deploy | 伪架构师

在 Kubernetes 和 Istio 环境下进行蓝绿部署

Sat, 20 Oct 2018 00:46:47 +0800

原文：Tutorial: Blue/Green Deployments with Kubernetes and Istio

作为一个服务网格系统，Istio 为服务间通信提供稳定性、透明性和安全性方面的保障。不论集群内外的服务，只要其访问目标是网格内的服务，就都会被 Istio 所拦截并进行处理。

Istio 有很多功能，例如服务间通信的加密、自动的指标记录、访问控制策略、频率限制以及配额等，这里我们仅着眼于最常用的流量管理能力。

Istio 让 DevOps 团队有能力为内部服务创建智能的路由规则。断路器、超时和重试之类的服务级属性非常容易配置，配置包含蓝绿部署及金丝雀发布的过程也很轻松。

本文教程用于帮助读者理解配置 Kubernetes + Istio 环境下的蓝绿部署过程。无需很多知识背景，只要理解一些在 Kubernetes 中部署 Pod 和服务的基础概念就好。我们会在 Minikube 和 Istio 中完成示例。

教程包含四个步骤：安装 Minikube、安装 Istio 并进行验证、安装一个应用的两个版本，最后配置服务的蓝绿部署。我们会使用两个简单的构建好了的镜像，分别作为蓝（v1）、绿（v2）两个版本。

步骤 1：安装 Minikube

为了降低依赖，我们会使用 Minikube 作为测试平台。因为需要自定义配置，所以要删除已经存在的配置，并使用额外参数重新启动集群：

minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.10.0 \
--extra-config=controller-manager.cluster-signing-cert-file="/var/lib/localkube/certs/ca.crt" \
--extra-config=controller-manager.cluster-signing-key-file="/var/lib/localkube/certs/ca.key" \
--vm-driver=virtualbox

要在 Minikube 上运行 Istio，需要至少 8G 内存和 4 个 CPU 核心。等集群启动：

步骤 2：安装 Istio

Kubernetes 集群成功启动之后，就可以安装 Istio 了。用下面的步骤完成：

curl -L https://git.io/getLatestIstio | sh -

在运行上述命令的目录中会发现一个 istio-1.0.2 目录，可以把 istio-1.0.2/bin 目录加入 PATH 变量，方便后面的命令执行过程。

由于我们在 Minikube 环境下运行的 Istio，所以我们要在下一步进行之前，要把 Ingress Gateway 服务从 LoadBalancer 改为 NodePort。

打开文件 istio-1.0.2/install/kubernetes/istio-demo.yaml，查找并替换：

Istio 中包含了很多 CRD，可以帮用户来进行虚拟服务、规则、网关以及其他对象的管理。在部署服务网格之前首先要部署一下这些 CRD：

kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml

最后，在 Kubernetes 中安装 Istio：

kubectl apply -f install/kubernetes/istio-demo.yaml

上面的步骤会创建新的命名空间（istio-system）：

会看到这里还有很多服务：

稍候片刻，会看到很多 Pod：

Istio 如果成功部署，所有这些 Pod 只能是 Running 或者 Completed 状态。

下一步就要准备用于蓝绿部署的应用了。

步骤 3：安装同一应用的两个版本

为了展示应用的不同版本，我构建了基于 Nginx 的简单镜像 - janakiramm/myapp:v1 和 janakiramm/myapp:v2。部署之后，会展示蓝色或者绿色的背景。

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  type: ClusterIP
  ports:
  - port: 80
    name: http
  selector:
    app: myapp
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

也可以在 Github 上看到这些代码。

接着就要创建 YAML 文件来定义 v1 和 v2 服务了。注意 Pod 标签的差异代表了不同的版本 —— app 保持一致，但 version 是不同的。这样一来，Istio 就会认为这是同一应用的不同版本。

而服务中的选择器定义只针对 app 标签进行设置，也就是说不同版本的 Pod 都会参与这一服务。

用 kubectl 创建 Service 和 Deployment。注意这个简单的应用对 Istio 一无所知。Istio 和应用的唯一可见的连接就是标签：

kubectl apply -f myapp.yaml

配置 Istio 路由之前，首先检查一下应用的版本。可以使用端口转发的方式来访问 Pod。

要访问应用的 v1 版本，可以运行下面的命令，然后访问 localhost:8080，验证完成之后，按 CTRL+C 结束端口映射命令。

kubectl port-forward deployment/myapp-v1 8080:80

