应用灰度发布

Canary Deployment 是一种渐进式发布策略，它会将新的应用版本逐步引入到一小部分用户或流量中。这种增量式发布方式允许团队在全面部署之前监控系统行为、收集指标并确保稳定性。该方法能够显著降低风险，尤其是在生产环境中。

Argo Rollouts 是一个 Kubernetes 原生的渐进式交付控制器，可支持高级部署策略。它通过提供 Canary、Blue-Green Deployments、Analysis Runs、Experimentation 和 Automated Rollbacks 等功能扩展了 Kubernetes 能力。它与可观测性栈集成，用于基于指标的健康检查，并提供基于 CLI 和监控面板的应用交付控制。

关键概念：

Rollout：Kubernetes 中的一个 Custom Resource Definition（CRD），用于替代标准的 Deployment 资源，从而支持 blue-green、canary deployment 等高级部署控制。

Canary Steps：一系列增量式流量切换操作，例如先将 25% 的流量，再将 50% 的流量导向新版本。

Pause Steps：在进入下一个 canary step 之前引入等待间隔，以便进行手动或自动验证。

灰度发布的优势

风险缓解：通过先将变更部署到少量服务器上，你可以在全面发布前发现并处理问题，从而将对用户的影响降到最低。
增量式发布：这种方式允许逐步暴露新功能，有助于你有效监控性能和用户反馈。
实时反馈：灰度发布可以在真实环境条件下，立即提供新版本性能和稳定性的洞察。
灵活性：你可以根据性能指标调整部署过程。这使得你能够按需暂停或回滚，实现动态发布。
成本效益：与 blue/green deployments 不同，canary deployments 不需要单独的环境，因此资源利用率更高。

使用 Argo Rollouts 进行灰度发布

Argo Rollouts 支持 canary deployment 策略来发布 Deployment，并通过 Gateway API Plugin 控制流量。在 ACP 中，你可以使用 ALB 作为 Gateway API Provider 来实现 Argo Rollouts 的流量控制。

前提条件

集群中已安装带有 Gateway API plugin 的 Argo Rollouts。
Argo Rollouts kubectl plugin（可从 here 安装）。
一个用于创建 namespace 的 project。
集群中已部署 ALB，并已分配给该 project。
集群中一个用于部署应用的 namespace。

操作步骤

创建 Deployment

首先定义应用的“stable”版本。这是用户当前访问的版本。创建一个 Kubernetes Deployment，并设置合适的副本数、容器镜像版本（例如 hello:1.23.1）以及正确的标签，例如 app=web。

使用以下 YAML：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: hello:1.23.1
          ports:
            - containerPort: 80

YAML 字段说明：

apiVersion：用于创建该资源的 Kubernetes API 版本。
kind：指定这是一个 Deployment 资源。
metadata.name：Deployment 的名称。
spec.replicas：期望的 Pod 副本数。
spec.selector.matchLabels：定义 Deployment 如何查找要管理的 Pod。
template.metadata.labels：应用到 Pod 的标签，供 Service 选择。
spec.containers：每个 Pod 中运行的容器。
containers.name：容器名称。
containers.image：要运行的容器镜像。
containers.ports.containerPort：容器暴露的端口。

使用 kubectl 应用配置：

kubectl apply -f deployment.yaml

这会设置生产环境。

另外，你也可以使用 Helm Chart 来创建这些 deployments 和 services。

创建 Stable Service

创建一个 Kubernetes Service 来暴露 stable deployment。该 Service 将根据匹配的标签，将流量转发到 stable 版本的 Pod。初始时，Service selector 目标是带有 app=web 标签的 Pod。

apiVersion: v1
kind: Service
metadata:
  name: web-stable
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

YAML 字段说明：

apiVersion：用于创建该 Service 的 Kubernetes API 版本。
kind：指定该资源是一个 Service。
metadata.name：Service 的名称。
spec.selector：根据标签标识要将流量路由到哪些 Pod。
ports.protocol：使用的协议（TCP）。
ports.port：Service 暴露的端口。
ports.targetPort：流量被转发到容器上的端口。

