渐进式交付组件KruiseRollouts使用

Kruise Rollouts 是 OpenKruise 提供的一个旁路组件，用于提供渐进式交付功能。它支持金丝雀、多批次和 A/B 测试交付模式，可以帮助实现对应用程序变更的平稳和可控发布，同时它与 Gateway API 和各种 Ingress 实现的兼容性使其更容易与你现有基础架构集成。总的来说，Kruise Rollouts 对于希望优化其部署流程的 Kubernetes 用户来说是一个有价值的工具！

成都创新互联公司服务项目包括内黄网站建设、内黄网站制作、内黄网页制作以及内黄网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，内黄网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到内黄省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

Kruise Rollouts

Kruise Rollouts 具有以下几个主要特点：

  • 更多的发布策略
  • Deployment、CloneSet、StatefulSet 和 Advanced StatefulSet 的多批次更新策略。
  • Deployment 的金丝雀更新策略。
  • 更多流量路由管理策略

  • 在更新工作负载时进行流量细粒度加权流量转移。

  • 基于 HTTP 头和 Cookie 进行 A/B 测试，根据流量进行转移。

  • 更多流量协议支持

  • Ingress 控制器集成：NGINX、ALB、Higress。

  • 通过 Gateway API 与服务网格集成。

  • 可插拔的 Lua 脚本，轻松扩展到其他 Kubernetes 流量协议（甚至 CRD）。

  • 容易集成

  • 轻松与 GitOps 风格的基于 Kubernetes 的 PaaS 集成。

和其他发布组件相比，Kruise Rollouts 有什么优势？

组件

Kruise Rollouts

Argo Rollouts

Flux Flagger

核心概念

增强现有工作负载

替换你的工作负载

管理你的工作负载

架构

旁路

一种新的工作负载类型

旁路

插拔式组件，热插拔

是

否

否

发布类型

多批次，金丝雀，A/B 测试

多批次，金丝雀，蓝绿部署，A/B 测试

金丝雀，蓝绿部署，A/B 测试

工作负载类型

Deployment,StatefulSet,CloneSet,Advaned StatefulSet,DaemonSet(WIP)

Agro-Rollout

Deployment. DaemonSet

流量类型

Ingress、GatewayAPI、CRD（需要 Lua 脚本）

Ingress、GatewayAPI、APISIX、Traefik、SMI 等

Ingress、GatewayAPI、APISIX、Traefik、SMI 等

迁移成本

无需迁移你的工作负载和 Pod

必须迁移你的工作负载和 Pod

必须迁移你的 Pod

HPA 兼容

是

是

否

整体上对比，Kruise Rollouts 与 Argo Rollouts 有相似的架构，但是功能上 Kruise Rollouts 更加强大，支持更多的发布策略和流量路由管理策略，同时也支持更多的流量协议。Kruise Rollouts 也是一个旁路组件，不需要迁移你的工作负载和 Pod，你可以在任何时候安装它，它会自动发现你的工作负载并管理它们。而和 Flagger 相比，Kruise Rollouts 支持更多的发布策略和流量路由管理策略，同时也支持更多的流量协议。

所以，如果你想要更多的发布策略和流量路由管理策略，同时也想要更多的流量协议支持，那么 Kruise Rollouts 就是一个不错的选择！

安装

要使用 Kruise Rollouts，需要 Kubernetes 版本 >= 1.19，如果要使用 CloneSet 作为工作负载类型，则还需要安装 OpenKruise。

这里我们使用 Helm 来安装 Kruise Rollouts，你可以使用 helm repo add 命令来添加 Kruise 的 Helm 仓库：

 helm repo add openkruise https://openkruise.github.io/charts/
 helm repo update

然后可以使用 helm install 命令来一键安装 Kruise Rollouts：

 helm upgrade --install kruise-rollout openkruise/kruise-rollout --version 0.3.0

如果你没办法访问 DockerHub，可以使用阿里云的镜像仓库：

 helm upgrade --install kruise-rollout openkruise/kruise-rollout --version 0.3.0 --set image.repository=openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/kruise-rollout

该命令默认会在 kruise-rollout 命名空间中安装 Kruise Rollouts，可以通过 kubectl get pods -n kruise-rollout 命令来查看安装结果：

 kubectl get pods -n kruise-rollout
