Kruise Rollout v0.3.0：手把手教你实战操作Deployment 分批发布和流量灰度

helm3

安装

kubectl版本：v1.20.9

heml版本：v3.1.2

[root@k8smaster peishunwu]
wget https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz
tar zxvf helm-v3.1.2-linux-amd64.tar.gz
cd linux-amd64
cp helm /usr/bin/helm
helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}
[root@192 demo]# helm help
The Kubernetes package manager

Common actions for Helm:

- helm search:    search for charts
- helm pull:      download a chart to your local directory to view
- helm install:   upload the chart to Kubernetes
- helm list:      list releases of charts

helm3不在需要tiller,可以设置环境变量KUBECONFIG来指定存有ApiServre的地址与token的配置文件地址，默认为~/.kube/config

查看helm配置信息

[root@k8smaster linux-amd64]# helm env
HELM_BIN="helm"
HELM_DEBUG="false"
HELM_KUBECONTEXT=""
HELM_NAMESPACE="default"
HELM_PLUGINS="/root/.local/share/helm/plugins"
HELM_REGISTRY_CONFIG="/root/.config/helm/registry.json"
HELM_REPOSITORY_CACHE="/root/.cache/helm/repository"
HELM_REPOSITORY_CONFIG="/root/.config/helm/repositories.yaml"

添加共有的仓库

helm repo add stable http://mirror.azure.cn/kubernetes/charts
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts 
helm repo update

指定k8s集群的位置

这一步非常关键，它是helm与k8s通讯的保证，这一步就是把k8s环境变量KUBECONFIG进行配置
export KUBECONFIG=/root/.kube/config #可以写到/etc/profile里

Kruise-Rollout安装并使用

安装Kruise-Rollout

Kruise Rollout 可以通过 helm v3.1+ 进行简单安装，这是一个简单的命令行工具，您可以从这里获取。
安装 Kubernetes 集群，需要Kubernetes 版本 >= 1.19。

# Firstly add openkruise charts repository if you haven't do this.
$ helm repo add openkruise https://openkruise.github.io/charts/

# [Optional]
$ helm repo update
$ helm install kruise-rollout openkruise/kruise-rollout --version 0.3.0

# 卸载
$ helm uninstall kruise-rollout
release "kruise-rollout" uninstalled

Kruise-Rollout玩转第一步

kubectl create namespace test #创建一个名叫test的命名空间
部署一个nginx，副本调整为3

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: test
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              protocol: TCP
              containerPort: 80
          resources:
            limits:
              cpu: "1.0"
              memory: 512Mi
            requests:
              cpu: "0.5"
              memory: 128Mi
---
apiVersion: v1
kind: Service
metadata:
  annotations:
  name: nginx-test-service
  namespace: test
spec:
  ports:
    - port: 80
      targetPort: 80
      nodePort: 32001
      protocol: TCP
  selector:
    app: nginx
  sessionAffinity: None
  type: NodePort

发布nginx 应用

kubectl create -f nginx-deployment.yaml -n test

为nginx的deployment绑定下发规则

kubectl apply -f rollouts-demo.yaml

rollouts-demo.yaml

apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
  namespace: test
  annotations:
    rollouts.kruise.io/rolling-style: partition
spec:
  objectRef:  # 绑定你的 Deployment
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: nginx
  strategy:   # 制定你的分批发布规则
    canary:
      steps:
      - replicas: 1     #第一批发一个 Pod，发布完后暂停，手动确认后进入下一批
      - replicas: 60%   #第二批发60% Pod，发布完后暂停，手动确认后进入下一批
      - replicas: 100%  #第三批发全量 Pod，最后一批发布完后默认自动完成

玩转 Deployment 的分批发布

1、玩前第一步，查看发布前的版本

kubectl get deployment -n test

kubectl get replicaset -L pod-template-hash -n test

2、玩前第一步，查看发布前的版本

此时，我们修改容器的镜像版本触发发布

kubectl patch deployment nginx --patch '{"spec": {"template": {"spec": {"containers": [{"name": "nginx","image":"nginx:1.22.1"}]}}}}' -n test

可以看到第一批只发布了一个 Pod，版本号为 5f56795d47：

kubectl get replicaset -L pod-template-hash -n test

3、继续发布第二批

第一批 Pod 发布完毕后，此时假设我们已经完成第一批的验证，想要继续发第二批 Pod，我们可以借助 kubectl-kruise 这个命令行工具来进行批次完成的确认操作。该工具是基于 kubectl 的拓展，目前也是由 OpenKruise 社区维护

# 确认上一步发布完成，用下命令进入下一步发布
kubectl-kruise rollout approve rollout/rollouts-demo -n test

# 查看rollout 目前状态
kubectl get rollout -n test

# 查看第二次发布pod 分布状态

# 第二次发布完成后  查看rollout 目前状态
kubectl get rollout -n test

注：确认发下一批的命令为 kubectl-kruise rollout approve rollout/rollouts-demo

从上述过程可以看出，在该批次发布过程中且未完成时，Rollout 会进入 StepUpgrade 状态，而当该批次发布完成，会转变成 StepPaused 状态。

注意：kubectl-kruise rollout approve rollout/rollouts-demo
该命令执行前需要安装kruise，但是安装他之前需要安装
安装 krew：具体安装步骤：
Kruise-tools
krew安装

否则kubectl-kruise无法执行。

4、发布最后一批

当第二批发布确认完成后，发最后一批后，Rollout 会进入 Completed 状态，表示发布完成：

# 确认第二步发布完成，用下命令进入下一步发布
kubectl-kruise rollout approve rollout/rollouts-demo -n test

# 查看rollout 目前状态
kubectl get rollout -n test

已经到了完成状态

# 查看pod的升级情况
kubectl get replicaset -L pod-template-hash -n test

最新的版本已经完全被替换

# 确认pod发布完成
kubectl get deployment -n test

特别要说明的是，在分批发布的单个发布批次内，我们仍然会遵循流式滚动发布的规则，也就是说你仍然可以通过调整 Deployment 的MaxUnavailable和MaxSurge来兼顾你发布时的稳定性和效率，例如在以下场景，你依然可以遵循 Deployment 的如下配置：

• 单个批次内必须先扩后缩，最大程度保证发布稳定：

kind: Deployment
spec:
  strategy:
    rollingUpdate: 
      maxUnavailble: 0
      maxSurge: 20%

• 单个批次内必须先缩后扩，最大程度节省资源占用：

kind: Deployment
spec:
  strategy:
    rollingUpdate: 
      maxUnavailble: 20%
      maxSurge: 0

• 单个批次内边扩遍缩，最大程度提高发布效率：

kind: Deployment
spec:
  strategy:
    rollingUpdate: 
      maxUnavailble: 25%
      maxSurge: 25%

此外，该方案还充分考虑了各种发布场景，最大程度地提高方案的灵活性：

连续发布场景：v1 到 v2 的发布过程中（v2 未发布完成），又发布了 v3，此时 v3 仍然会从第一批开始走标准分批发布流程；
快速回滚场景：v1 到 v2 发布到中途，回滚回 v1，则会进行快速回滚，默认不再进行分批发布。
发布策略删除：无论是在发布完成后，甚至是在发布过程中，正常删除 Rollout 资源后，相应的 Deployment 都会无缝回退至流式滚动发布场景，方便某些特殊情况下快速进行变更。