使用以下命令应用：

kubectl apply -f web-stable-service.yaml

这样即可从集群外访问 stable deployment。

创建 Canary Service

创建一个 Kubernetes Service 来暴露 canary deployment。该 Service 将根据匹配的标签，将流量转发到 canary 版本的 Pod。初始时，Service selector 目标是带有 app=web 标签的 Pod。

apiVersion: v1
kind: Service
metadata:
  name: web-canary
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

YAML 字段说明：

apiVersion：用于创建该 Service 的 Kubernetes API 版本。
kind：指定该资源是一个 Service。
metadata.name：Service 的名称。
spec.selector：根据标签标识要将流量路由到哪些 Pod。
ports.protocol：使用的协议（TCP）。
ports.port：Service 暴露的端口。
ports.targetPort：流量被转发到容器上的端口。

使用以下命令应用：

kubectl apply -f web-canary-service.yaml

这样即可从集群外访问 canary deployment。

创建 Gateway

使用 example.com 作为访问服务的域名，创建 Gateway 以通过该域名暴露服务：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: default
spec:
  gatewayClassName: exclusive-gateway
  listeners:
  - allowedRoutes:
      namespaces:
        from: All
    name: gateway-metric
    port: 11782
    protocol: TCP
  - allowedRoutes:
      namespaces:
        from: All
    hostname: example.com
    name: web
    port: 80
    protocol: HTTP

使用以下命令：

kubectl apply -f gateway.yaml

Gateway 将分配一个外部 IP 地址，请从 Gateway 资源中 status.addresses 里类型为 IPAddress 的条目获取该 IP 地址。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: default
...
status:
  addresses:
  - type: IPAddress
    value: 192.168.134.30

DNS 配置

在你的 DNS 服务器中配置该域名，将域名解析到 Gateway 的 IP 地址。使用以下命令验证 DNS 解析：

nslookup example.com
Server:         192.168.16.19
Address:        192.168.16.19#53

Non-authoritative answer:
Name:   example.com
Address: 192.168.134.30

它应该返回 Gateway 的地址。

创建 HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
spec:
  hostnames:
  - example.com
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: default
    namespace: default
    sectionName: web
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: web-canary
      namespace: default
      port: 80
      weight: 0
    - group: ""
      kind: Service
      name: web-stable
      namespace: default
      port: 80
      weight: 100
    matches:
    - path:
        type: PathPrefix
        value: /

使用以下命令：

kubectl apply -f httproute.yaml

访问 Stable Service

在集群外，使用以下命令通过域名访问服务：

curl http://example.com

或者，你也可以在浏览器中访问 http://example.com。

创建 Rollout

接下来，创建 Argo Rollouts 的 Rollout 资源，并使用 Canary 策略。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-canary
spec:
  minReadySeconds: 30
  replicas: 2
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: web
  strategy:
    canary:
      canaryService: web-canary
      maxSurge: 25%
      maxUnavailable: 0
      stableService: web-stable
      steps:
      - setWeight: 50
      - pause: {}
      - setWeight: 100
      trafficRouting:
        plugins:
          argoproj-labs/gatewayAPI:
            httpRoute: web
            namespace: default
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
    scaleDown: onsuccess

YAML 字段说明：

spec.selector：Pod 的标签选择器。此选择器所选中的现有 ReplicaSet 将受到该 Rollout 的影响。它必须与 Pod 模板的标签匹配。
workloadRef：指定 workload 引用以及要应用于 Rollout 的缩容策略。
scaleDown：指定在迁移到 Rollout 之后，workload（Deployment）是否缩容。可选项如下：
- "never"：Deployment 不会缩容。
- "onsuccess"：当 Rollout 变为健康状态后，Deployment 会缩容。
- "progressively"：随着 Rollout 扩容，Deployment 会同步缩容。如果 Rollout 失败，Deployment 将重新扩容。
strategy：Rollout 策略，支持 BlueGreen 和 Canary 策略。
canary：Canary Rollout 策略定义。
- canaryService：指向一个 Service 的引用，控制器将更新该 Service 以选择 canary Pod。流量路由时必填。
- stableService：指向一个 Service 的引用，控制器将更新该 Service 以选择 stable Pod。流量路由时必填。
- steps：定义更新 canary 时要执行的一系列步骤。首次部署 Rollout 时会跳过这些步骤。
  - setWeight：设置 canary ReplicaSet 的流量比例。
  - pause：无限期或按指定时长暂停 Rollout。支持的单位：s、m、h。{} 表示无限期。
  - plugin：执行已配置的插件，此处配置的是 gatewayAPI 插件。

