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

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

作者:Janakiram MSV

作为一个服务网格系统,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 核心。等集群启动:

minikube startup

步骤 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,查找并替换:

Changing Service Type

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):

kubectl get ns

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

kubectl get svc

稍候片刻,会看到很多 Pod:

kubectl get po

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

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

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

为了展示应用的不同版本,我构建了基于 Nginx 的简单镜像 - janakiramm/myapp:v1janakiramm/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 创建 ServiceDeployment。注意这个简单的应用对 Istio 一无所知。Istio 和应用的唯一可见的连接就是标签:

kubectl apply -f myapp.yaml

apply -f yaml

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

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

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

app image blue

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

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

app image green

步骤 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

app gateway

接下来就可以尝试访问这一服务了。因为我们使用的是 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

curl

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

把新的定义提交到 Istio。

$ istioctl replace -f app-gateway.yaml

replace

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

v2-100%

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

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

comments powered by Disqus
下一页
上一页

相关