NAME                                                READY   STATUS    RESTARTS   AGE
kruise-rollout-controller-manager-b4d64789d-9kmgm   1/1     Running   0          3m18s
kruise-rollout-controller-manager-b4d64789d-gln5n   1/1     Running   0          3m18s

如果想更改默认安装的命名空间，则可以通过 installation.namespace 参数来进行指定。

安装后可以看到在 kruise-rollout 命名空间中多了一个 kruise-rollout-controller-manager 的 Deployment，它是 Kruise Rollouts 的控制器，它会自动发现你的工作负载并管理它们。

同样还会安装 3 个用于 Rollout 的 CRD：

 kubectl get crd |grep rollout
batchreleases.rollouts.kruise.io           2023-04-08T06:44:51Z
rollouthistories.rollouts.kruise.io        2023-04-08T06:44:51Z
rollouts.rollouts.kruise.io                2023-04-08T06:44:51Z

使用

接下来我们来使用 Kruise Rollouts 来管理一个工作负载，这里我们使用 Deployment 作为示例。

首先我们创建一个如下所示的 Deployment 工作负载：

# workload-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: workload-demo
  namespace: default
spec:
  replicas: 10
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: busybox
          image: busybox:1.28.3
          command: ["/bin/sh", "-c", "sleep 100d"]
          env:
            - name: VERSION
              value: "version-1"

直接应用该资源对象即可：

 kubectl apply -f workload-demo.yaml
 kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
workload-demo-6c7764b765-69ls9   1/1     Running   0          25m
workload-demo-6c7764b765-9zxr7   1/1     Running   0          26m
workload-demo-6c7764b765-hrd55   1/1     Running   0          25m
workload-demo-6c7764b765-krhfd   1/1     Running   0          25m
workload-demo-6c7764b765-mvrdk   1/1     Running   0          25m
workload-demo-6c7764b765-qzzl2   1/1     Running   0          25m
workload-demo-6c7764b765-tgt4k   1/1     Running   0          26m
workload-demo-6c7764b765-tjgcg   1/1     Running   0          26m
workload-demo-6c7764b765-x5b94   1/1     Running   0          26m
workload-demo-6c7764b765-xj5hb   1/1     Running   0          26m

多批次更新策略

多批次更新策略是 Kruise Rollouts 的一个特性，它可以让你在更新工作负载时，可以控制每批次更新的 Pod 数量，以及每批次更新的时间间隔。

接下来我们需要创建一个 Rollout 对象来管理这个工作负载，比如我们想使用多批次更新策略将 Deployment 从 version-1​ 升级到 version-2。

  • 第 1 批：只升级 1 个 Pod。
  • 在第 2 批中：50% 的 Pod 应该升级，即 5 个更新的 Pod。
  • 在第 3 批中：100% 的 Pod 应该被升级，即 10 个更新的 Pod。

多批次更新策略

目前，多批次更新策略可以在 CloneSet、StatefulSet、Advanced StatefulSet 和 Deployment 上工作。

那么我们可以创建如下所示的 Rollout 对象：

# rollouts-demo.yaml
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
  namespace: default
  annotations:
    rollouts.kruise.io/rolling-style: partition # 使用多批次更新策略，只能配置 "partition" or "canary"
    # "partition" 意味着像 CloneSet 一样分批滚动，不会创建任何额外的 Workload
    # “canary” 表示以金丝雀方式滚动，并将创建一个金丝雀工作负载，对于Deployment默认是canary
spec:
  objectRef: # 定义工作负载
    workloadRef: # 关联需要管理的工作负载
      apiVersion: apps/v1
      kind: Deployment
      name: workload-demo
  strategy: # 定义升级策略
    canary: # 使用 Canary 策略
      steps: # 定义多批次更新策略
        - replicas: 1
        - replicas: 50%
        - replicas: 100%

直接创建该 Rollout 对象即可。

 kubectl apply -f rollouts-demo.yaml
 kubectl get rollout
NAME            STATUS    CANARY_STEP   CANARY_STATE   MESSAGE                            AGE
rollouts-demo   Healthy   3             Completed      workload deployment is completed   6s

创建 Rollout 对象后，其实已经开始管理工作负载了，上面的 kubectl get rollout 命令可以看到 Rollout 的状态为 Healthy，但现在工作负载的版本还是 version-1，我们可以通过将 Deployment 升级到 version-2 版本，来观察下 Rollout 的状态变化。

 kubectl patch deployment workload-demo -p \
