在 Kubernetes 和 Istio 环境下进行蓝绿部署-莱卡云

原文：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