kubernetes灰度发布

frankcqy_coding

已于 2025-02-12 09:56:23 修改

阅读量630

点赞数 8

文章标签： kubernetes 容器云原生

于 2025-02-06 11:31:22 首次发布

本文链接：https://blog.youkuaiyun.com/Franklin7B/article/details/145469776

版权

在 Kubernetes 中实现灰度发布（金丝雀发布、蓝绿发布等）可以通过多种方法和工具实现，同时针对长连接请求的灰度发布问题也有对应的解决方案。以下是详细说明：

一、Kubernetes 中实现灰度发布的方法和工具

1. 原生 Kubernetes 方案

滚动更新（Rolling Update）
Kubernetes 的 Deployment 原生支持滚动更新策略，逐步替换旧 Pod。
- 特点：简单但无法精细控制流量，严格来说不是灰度发布，但可以分阶段更新（例如通过 maxSurge 和 maxUnavailable 参数）。
- 适用场景：无复杂流量控制需求的简单应用。

手动金丝雀发布
通过创建新版本 Deployment 并逐步调整 Service 流量权重。
步骤示例：

# 创建稳定版 Deployment（v1）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: v1
  template: { ... }

# 创建金丝雀版 Deployment（v2）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v2
spec:
  replicas: 1  # 初始少量副本
  selector:
    matchLabels:
      app: my-app
      version: v2
  template: { ... }

# 通过 Service 选择多个版本（需应用支持流量标识）
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app  # 同时选中 v1 和 v2 的 Pod
  ports: [ ... ]

缺点：需要应用层或 Ingress 配合流量分配（如基于请求头、Cookie 的路由）。

Ingress 控制器（如 Nginx Ingress）
使用 Ingress 的流量切分功能（例如基于权重或请求头）。
示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"  # 10% 流量到 v2
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          service:
            name: app-v2
            port: 80

2. 服务网格（Service Mesh）

Istio
通过 VirtualService 和 DestinationRule 实现精细流量控制。
示例：

# DestinationRule 定义子集（版本）
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

# VirtualService 分配流量
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app
  http:
  - route:
    - destination:
        host: my-app
        subset: v1
      weight: 90
    - destination:
        host: my-app
        subset: v2
      weight: 10

优势：支持基于权重、请求头、Cookie 等复杂路由规则。

Linkerd
类似 Istio，通过 TrafficSplit 资源实现流量切分。

3. 专用工具

Flagger
基于 Istio、Linkerd 或 App Mesh 的自动化金丝雀发布工具，支持渐进式流量切换和自动回滚。
- 监控指标（如请求成功率、延迟）自动决策是否继续发布。
- 集成：Prometheus、Datadog 等。

Argo Rollouts
提供蓝绿发布、金丝雀发布策略，支持手动或自动渐进式流量切换。
示例：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {}  # 等待人工确认
      - setWeight: 50
      - pause: { duration: 60 }  # 自动继续前等待 60 秒
  template: { ... }  # Pod 定义

二、解决灰度发布中的长连接问题

问题背景

在灰度发布过程中，若客户端使用长连接（如 WebSocket、gRPC 长连接），旧 Pod 的连接可能不会立即终止，导致部分请求仍被旧版本处理，影响灰度效果。

解决方案

优雅终止（Graceful Shutdown）
Kubernetes 默认会在终止 Pod 前发送 SIGTERM 信号，应用需在此阶段主动关闭长连接。
- 配置 preStop Hook：在 Pod 终止前等待现有连接完成。
```
lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 30"]  # 等待 30 秒以排空连接
```
- 应用层逻辑：收到终止信号后，停止接受新请求并等待现有连接完成。

服务网格的流量迁移
Istio 等工具支持主动排空（Drain）连接：

配置连接池超时：强制关闭空闲长连接。

# DestinationRule 中设置连接超时
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
spec:
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30ms
      http:
        http1MaxPendingRequests: 10
        maxRequestsPerConnection: 1  # 禁用长连接

逐步迁移：在灰度过程中，先切断新流量到旧 Pod，等待旧连接自然关闭后再终止 Pod。

应用层心跳机制
在长连接协议中设计心跳检测（如 WebSocket Ping/Pong），若客户端一段时间未响应，服务端主动断开连接。
- 结合服务网格或 Ingress 控制，确保新请求仅路由到新版本。
客户端重连逻辑
客户端应具备自动重连能力，在连接断开后重新发起请求，此时流量会被路由到新版本。

三、总结

灰度发布工具选择：
- 简单场景：原生 Deployment + Ingress 权重控制。
- 复杂场景：Istio/Argo Rollouts/Flagger + 服务网格。
长连接问题：
需结合优雅终止、服务网格流量控制和应用层设计（心跳、重连）共同解决。
验证与监控：
灰度过程中务必监控连接状态、错误率和延迟，使用工具（如 Prometheus + Grafana）实时分析。