k8s灰度发布配置

在现代微服务架构中，应用的更新和发布是一个高频且关键的操作。如何在不影响用户体验的前提下，安全、平稳地将新版本应用推送到生产环境，是每个开发者和运维团队必须面对的挑战。灰度发布（Gray Release）作为一种渐进式发布策略，能够有效降低发布风险，而 Kubernetes 的 Ingress 注解功能为我们提供了一种简单而强大的实现方式。

灰度发布，也称为金丝雀发布（Canary Release），是一种渐进式的应用发布策略。它的核心思想是：将新版本应用逐步推送给一小部分用户，观察其运行状态，确认无误后再逐步扩大范围，最终完成全量发布。

相比于全量发布，灰度发布具有以下优势：

1. 降低风险：通过小范围验证，避免因新版本问题导致全局故障。
2. 快速回滚：如果新版本出现问题，可以快速切换回旧版本。
3. 用户体验优化：逐步发布可以减少对用户的影响。

Kubernetes 中的灰度发布实现方式

在 Kubernetes 中，灰度发布可以通过多种方式实现，例如：

• Istio：通过服务网格实现高级流量管理。
• Ingress 注解：通过 Nginx Ingress Controller 的注解功能实现流量分割。
• Deployment + Service：手动控制流量切换。

通过Istio实现灰度发布

之前在Istio服务网格篇已经讲解过：服务网格Istio安装及使用 | 逸贤 | Blog

通过 Ingress 注解实现灰度发布

Nginx Ingress Controller 提供了丰富的注解（Annotations），可以轻松实现灰度发布。以下是具体步骤：

部署新旧版本应用

首先，我们需要部署两个版本的应用程序：

• 旧版本（v1）：当前正在运行的生产版本。
• 新版本（v2）：待发布的新版本。

创建 v1 版本 Deployment 和 Service

# v1 版本 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
        version: v1
    spec:
      containers:
      - name: my-app
        image: my-app:v1
        ports:
        - containerPort: 80

# v1 版本 Service
apiVersion: v1
kind: Service
metadata:
  name: my-app-v1
spec:
  selector:
    app: my-app
    version: v1
  ports:
  - port: 80
    targetPort: 80

创建 v2 版本 Deployment 和 Service

# v2 版本 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
        version: v2
    spec:
      containers:
      - name: my-app
        image: my-app:v2
        ports:
        - containerPort: 80

# v2 版本 Service
apiVersion: v1
kind: Service
metadata:
  name: my-app-v2
spec:
  selector:
    app: my-app
    version: v2
  ports:
  - port: 80
    targetPort: 80

配置 Ingress 实现灰度发布

通过 Nginx Ingress Controller 的 canary 注解，我们可以轻松实现流量分割。

创建 Ingress 资源

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"  # 启用灰度发布
    nginx.ingress.kubernetes.io/canary-weight: "10"  # 10% 流量到新版本
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2  # 新版本服务
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1  # 旧版本服务
            port:
              number: 80

关键注解说明：

• nginx.ingress.kubernetes.io/canary: "true"：启用灰度发布功能。
• nginx.ingress.kubernetes.io/canary-weight: "10"：将 10% 的流量分配到新版本（v2），剩余 90% 的流量继续使用旧版本（v1）。

逐步调整流量权重

在灰度发布过程中，可以逐步增加新版本的流量比例。例如：

• 初始阶段：10% 流量到 v2。
• 验证通过后：将权重调整为 50%。
• 最终阶段：将权重调整为 100%，完成全量发布。

只需修改 canary-weight 注解的值即可：

nginx.ingress.kubernetes.io/canary-weight: "50"  # 50% 流量到新版本

监控与回滚

在灰度发布过程中，务必监控新版本的运行状态，包括：

• 应用日志：检查是否有错误或异常。
• 性能指标：如响应时间、错误率等。
• 用户反馈：收集用户的使用体验。

