纸上得来终觉浅，绝知此事要躬行

0%

渐进式的Deployment-Argo Rollout

发表于 更新于 分类于

渐进式的Deployment–Argo Rollout

导语：熟悉k8s的同学知道Deployment目前只支持RollingUpgrade和ReCreate两种策略。而对于运维的同学而言，实际生产环境中更多应该使用灰度发布和蓝绿部署，笔者本想尝试造轮子，实现一个加强版，正好网上搜索到Argo-Rollout和我想法一致，就不用重复造轮子了，本文就是体验一下Argo-Rollout。

简介

Argo-Rollout是一个Kubernetes Controller和对应一系列的CRD，提供更强大的Deployment能力。包括灰度发布、蓝绿部署、更新测试(experimentation)、渐进式交付(progressive delivery)等特性。

支持特性：

  • 蓝绿部署
  • 灰度发布
  • 细粒的，带权重的流量调度（traffic shifting）
  • 自动rollback和promotion
  • 手动管理
  • 可定制的metric查询和kpi分析
  • Ingress controller集成：nginx，alb
  • Service Mesh集成：Istio，Linkerd，SMI
  • Metric provider集成：Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs

原理：

Argo原理和Deployment差不多，只是加强rollout的策略和流量控制。当spec.template发送变化时，Argo-Rollout就会根据spec.strategy进行rollout，通常会产生一个新的ReplicaSet，逐步scale down之前的ReplicaSet的pod数量。

安装

官方安装文档

1.安装argo-rollouts的controller和crd

1
2
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

2.安装argo-rollouts的kubectl plugin

1
2
3
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

使用

灰度发布包含Replica Shifting和Traffic Shifting两个过程。

Replica Shifting

这里就直接拿官网的例子，来体验一下Replica Shifting。

1.部署一个Demo应用

首先创建一个Rollout的CR和访问该CR的Service:

1
2
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

Rollout CR，可以看到除了apiVersion，kind以及strategy之外，其他和Deployment无异，实际上其源码基本上都是引用的Deployment的数据结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#cat rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollouts-demo
  template:
    metadata:
      labels:
        app: rollouts-demo
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        resources:
          requests:
            memory: 32Mi
            cpu: 5m

暴露的service：

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: rollouts-demo

可以使用Argo-Rollout提供的plugin查看其状态，感觉还是很香：

1
[root@xiowang-dev ~/yaml]# kubectl argo rollouts get rollout rollouts-demo

部署Rollout

2.更新spec触发rollout

然后通过修改spec中的镜像，触发一次rollout:

1
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

预期Rollout会创建一个新的ReplicaSet，并且逐步扩容新的ReplicaSet和缩容旧的ReplicaSet，用plugin查看一下:

1
# kubectl argo rollouts get rollout rollouts-demo --watch

Canary状态

可以看到Rollout新创建了ReplicaSet rollouts-demo-789746c88d，并且将老ReplicaSet的Pod转移到新的ReplicaSet，新老ReplicaSet的pod比例为: 1:4，并且状态为Paused，没有继续升级新pod，为什么呢？

主要原因就在这个spec.strategy，通过这个strategy我们可以看到其为升级设定了steps，由于是个列表，因此其会按照顺序执行。这里第一步就是setWeight：20，意味着需要将20%的pod更新为新版本；第二步动作为pause: {}，意味着将永久暂停，需要人为通过plugin使其继续:

1
2
3
4
5
6
7
8
9
10
11
strategy:
  canary:
    steps:
    - setWeight: 20
    - pause: {}
    - setWeight: 40
    - pause: {duration: 10} #停顿10s
    - setWeight: 60
    - pause: {duration: 10}
    - setWeight: 80
    - pause: {duration: 10}

我们通过promote命令使其进行下一步：

1
# kubectl argo rollouts promote rollouts-demo

让我们再查看结果，所有pod都为新的ReplicaSet的pod：

Finished

Traffic Shifting

上面例子演示了Argo-Rollout如何控制Replica Shifting，而正常的灰度过程，应该包含Replica Shifting和Traffic Shifting两部分。