要访问应用的 v2 版本，可以运行下面的命令，然后访问 localhost:8081，验证完成之后，按 CTRL+C 结束端口映射命令。

kubectl port-forward deployment/myapp-v2 8081:80

步骤 4：配置蓝绿部署

我们的目标是在不停机的情况下，让流量选择性的进入某一版本。为了完成这一目的，就需要告知 Istio 根据权重进行路由。完成这一任务需要三个对象：

Gateway

Istio Gateway 描述了网格边缘的负载均衡组件，用于 HTTP/TCP 连接的接收和发出。定义中包含一组要开放的端口、使用的协议、负载均衡的 SNI 等。下面的定义中我们将 Gateway 指向 Istio 部署过程中建立的缺省的 Ingress Gategeway。

用 Kubernetes 的方式创建 Gateway 对象：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: app-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

目标规则

Istio DestinationRule 定义了在一个服务成为路由目标之后的行为。注意一下这一规则中是如何通过标签来对 Kubernetes 的原生 Deployment 进行区分的：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

虚拟服务

虚拟服务中定义了一组流量路由规则，在其中的 host 被访问时就会触发。每个路由规则中都定义了对某一协议进行匹配的标准。如果流量匹配这一标准，那么就发送给对应的区分了版本的目标服务。

下面的定义中我们定义两个版本的服务权重都是 50，也就是说流量会在版本间进行平均分配：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - "*"
  gateways:
  - app-gateway
  http:
    - route:
      - destination:
          host: myapp
          subset: v1
        weight: 50
      - destination:
          host: myapp
          subset: v2
        weight: 50

所有这些都可以定义在同一个 YAML 文件中，然后用 kubectl 提交给集群，同样可以在 Gtihub 中获取这一文件。

kubectl apply -f app-gateway.yaml

接下来就可以尝试访问这一服务了。因为我们使用的是 NodePort 模式的服务，所以就需要首先判断一下 Ingress Gateway 所在的端口。

运行下面的命令来访问 MiniKube 的 Ingress 端口。

$ export INGRESS_HOST=$(minikube ip)

$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

从浏览器访问这个 URL，会看到流量被均等的在蓝色和绿色版本之间进行分配。

也可以在终端里面查看命令结果。运行下面的命令会看到 V1 和 V2 的响应：

while : ;do export GREP_COLOR='1;33';curl -s  192.168.99.100:31380 \
 |  grep --color=always "V1" ; export GREP_COLOR='1;36';\
 curl -s  192.168.99.100:31380 \
 | grep --color=always "vNext" ; sleep 1; done

上面的命令会循环运行，我们可以返回编辑 gateway.yaml，修改其中的权重分配。把 V1 的权重设置为 0，V2 的权重设置为 100.

把新的定义提交到 Istio。

$ istioctl replace -f app-gateway.yaml

更新权重之后，V2 的响应比例会提升到 100%。这一结果会体现在输出之中：

可以继续对权重进行修改，查看路由的动态变化过程。

流量管理只是 Istio 的一个功能，后续文章中尝试更多其他特性。

Deploy 的基本用法

Thu, 13 Aug 2015 23:48:37 +0800

在这个演示中，我们会创建和部署一个新的 Node，然后发布一个针对该 Node 的更新。

部署

一次部署分为两个阶段：把内容添加到部署计划，发布部署计划。部署计划的发布将内容添加到目标服务器。

部署计划

一个部署计划包含一组将要发布到目标服务器上的内容。这些内容可以手工添加到部署计划中，也可以使用 Views 聚合或者 Rules 进行自动化操作。

手工添加内容

在源服务器进入node/add/article，创建一个新的 Article。然后随便选一些选项并保存。
进入admin/content/node，查看刚新建的 Node，从 Update options 中，Add to managed deployment plan下选择部署计划，点击 Update 按钮，然后在其他需要添加的内容上做同样的操作。
要发布这个计划，进入admin/structure/deploy然后点击 Deploy 连接，点击 Deploy 按钮进行确认。
在源服务器上运行Cron（这是因为在 Deploy 安装指南中选择 Queue API 作为 Deployment 处理器）。
编辑步骤1中提到的Node并保存。
重复第二和第三步。
在源服务器上运行Cron。

注：可以在 admin/reports/dblog 上查看部署消息。

自动部署计划

上文中我们通过手工添加内容到部署计划的方式发布了一个Node，接下来我们看看更自动化的方式。

Views Aggregation