使用以下命令应用：

kubectl apply -f rollout.yaml

这会为该 Deployment 设置 Canary 策略的 Rollout。它会先将权重设为 50，并等待晋级。50% 的流量将转发到 canary service。完成 Rollout 晋级后，权重将设为 100，100% 的流量将转发到 canary service。最终，canary service 将成为 stable service。

验证 Rollout

创建 Rollout 后，Argo Rollouts 会基于 Deployment 的相同模板创建一个新的 ReplicaSet。当新 ReplicaSet 的 Pod 处于健康状态时，Deployment 会缩容到 0。

使用以下命令确保 Pod 运行正常：

kubectl argo rollouts get rollout rollout-canary
Name:            rollout-canary
Namespace:       default
Status:          ✔ Healthy
Strategy:        Canary
Step:          9/9
SetWeight:     100
ActualWeight:  100
Images:          hello:1.23.1 (stable)
Replicas:
Desired:       2
Current:       2
Updated:       2
Ready:         2
Available:     2

NAME                                      KIND        STATUS     AGE  INFO
⟳ rollout-canary                            Rollout     ✔ Healthy  32s
└──# revision:1
  └──⧉ rollout-canary-5c9d79697b           ReplicaSet  ✔ Healthy  32s  stable
    ├──□ rollout-canary-5c9d79697b-fh78d  Pod         ✔ Running  32s  ready:1/1
    └──□ rollout-canary-5c9d79697b-rrbtj  Pod         ✔ Running  32s  ready:1/1

准备 Canary Deployment

接下来，将应用的新版本准备为 green deployment。使用新的镜像版本更新 Deployment web（例如 hello:1.23.2）。使用以下命令：

kubectl patch deployment web -p '{"spec":{"template":{"spec":{"containers":[{"name":"web","image":"hello:1.23.2"}]}}}}'

这会为测试准备新的应用版本。

Rollouts 会创建一个新的 ReplicaSet 来管理 canary Pod，并且 50% 的流量会转发到 canary Pod。使用以下命令进行验证：

kubectl argo rollouts get rollout rollout-canary
Name:            rollout-canary
Namespace:       default
Status:          ॥ Paused
Message:         CanaryPauseStep
Strategy:        Canary
Step:          1/3
SetWeight:     50
ActualWeight:  50
Images:          hello:1.23.1 (stable)
                hello:1.23.2 (canary)
Replicas:
Desired:       2
Current:       3
Updated:       1
Ready:         3
Available:     3

NAME                                      KIND        STATUS     AGE  INFO
⟳ rollout-canary                            Rollout     ॥ Paused   95s
├──# revision:2
│  └──⧉ rollout-canary-5898765588           ReplicaSet  ✔ Healthy  46s  canary
│     └──□ rollout-canary-5898765588-ls5jk  Pod         ✔ Running  45s  ready:1/1
└──# revision:1
  └──⧉ rollout-canary-5c9d79697b           ReplicaSet  ✔ Healthy  95s  stable
    ├──□ rollout-canary-5c9d79697b-fk269  Pod         ✔ Running  94s  ready:1/1
    └──□ rollout-canary-5c9d79697b-wkmcn  Pod         ✔ Running  94s  ready:1/1

当前有 3 个 Pod 在运行，分别是 stable 和 canary 版本。此时权重为 50，50% 的流量会转发到 canary service。Rollout 流程已暂停，等待晋级。

如果你使用 Helm Chart 部署应用，则使用 Helm 工具将应用升级到 canary 版本。

