istio流量管理

目录

1 准备工作

1.1 在k8s部署istio

Istio在k8s集群内的部署很简单,非生产要求的部署,可以直接在https://github.com/istio/istio/releases 下载最新的发布包,压缩包里有供简单部署的yaml文件:

$ for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -f $i; done
$ kubectl apply -f install/kubernetes/istio-demo.yaml

注意,上面两条指令会把主要的组件都给装上,镜像下载比较费力,内存消耗也比较大。没个十几G内存的同学请慎重。

部署完成后会新增一个命名空间istio-system:

$ kubectl get pods -n istio-system
NAME                                                           READY   STATUS      RESTARTS   AGE
grafana-f8467cc6-rbjlg                                         1/1     Running     0          1m
istio-citadel-78df5b548f-g5cpw                                 1/1     Running     0          1m
istio-cleanup-secrets-release-1.1-20190308-09-16-8s2mp         0/1     Completed   0          2m
istio-egressgateway-78569df5c4-zwtb5                           1/1     Running     0          1m
istio-galley-74d5f764fc-q7nrk                                  1/1     Running     0          1m
istio-grafana-post-install-release-1.1-20190308-09-16-2p7m5    0/1     Completed   0          2m
istio-ingressgateway-7ddcfd665c-dmtqz                          1/1     Running     0          1m
istio-pilot-f479bbf5c-qwr28                                    2/2     Running     0          1m
istio-policy-6fccc5c868-xhblv                                  2/2     Running     2          1m
istio-security-post-install-release-1.1-20190308-09-16-bmfs4   0/1     Completed   0          2m
istio-sidecar-injector-78499d85b8-x44m6                        1/1     Running     0          1m
istio-telemetry-78b96c6cb6-ldm9q                               2/2     Running     2          1m
istio-tracing-69b5f778b7-s2zvw                                 1/1     Running     0          1m
kiali-99f7467dc-6rvwp                                          1/1     Running     0          1m
prometheus-67cdb66cbb-9w2hm                                    1/1     Running     0          1m

1.2 istio自动注入

在介绍istio原理时有提到,istio会在每一个被管理的pod里注入一个sidecar容器envoy。那么istio是如何完成注入的呢,主要有2种方式:
1) 手动注入:如下命令,在kubectl前先执行istioctl手动注入

$ istioctl kube-inject -f <your-app-spec>.yaml | kubectl apply -f -

2) 自动注入:运用k8s的admission-control完成自动注入
• kube-apiserver配置文件的admission-control参数,增加MutatingAdmissionWebhook 以及 ValidatingAdmissionWebhook 两项
• 给命名空间打上自动注入的标签(下方我们允许istio在default空间自动注入,同时禁用了istio-system空间的自动注入):

$ kubectl label namespace default istio-injection=enabled
$ kubectl get namespace -L istio-injection
NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   4d21h   enabled
ingress-nginx     Active   4d17h   
istio-system      Active   4d17h   disabled
kube-node-lease   Active   4d21h   
kube-public       Active   4d21h   
kube-system       Active   4d21h

后面的测试,我们以第2种方式自动注入envoy。
注:通过在deployment文件的annotations参数里加上sidecar.istio.io/inject: "false",可以覆盖命名空间的标签,禁止istio对本pod的自动注入

1.3 应用部署要求

Istio原生与k8s能够无缝对接, istio的存在与否对应用程序本身来说,也是透明的。所以应用的部署,主要涉及的是yaml文件的修改完善:
1) Deployment文件的要求:
• 应带有app和version标签,这个主要是用来识别不同版本的pod。
• Deployment应明确列出端口列表,istio会忽略未列出的端口。
• 下方为data-product的示例,注释部分为需要注意的地方:

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  # 建议pod名称 = 应用名 + 版本号
  name: data-product-v4.0
  namespace: default
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
      namespace: default
      labels:
        # 标签1:应用名称
        app: data-product
        # 标签2:版本号
        version: v4.0
    spec:
      containers:
      - name: data-product
        ports:
        # 需要Istio管理的端口号列表
        - containerPort: 50051
……

2) Service文件的要求:
• 需要指定端口的协议类型,否则默认按TCP协议处理:

---
apiVersion: v1
kind: Service
metadata:
  name: data-product
  namespace: default
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path:   /metrics
    prometheus.io/port:   '8081'
  labels:
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "data-product"
spec:
  ports:
    - name: data-product
      port: 50051
      # 指定端口的协议类型为grpc
      name: grpc
      targetPort: 50051
  selector:
    app: data-product

2 负载均衡

$ kubectl get po -o wide
NAME                                     READY   STATUS  
business-product-6b954db744-cgn8k        2/2     Running 
business-product-6b954db744-dgm4x        2/2     Running 
business-product-6b954db744-n5c8p        2/2     Running 
business-product-v4.0-747ccffbb4-2p2z8   2/2     Running 
business-product-v4.0-747ccffbb4-4bh6z   2/2     Running 
business-product-v4.0-747ccffbb4-8kgqs   2/2     Running 
business-product-v4.0-747ccffbb4-hz6lb   2/2     Running 
business-product-v4.0-747ccffbb4-kgs6p   2/2     Running 
business-product-v4.0-747ccffbb4-rmmwg   2/2     Running 
business-product-v4.0-747ccffbb4-sspgr   2/2     Running 
business-product-v4.0-747ccffbb4-sz7ll   2/2     Running 
business-product-v4.0-747ccffbb4-vnd58   2/2     Running 
data-product-5bc9f7bb9c-dfchd            2/2     Running 
data-product-5bc9f7bb9c-tv8cj            2/2     Running 
data-product-5bc9f7bb9c-xzz7s            2/2     Running 

这里我们启用了9个business-product的pod,和3个data-product的pod。上表有一个细节,每个pod里有2个容器,除了我们的应用程序容器外,还有一个就是enovy。

当pod被注入了enovy,并且是按1.3节的要求将port暴露给了istio,则Istio会自动接管pod的流量,实现负载均衡。
Business-product作为client与data-product server之间通过grpc通讯,这里我简单修改了下business-product和data-product的逻辑,当收到请求时data-product会将自身和client的ip作为响应,而business-product则会在这个响应的基础上再加上自己的ip。所以我们对business-product发起连续的请求,就能得到下方的一组ip对(其中每一行的第1个ip是client的ip,第2个是server检测到的client ip,第3个是server的ip):

"ip": "172.30.27.8/24 - 127.0.0.1:43094 - 172.30.86.3/24",
"ip": "172.30.95.17/24 - 127.0.0.1:43120 - 172.30.86.3/24",
"ip": "172.30.27.9/24 - 127.0.0.1:43094 - 172.30.86.3/24",
"ip": "172.30.86.9/24 - 127.0.0.1:41662 - 172.30.27.3/24",
"ip": "172.30.95.15/24 - 127.0.0.1:43094 - 172.30.86.3/24",
"ip": "172.30.86.7/24 - 127.0.0.1:41712 - 172.30.27.3/24",
"ip": "172.30.27.11/24 - 127.0.0.1:43872 - 172.30.95.7/24",
"ip": "172.30.86.8/24 - 127.0.0.1:41712 - 172.30.27.3/24",
"ip": "172.30.95.14/24 - 127.0.0.1:43944 - 172.30.95.7/24",

"ip": "172.30.27.8/24 - 127.0.0.1:43944 - 172.30.95.7/24",
"ip": "172.30.95.17/24 - 127.0.0.1:43872 - 172.30.95.7/24",
"ip": "172.30.27.9/24 - 127.0.0.1:43944 - 172.30.95.7/24",
"ip": "172.30.86.9/24 - 127.0.0.1:43094 - 172.30.86.3/24",
"ip": "172.30.95.15/24 - 127.0.0.1:43872 - 172.30.95.7/24",
"ip": "172.30.86.7/24 - 127.0.0.1:43120 - 172.30.86.3/24",
"ip": "172.30.27.11/24 - 127.0.0.1:41662 - 172.30.27.3/24",
"ip": "172.30.86.8/24 - 127.0.0.1:43094 - 172.30.86.3/24",
"ip": "172.30.95.14/24 - 127.0.0.1:41712 - 172.30.27.3/24",