如果发现问题，可以通过调整 canary-weight 注解将流量切回旧版本：

nginx.ingress.kubernetes.io/canary-weight: "0"  # 所有流量切回旧版本

灰度发布的进阶用法

除了基于权重的流量分割，Nginx Ingress Controller 还支持以下灰度发布策略：

基于请求头的流量分割

通过 nginx.ingress.kubernetes.io/canary-by-header 注解，将特定请求头的流量路由到新版本。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1
            port:
              number: 80

说明

• 当请求头中包含 X-Canary: true 时，流量会被路由到新版本（v2）。
• 其他请求继续使用旧版本（v1）。

基于 Cookie 的流量分割

过 nginx.ingress.kubernetes.io/canary-by-cookie 注解，将特定 Cookie 的流量路由到新版本。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1
            port:
              number: 80

说明

• 当请求中包含 canary=true 的 Cookie 时，流量会被路由到新版本（v2）。
• 其他请求继续使用旧版本（v1）。

组合使用

可以同时使用权重、请求头和 Cookie 实现更复杂的灰度发布策略。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1
            port:
              number: 80

说明

• 10% 的流量会被分配到新版本（v2）。
• 如果请求头中包含 X-Canary: true 或 Cookie 中包含 canary=true，流量也会被路由到新版本。

通过Deployment+Service实现

deploy-blue.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hellok8s
      version: "1.0"
  template:
    metadata:
      labels:
        app: hellok8s
        version: "1.0"
    spec:
      containers:
      - name: hellok8s
        image: hellok8s:1.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

运行并查看：

kubectl apply -f deploy-blue.yaml
kubectl get pod -owide

在另一个终端开启监控：

kubectl get pod -owide -w

执行更新并暂停：

kubectl set image deploy deploy-blue hellok8s=hellok8s:2.0 && kubectl rollout pause deploy deploy-blue

命令说明：

set image 命令用来给工作负载更新镜像。命令格式为：
kubectl set image deploy deploy-name container-name=image-name:image-tag

&& 表示上一条命令执行成功之后才执行下一条命令

rollout pause 命令用来暂停滚动更新过程。命令格式为：
kubectl rollout pause deploy deploy-name

查看监控：

一个新的pod会被创建，与此同时所有旧的pod还在运行。
一旦新的pod成功运行，服务的一部分请求将被切换到新的pod。这样相当于运行了一个金丝雀版本。金丝雀发布是一种可以将应用程序的出错版本和其影响到的用户的风险化为最小的技术。与其直接向每个用户发布新版本，不如用新版本替换一个或一小部分的pod。通过这种方式，在升级的初期只有少数用户会访问新版本。验证新版本是否正常工作之后，可以将剩余的pod继续升级或者回滚到上一个的版本。

查看部署详情：会发现 paused 被系统设置为 true

kubectl get deploy deploy-blue -ojson

执行回滚：

kubectl rollout undo deploy deploy-blue

它会提示你，要先恢复（resume）rollout 过程，然后才能执行回滚命令。

恢复 Rollout：

kubectl rollout resume deployment/deploy-blue

查看监控：

可以看到，所有的 pod，都已被更新成新版。

执行回滚（现在可以正常回滚了）：

kubectl rollout undo deploy deploy-blue

Deployment pause 的金丝雀发布是一种伪金丝雀发布，它有以下几个问题：

1）在滚动升级过程中，想要在⼀个确切的位置暂停滚动升级无法做到。
2）无法实现流量的按比例分配。
3）需要恢复更新才能执行回滚。相当于将有问题的版本全部更新完才能回滚，将影响面扩大化了。可以使用 kubectl set image 旧版本来规避 kubectl rollout resume

还有一种就是deployment+service灰度发布的方式就是部署新旧版本的deployment，新旧版本应用使用同样的lable，service会关联新旧版本的deployment，通过控制新旧版本的pod数量来控制发布比例。