目前Argo-Rollout主要集成了Ingress和ServiceMesh两种流量控制方法，我的测试环境中目前只部署了Nginx-Controller那就使用Ingress做演示。

1.部署物料

首先删除之前的例子:

1
2
kubectl delete -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl delete -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

再部署官网的例子:

1
2
3
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/nginx/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/nginx/services.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/nginx/ingress.yaml

上面的文件会部署1个rollout，两个service和一个ingress:

Rollout里分别用canaryService和stableService分别定义了该应用灰度的Service Name(rollouts-demo-canary)和当前版本的Service Name(rollouts-demo-stable):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  replicas: 1
  strategy:
    canary:
      canaryService: rollouts-demo-canary
      stableService: rollouts-demo-stable
      trafficRouting:
        nginx:
          stableIngress: rollouts-demo-stable
      steps:
      - setWeight: 5
      - pause: {}
...

Service rollouts-demo-canary 和 rollouts-demo-stable，二者内容一样。selector中暂时没有填上pod-template-hash，Argo-Rollout Controller会根据实际的ReplicaSet hash来修改该值:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo-canary
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: rollouts-demo
    # This selector will be updated with the pod-template-hash of the canary ReplicaSet. e.g.:
    # rollouts-pod-template-hash: 7bf84f9696

---
apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo-stable
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: rollouts-demo
    # This selector will be updated with the pod-template-hash of the stable ReplicaSet. e.g.:
    # rollouts-pod-template-hash: 789746c88d

Ingress则定义了规则，nginx将rollouts-demo.local域名的请求转发到当前版本的Service(rollouts-demo-stable):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: rollouts-demo-stable
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: rollouts-demo.local
    http:
      paths:
      - path: /
        backend:
          # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
          serviceName: rollouts-demo-stable
          servicePort: 80

Rollout Controller会根据ingress rollouts-demo-stable内容，自动创建一个ingress用了灰度的流量，名字为--canary，所以这里多了一个ingress rollouts-demo-rollouts-demo-stable-canary，将流量导向Canary Service(rollouts-demo-canary):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  generation: 1
  name: rollouts-demo-rollouts-demo-stable-canary
  namespace: default
  ownerReferences:
  - apiVersion: argoproj.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Rollout
    name: rollouts-demo
    uid: 2d5b728b-2f71-4bf2-8283-323acf8ef573
spec:
  rules:
  - host: rollouts-demo.local
    http:
      paths:
      - backend:
          serviceName: rollouts-demo-canary
          servicePort: 80
        path: /

2.触发更新

1
2
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
kubectl argo rollouts get rollout rollouts-demo

可以看到Rollout状态中SetWeight为5了

traffic

同时查看Ingress，多了nginx.ingress.kubernetes.io/canary和nginx.ingress.kubernetes.io/canary-weight 两条annotation:

1
2
3
4
5
6
7
8
9
10
11
12
13
#当前版本Ingress

#灰度Ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "5"
  creationTimestamp: "2020-07-05T06:31:54Z"
  generation: 1
  name: rollouts-demo-rollouts-demo-stable-canary

细心的你也能看出上面结果显示有一个小问题问题ActualWeight：50，这里应该为5或者95，所以顺便提了个issue给社区。

总结

Argo-Rollout提供更加强大的Deployment，包含比较适合运维的灰度发布和蓝绿发布功能。本文也是简单体验了一下其灰度发布功能。

本文未提及的功能包括：

  1. Experiments，可以加入到Steps中，用于检验每个Step是否符合用户预期；
  2. Analysis，用于统计Rollout中的各种metrics，包括每个Step花费时间等。

另外想到一个需求Argo-Rollout暂时未支持:

对于traffic-shifting，在做灰度的时候应该是让固定的一些用户或者url流量到新版本，目前Argo-Rollout并不支持。

当然上面这个问题可以通过添加一个Experiment，由该Experiment去修改Ingress或者SMI中的内容来实现。

除去功能之外，从源码学习的角度来说，Argo-Rollout仍然是一个好项目，结构清晰，适合学习写Controller和Plugin。

思考：为什么不算复杂的代码，k8s自己不实现呢？猜测官方为了鼓励大家多写CRD吧，哈哈！