'{"spec":{"template":{"spec":{"containers":[{"name":"busybox", "env":[{"name":"VERSION", "value":"version-2"}]}]}}}}'

稍等片刻，我们会看到 Deployment 更新了一个 Pod：

 kubectl get deploy
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
workload-demo   10/10   1            10          30m
 kubectl get replicaset
NAME                       DESIRED   CURRENT   READY   AGE
workload-demo-6c7764b765   9         9         9       30m
workload-demo-6dd59d49b5   1         1         1       34s
 kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
workload-demo-6c7764b765-69ls9   1/1     Running   0          30m
workload-demo-6c7764b765-hrd55   1/1     Running   0          30m
workload-demo-6c7764b765-krhfd   1/1     Running   0          30m
workload-demo-6c7764b765-mvrdk   1/1     Running   0          30m
workload-demo-6c7764b765-qzzl2   1/1     Running   0          30m
workload-demo-6c7764b765-tgt4k   1/1     Running   0          31m
workload-demo-6c7764b765-tjgcg   1/1     Running   0          31m
workload-demo-6c7764b765-x5b94   1/1     Running   0          31m
workload-demo-6c7764b765-xj5hb   1/1     Running   0          31m
workload-demo-6dd59d49b5-mpthm   1/1     Running   0          52s

现在我们再查看 Rollout 的状态：

 kubectl describe rollout rollouts-demo
Name:         rollouts-demo
Namespace:    default
Labels:       
Annotations:  rollouts.kruise.io/hash: 77cxd69w47b7bwddwv2w7vxvb4xxdbwcx9x289vw69w788w4w6z4x8dd4vbz2zbw
              rollouts.kruise.io/rolling-style: partition
API Version:  rollouts.kruise.io/v1alpha1
Kind:         Rollout
# ......
Status:
  Canary Status:
    Canary Ready Replicas:         1
    Canary Replicas:               1
    Canary Revision:               6dd59d49b5
    Current Step Index:            1
    Current Step State:            StepPaused
    Last Update Time:              2023-04-08T07:27:24Z
    Message:                       BatchRelease is at state Ready, rollout-id , step 1
    Observed Workload Generation:  8
    Pod Template Hash:             6dd59d49b5
    Rollout Hash:                  77cxd69w47b7bwddwv2w7vxvb4xxdbwcx9x289vw69w788w4w6z4x8dd4vbz2zbw
    Stable Revision:               6c7764b765
  Conditions:
    Last Transition Time:  2023-04-08T07:27:16Z
    Last Update Time:      2023-04-08T07:27:16Z
    Message:               Rollout is in Progressing
    Reason:                InRolling
    Status:                True
    Type:                  Progressing
  Message:                 Rollout is in step(1/3), and you need manually confirm to enter the next step
  Observed Generation:     2
  Phase:                   Progressing
Events:
  Type    Reason       Age   From                Message
  ----    ------       ----  ----                -------
  Normal  Progressing  110s  rollout-controller  upgrade step(1) canary pods with new versions done
 kubectl get rollout
NAME            STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                         AGE
rollouts-demo   Progressing   1             StepPaused     Rollout is in step(1/3), and you need manually confirm to enter the next step   6m17s

可以看到现在 Rollout 的状态为 Progressing，并且在第 1 步，当前的金丝雀状态为 StepPaused，这是因为我们使用了 partition 策略，需要手动确认才能进入下一步。

为了方便手动确认，我们可以安装使用 kubectl-kruise 这个插件。如果你已经安装过 Krew 这个插件，那么可以直接通过 kubectl krew install kruise-tools 来安装。

如果没有安装 Krew，可以直接前往 Release 页面 下载对应的二进制文件，然后将其放到 PATH 路径下即可。

 tar -xvf kubectl-kruise-darwin-arm64.tar.gz
 sudo mv darwin-arm64/kubectl-kruise /usr/local/bin/

然后就可以使用 kubectl-kruise 或者 kubectl kruise 命令了：

 kubectl-kruise --help
# or
 kubectl kruise --help

kubectl-kruise 插件安装完成后，我们就可以通过 kubectl-kruise rollout approve 命令来手动确认继续发布第二批次了：

 kubectl kruise rollout approve rollout/rollouts-demo -n default
rollout.rollouts.kruise.io/rollouts-demo approved