"ip": "172.30.27.8/24 - 127.0.0.1:41712 - 172.30.27.3/24",
"ip": "172.30.95.17/24 - 127.0.0.1:41712 - 172.30.27.3/24",
"ip": "172.30.27.9/24 - 127.0.0.1:41712 - 172.30.27.3/24",
"ip": "172.30.86.9/24 - 127.0.0.1:43872 - 172.30.95.7/24",
"ip": "172.30.95.15/24 - 127.0.0.1:41662 - 172.30.27.3/24",
"ip": "172.30.86.7/24 - 127.0.0.1:43944 - 172.30.95.7/24",
"ip": "172.30.27.11/24 - 127.0.0.1:43094 - 172.30.86.3/24",
"ip": "172.30.86.8/24 - 127.0.0.1:43872 - 172.30.95.7/24",
"ip": "172.30.95.14/24 - 127.0.0.1:43120 - 172.30.86.3/24",

我们连续发起了27次请求,不出所料,client的9个Pod分别被分配到了3次请求,接下来我们看看server是否负载上了:
• 27次请求中,3个server的pod均被分配了9次,负载是均衡的。
• 进一步分析,同一个client,每次被分配到的server是不同的,这是因为envoy代理在中间拦了一手,这正是负载的实现原理。
• 再进一步分析,server检测到的客户端ip,是127.0.0.1的本地ip,这个连接其实是面向本pod的envoy的。

所以我们可以认为envoy为我们在网格内建立起了一个服务之间的连接池,从而实现了负载均衡。

最后,我们再回过头来对比针对grpc长连接的情况,k8s的负载和istio的负载的差异:
• K8s的负载是在连接发起时实现的,比如我们的例子里有9个客户端,则调用了9次负载算法,次数太少,负载未必是均衡的。
• 基于连接的负载,一旦pod异常退出,连接断开,重新建立起的连接有更大的概率被集中到个别没断开的pod上,这会加剧负载的不均衡性。
• Istio维护的负载是在每次通讯的时候完成的动态调度,不受连接数的限制,在大量通讯的情况下,istio能够保证负载的均衡。

3 流量迁移:金丝雀发布

上一章envoy已经接管了我们的流量,接下来就可以让envoy为我们做更细致的流量管理的动作了。本章我们会通过简单的配置来实现金丝雀发布。

假设我们已经发布了data-product的v3.0版本,现在我们有一个v4.0的版本需要更新上去。版本发布过程中我们期望先将10%的流量导入到v4.0版本,剩余90%的流量还是由v3.0版本来处理。待v4.0版本运行稳定无异常后,我们再将100%的流量迁移到v4.0版本。

3.1 发布应用

回顾1.3章节,我们在发布data-product时,需要deployment的名称区分版本(想想为啥?)。为实现两个版本的平滑过渡、金丝雀发布,我们需要同时发布两个版本的deployment:

$ kubectl get deployment 
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
business-product    3/3     3            3           5h13m
data-product        3/3     3            3           4h30m
data-product-v4.0   3/3     3            3           4h16m

上表data-product是v3.0版本的(这里我命名不规范),data-product-v4.0是v4.0版本的,各有3个pod在运行。

3.2 创建目标规则:DestinationRule

目标规则(DestinationRule)是用来定义流量应该由哪些pod来接收的。下方的yaml文件我们创建了一个DestinationRule,标识发往data-product的流量,由data-product的v3.0和v4.0两个版本来接收。这个yaml文件的关键是subsets字段的两个labels,这对应着1.3和3.1节的应用版本。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: data-product
spec:
  host: data-product
  subsets:
  - name: v3
    labels:
      version: v3.0
  - name: v4
    labels:
      version: v4.0

3.3 创建虚拟服务:VirtualService

Service和virtualservice的目标是一致的,都是将流量导向后端的pod。区别是由istio引入的virtualservice可以完成更细致的流量划分。
下方的yaml文件,我们将10%的流量导向了v4版本,90%的流量导向v3版本。这个文件的关键是subset字段,这对应于DestinationRule的subsets;以及weight权重,按百分比划分。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: data-product
spec:
  hosts:
  - data-product
  http:
  - route:
    - destination:
        host: data-product
        subset: v3
      weight: 90
    - destination:
        host: data-product
        subset: v4
      weight: 10

3.4 验证和结语

限于篇幅,验证数据就不贴了。平均每10次请求,会有1次导向v4,另外9次还在v3。
不难理解,运行一段时间觉得v4版本ok了,我们可以将权重配比调整到50%,75%,直到100%的流量都导向v4。之后v3版本的deployment就可以删了。

上一篇:Istio概念原理&&为什么要使用 Istio?&&架构图


下一篇:Istio 是什么?