确认你完成了 Deploy 安装中的所有步骤。我们要创建一个 Views Aggregator（和一个 View），而不是用一个 Managed aggregator。

在源服务器：

启用如下模块：Views deployment aggregator

drush en deploy_aggregator_views
创建一个包含你想要添加到 Deployment plan 中的内容的 View（也可以直接使用首页 View）。
接下来，利用 Views aggragator 创建一个部署计划：进入admin/structure/deploy/plans，点击”Add”。
给计划命名，例如 “Push to live server”。Aggregator 选择 Views aggregator；清空 Fetch only 选项；Deploy processor 使用 Queue API；Endpoints 设置为 Deploy 安装中的设置内容。点击 “Continue” 进入下一步。
选择刚才新建的 Aggregator View（或者选择缺省的首页视图）。
没有需要配置的插件，点击完成。
要发布这个计划，进入admin/structure/deploy点击 Deploy 连接，确认发布。

所有出现在指定视图中的内容都会被添加到部署计划中。创建视图之后发布的内容也会包含进来。如果有内容在发布的同时进入该视图，那么他会被加入部署计划，并推送到目标服务器。

Rule Actions

在源服务器上：

确认按照Installing Deploy中讲到的方法创建一个Managed aggregator，记住点击”Delete successfully deployed items(删除发布成功的内容)“。
下载Rules模块。
```
drush dl rules
```
启用Rules以及Rules UI模块。
```
drush en rules rules_admin
```
进入 admin/config/workflow/rules，点击 Add new rule。
输入 Content to Deployment plan ，或者其他什么名字，在 React on event 中选择After saveing new content (新建内容之后)（这个选项位于 Node 的下级）。点击Add。
点击 Add Event（添加事件）。
选择 After updating existing content (更新现有内容)，点击Add。
点击 Add Condition(添加条件).
在 Select the condition to add 中选择 Content is of type(内容属于某类)。
在 Data Selector 中选择 Node，并在 Content type 检查条件中选择 Article。
点击 Add action。
在 Select the action to add 中选择 Add an entity to a managed deployment plan。
在 Value 中选择之前创建的 Managed aggregator 计划，在 Data Selector 中选择 node，点击 Save。
在 node/add/article 中创建新的 Article。
进入 admin/structure/deploy，可以看到刚创建的 Article 已经在第 13 步中的计划之中了。现在开始，所有新创建和更新的 Articles 都会被自动加入部署计划。
要发布计划，进入 adimin/structure/deploy，点击 “Deploy” 按钮，然后利用 “Deploy” 按钮确认。

另外，要把部署计划做成自动化部署，可以添加一个 Rule Action “Deploy a plan”，使得每次 Aticle 的创建和编辑都触发部署计划的发布。这种做法并不推荐。

使用Deploy和Features导出Entities

Thu, 13 Aug 2015 23:48:21 +0800

Deploy Module可以把任何支持UUID的Entity导出到Features中。这个功能在创建安装范本或演示时非常有用，或者用于处理一些既非配置，也非内容的对象。

使用Deploy导出内容：

安装Deploy和Features。如果不需要使用Deploy进行Drupal站点之间的内容同步，知识想要导出到Features的话，就无需关心Service Module的安装了。
进入admin/structure/deploy/plans/add建立一个新的部署计划。
选择聚合方式，参考Deploy基础用法，来获取关于将内容加入部署计划的不同方法。
选择Fetch only，因为我们不需要部署处理，也不需要服务节点，而且没有选择这个选项的话，部署计划也不会出现在Features界面中。
进入admin/structure/features/create菜单。
在Deployment(deploy_pnas)中，为新建的部署计划选择组件。
在UUID Entities(uuid_entities)中，会发现一个和部署计划同名的组件，选择之。
注意，上文提到的选择，不会自动提供对内容类型、字段、模块等依赖关系的处理。所以要清楚导出内容的外部依赖。如果只是导出内容到相似或相同的站点，或者利用其他的Features来解决依赖关系，最好只导出部署计划以及相关的Entity组件。

需要导出的内容需要支持UUID。Entity UUID项目为非核心Entity提供了支持。要给Commerce Entity提供UUID支持，可移步到Commerce UUID。

变通做法：

UUID Features Integration模块提供了一种简单的导出内容到Features的方式，不过她主要支持的是核心Entity。使用Deploy，只要有UUID支持的Entity都是可导出的。如果你只是想要导出核心Entity，那么这种无需更多配置的方式可能更简单。