确认后现在我们再去查看下现在工作负载的状态：

 kubectl get deploy
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
workload-demo   10/10   5            10          45m
 kubectl get replicaset
NAME                       DESIRED   CURRENT   READY   AGE
workload-demo-6c7764b765   5         5         5       45m
workload-demo-6dd59d49b5   5         5         5       15m
 kubectl get rollout
NAME            STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                         AGE
rollouts-demo   Progressing   2             StepPaused     Rollout is in step(2/3), and you need manually confirm to enter the next step   18m

可以看到现在工作负载已经有 5 个是新版本的了，Rollout 对象也已经进入了第 2 步，如果我们再次手动确认，那么就会进入第 3 步，然后就会将所有的工作负载全部更新为新版本。

继续执行确认操作：

 kubectl kruise rollout approve rollout/rollouts-demo -n default
rollout.rollouts.kruise.io/rollouts-demo approved

可以看到现在工作负载已经全部更新为新版本了，Rollout 对象也显示金丝雀发布已经完成：

 kubectl get deploy
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
workload-demo   10/10   10           10          47m
 kubectl get replicaset
NAME                       DESIRED   CURRENT   READY   AGE
workload-demo-6c7764b765   0         0         0       48m
workload-demo-6dd59d49b5   10        10        10      17m
 kubectl get rollout
NAME            STATUS    CANARY_STEP   CANARY_STATE   MESSAGE                                  AGE
rollouts-demo   Healthy   3             Completed      Rollout progressing has been completed   21m

到这里我们的分批次发布就完成了。

上面我们使用 kubectl kruise rollout approve 命令来进行手动确认的，那么还有其他方法吗？目前，有两种方法，例如，如果你已完成第一批并要发送第二批：

  • 方法一：可以将第一批的 pause.duration 字段设置为 duration:0，会自动进入下一批。
  • 方法二：可以更新 rollout.status.canaryStatus.currentStepState 字段为 StepReady，同样会自动进入下一批次。

这两种方法都有自己的优点和缺点：

  • 对于第一种方法，它可以确保你的操作幂等性，但是在下一个发布之前，你需要将发布策略重置回其原始状态（例如，将持续 duration 重置为 nil）
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - replicas: 1
          pause:
            duration: 0
        - ... ...
  • 对于方法二，你无需在下一次发布之前更改任何内容。不过在确认之前，需要查看 Rollout 的状态，使用 update 接口，而不是 Kubernetes 客户端的 patch 接口，或者使用我们的 kubectl-kruise 工具，也就是上面我们使用的方法。
 kubectl kruise rollout approve rollout/ -n

那么如果现在我们想要回滚操作怎么办呢？事实上，Kruise Rollout 不提供直接回滚的能力。Kruise Rollout 更喜欢用户可以直接回滚工作负载规范来回滚他们的应用程序。当用户需要从 version-2​ 回滚到 version-1 时，Kruise Rollout 会使用原生的滚动升级策略快速回滚，而不是遵循 multi-batch checkpoint 策略。

此外还有一些其他注意事项值得我们注意：

  • 持续发布：假设 Rollout 正在从 version-1 发布到 version-2（未完成）。现在，工作负载被修改为 version-3，Rollout 将从开始步骤（第一步）开始进行。
  • HPA 兼容性：假设你将 HPA 配置为你的工作负载并使用多批更新策略，我们建议使用百分比来指定 steps[x].replicas。如果在 rollout 过程中副本被放大/缩小，旧版本和新版本副本将根据百分比配置进行缩放。

金丝雀发布策略

金丝雀发布策略允许用户在发布新版本时，将流量分配给新版本的一小部分，以便在发布新版本之前，可以对其进行测试。如果测试通过，则可以将流量分配给新版本的所有副本，否则可以回滚到旧版本。

目前金丝雀发布策略只支持 Deployment 工作负载。

金丝雀发布策略

比如现在我们有一个如下所示的 Deployment 工作负载：

# workload-canary-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
  labels:
    app: echoserver
spec:
  replicas: 5
  selector:
    matchLabels:
      app: echoserver
  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
        - name: echoserver
          image: registry.aliyuncs.com/google_containers/echoserver:1.10
          ports:
            - containerPort: 8080
          env:
            - name: VERSION # 表示当前是 v1 版本
              value: v1
            - name: NODE_NAME # 这里我们使用该环境变量来表示版本，这样后续只需要更改该环境变量的值即可
              value: version1
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
# nginx ingress 配置
---
apiVersion: v1
kind: Service
metadata:
  name: echoserver
  labels:
    app: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: echoserver
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserver
spec:
  ingressClassName: nginx
  rules:
    - host: echo.k8s.local
      http:
        paths:
          - path: /apis/echo
            pathType: Exact
            backend:
              service:
                name: echoserver
                port:
                  number: 80