访问 http://example.com 时，50% 的流量将转发到 canary service。你应该会从该 URL 收到不同的响应。

晋级 Rollout

当 canary 版本测试通过后，你可以晋级 Rollout，将所有流量切换到 canary Pod。使用以下命令：

kubectl argo rollouts promote rollout-canary

验证 Rollout 是否完成：

kubectl argo rollouts get rollout rollout-canary
Name:            rollout-canary
Namespace:       default
Status:          ✔ Healthy
Strategy:        Canary
Step:          3/3
SetWeight:     100
ActualWeight:  100
Images:          hello:1.23.2 (stable)
Replicas:
Desired:       2
Current:       2
Updated:       2
Ready:         2
Available:     2

NAME                                      KIND        STATUS         AGE    INFO
⟳ rollout-canary                            Rollout     ✔ Healthy      8m42s
├──# revision:2
│  └──⧉ rollout-canary-5898765588           ReplicaSet  ✔ Healthy      7m53s  stable
│     ├──□ rollout-canary-5898765588-ls5jk  Pod         ✔ Running      7m52s  ready:1/1
│     └──□ rollout-canary-5898765588-dkfwg  Pod         ✔ Running      68s    ready:1/1
└──# revision:1
  └──⧉ rollout-canary-5c9d79697b           ReplicaSet  • ScaledDown   8m42s
    ├──□ rollout-canary-5c9d79697b-fk269  Pod         ◌ Terminating  8m41s  ready:1/1
    └──□ rollout-canary-5c9d79697b-wkmcn  Pod         ◌ Terminating  8m41s  ready:1/1

如果 stable 的 Images 已更新为 hello:1.23.2，并且 revision 1 的 ReplicaSet 已缩容为 0，则说明 Rollout 已完成。

访问 http://example.com 时，100% 的流量将转发到 canary service。

中止 Rollout（可选）

如果你在 Rollout 过程中发现 canary 版本存在问题，可以中止该流程，将所有流量切换回 stable service。使用以下命令：

kubectl argo rollouts abort rollout-canary

验证结果：

kubectl argo rollouts get rollout rollout-canary
Name:            rollout-demo
Namespace:       default
Status:          ✖ Degraded
Message:         RolloutAborted: Rollout aborted update to revision 3
Strategy:        Canary
Step:          0/3
SetWeight:     0
ActualWeight:  0
Images:          hello:1.23.1 (stable)
Replicas:
Desired:       2
Current:       2
Updated:       0
Ready:         2
Available:     2

NAME                                      KIND        STATUS        AGE  INFO
⟳ rollout-canary                            Rollout     ✖ Degraded    18m
├──# revision:3
│  └──⧉ rollout-canary-5c9d79697b           ReplicaSet  • ScaledDown  18m  canary,delay:passed
└──# revision:2
  └──⧉ rollout-canary-5898765588           ReplicaSet  ✔ Healthy     17m  stable
    ├──□ rollout-canary-5898765588-ls5jk  Pod         ✔ Running     17m  ready:1/1
    └──□ rollout-canary-5898765588-dkfwg  Pod         ✔ Running     10m  ready:1/1

访问 http://example.com 时，100% 的流量将转发到 stable service。

#应用灰度发布

#目录

#灰度发布的优势

#使用 Argo Rollouts 进行灰度发布

#前提条件

#操作步骤

#创建 Deployment

#创建 Stable Service

#创建 Canary Service

#创建 Gateway

#DNS 配置

#创建 HTTPRoute

#访问 Stable Service

#创建 Rollout

#验证 Rollout

#准备 Canary Deployment

#晋级 Rollout

#中止 Rollout（可选）

应用灰度发布

目录

灰度发布的优势

使用 Argo Rollouts 进行灰度发布

前提条件

操作步骤

创建 Deployment

创建 Stable Service

创建 Canary Service

创建 Gateway

DNS 配置

创建 HTTPRoute

访问 Stable Service

创建 Rollout

验证 Rollout

准备 Canary Deployment

晋级 Rollout

中止 Rollout（可选）