由于要我们这里要使用金丝雀发布策略，所以需要指定流量来源，这里我们使用 Ingress 来指定流量来源。在 Ingress 中，我们指定了 echo.k8s.local 作为域名，然后在 paths 中指定了 /apis/echo 作为路径。

直接应用上面的资源对象即可：

 kubectl apply -f workload-canary-demo.yaml
 kubectl get ingress echoserver
NAME         CLASS   HOSTS            ADDRESS       PORTS   AGE
echoserver   nginx   echo.k8s.local   10.98.12.94   80      2m42s
 kubectl get svc echoserver
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
echoserver   ClusterIP   10.97.158.14           80/TCP    2m48s
 kubectl get pods -l app=echoserver
NAME                          READY   STATUS    RESTARTS   AGE
echoserver-6995b4bc86-4dzvb   1/1     Running   0          2m54s
echoserver-6995b4bc86-9b4qg   1/1     Running   0          2m54s
echoserver-6995b4bc86-bl82m   1/1     Running   0          2m54s
echoserver-6995b4bc86-n27v7   1/1     Running   0          2m54s
echoserver-6995b4bc86-wgjwp   1/1     Running   0          2m54s

部署后我们就可以通过 http://echo.k8s.local/apis/echo 来访问我们的服务了。

echo 服务

然后接下来我们就可以使用 Rollout 来进行金丝雀发布了，定义一个如下所示的 Rollout 对象：

# rollout-canary-demo.yaml
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-canary-demo
  annotations:
    rollouts.kruise.io/rolling-style: canary # 指定金丝雀发布策略
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: echoserver
  strategy:
    canary: # 金丝雀发布策略
      steps: # 步骤
        - weight: 5 # 导入5%的流量
          pause: {} # 表示人工确认
          replicas: 1 # 第一批发布的副本个数
        - weight: 40 # 导入40%的流量，没有配置 replicas，也表示发布40%的副本数
          pause: { duration: 30 } # 不需要人工确认，等待30s继续下一批
        - weight: 60
          pause: { duration: 30 }
        - weight: 80
          pause: { duration: 30 }
        - weight: 100
          pause: { duration: 10 }
      trafficRoutings: # 流量路由
        - service: echoserver
          ingress:
            classType: nginx
            name: echoserver

同样直接应用上面的资源对象即可：

 kubectl apply -f rollout-canary-demo.yaml
rollout.kruise.io/rollouts-canary-demo created
 kubectl get rollout rollouts-canary-demo
NAME                   STATUS    CANARY_STEP   CANARY_STATE   MESSAGE                            AGE
rollouts-canary-demo   Healthy   5             Completed      workload deployment is completed   2m53s

目前第一次不会有任何变化，当我们进行下一次发布的时候才能看到效果，比如这里我们修改一下 workload-canary-demo.yaml 中的 NODE_NAME 环境变量，将其修改为 version2，然后再次应用，这样就会触发一次新的发布。

我们可以开一个新的终端来查看工作负载的版本变化：

 while true; do curl -s http://echo.k8s.local/apis/echo |grep node; sleep 1; done

应用后我们再次查看工作负载的变化：

 kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
echoserver         
                当前标题：渐进式交付组件KruiseRollouts使用
                

                网站URL：http://www.stwzsj.com/qtweb/news28/13278.html
            

            

                网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等
                                

            

                广告
                
            

            

                声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：
                创新互联

猜你还喜欢下面的内容

软件开发知识

分类信息网

重庆移动机房托管　　 　绵阳服务器托管　　 　自适应网站　　 　成都包装设计公司　　 　四川成都网站设计　　 　ios开发　　 　教育建设方案　　 　绵阳梓潼做网站　　 　成都主机托管　　 　成都企业网站定制　　 　成都移动托管　　 　网站优化排名　　 　堡垒主机　　 　简阳机房托管　　 　成都包装盒设计　　 　标志设计　　 　成都网站制作　　 　电子商务商城网站　　 　广元双南建站　　 　盐亭网站制作公司