Kubernetes 金丝雀发布经典案例实战

在现代微服务架构中，应用发布风险 是一个核心问题。直接全量替换部署可能导致生产环境大面积故障。

金丝雀发布（Canary Release） 是一种安全、渐进的发布策略，它允许我们在一小部分用户中测试新版本的应用，确认稳定后再逐步扩展到全部用户。

本文将通过一个 经典 Nginx Web 服务的金丝雀发布案例，结合 K8s Deployment + Service + Istio VirtualService，完整演示如何实现。

一、实验环境准备

• Kubernetes 集群（>= v1.24）
• 已安装 Istio Ingress Gateway
• kubectl 客户端
• 一个示例应用（Nginx 作为 v1 / v2 版本）

二、案例架构说明

1. 初始运行 v1 版本的 Nginx（显示“Welcome v1”）。
2. 发布新版本 v2（显示“Welcome v2”）。
3. 使用 Istio VirtualService 将 10% 流量 引导到 v2，其余 90% 保持在 v1。
4. 验证 v2 稳定后逐步扩大流量，最终替换 v1。

三、源代码与步骤

1. 部署 Nginx v1 版本

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-v1

labels:

app: nginx

version: v1

spec:

replicas: 3

selector:

matchLabels:

app: nginx

version: v1

template:

metadata:

labels:

app: nginx

version: v1

spec:

containers:

- name: nginx

image: nginx:1.21

ports:

- containerPort: 80

volumeMounts:

- name: html

mountPath: /usr/share/nginx/html

volumes:

- name: html

configMap:

name: nginx-v1-html

---

apiVersion: v1

kind: ConfigMap

metadata:

name: nginx-v1-html

data:

index.html: |

<h1>Welcome v1</h1>

2. 部署 Nginx v2 版本

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-v2

labels:

app: nginx

version: v2

spec:

replicas: 2

selector:

matchLabels:

app: nginx

version: v2

template:

metadata:

labels:

app: nginx

version: v2

spec:

containers:

- name: nginx

image: nginx:1.21

ports:

- containerPort: 80

volumeMounts:

- name: html

mountPath: /usr/share/nginx/html

volumes:

- name: html

configMap:

name: nginx-v2-html

---

apiVersion: v1

kind: ConfigMap

metadata:

name: nginx-v2-html

data:

index.html: |

<h1>Welcome v2</h1>

3. 定义统一 Service（v1 + v2）

apiVersion: v1

kind: Service

metadata:

name: nginx-svc

spec:

selector:

app: nginx

ports:

- port: 80

targetPort: 80

4. 配置 Istio VirtualService（流量按比例分配）

apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

name: nginx-destination

spec:

host: nginx-svc

subsets:

- name: v1

labels:

version: v1

- name: v2

labels:

version: v2

---

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: nginx-canary

spec:

hosts:

- "*"

gateways:

- istio-system/ingressgateway

http:

- route:

- destination:

host: nginx-svc

subset: v1

weight: 90

- destination:

host: nginx-svc

subset: v2

weight: 10

四、测试与验证

1. 部署所有资源：

kubectl apply -f nginx-v1.yaml

kubectl apply -f nginx-v2.yaml

kubectl apply -f nginx-svc.yaml

kubectl apply -f nginx-canary.yaml

1. 获取 Ingress Gateway 地址：

kubectl get svc -n istio-system

2. 连续访问应用：

curl http://<GATEWAY_IP>

3. 大约 90% 返回：

<h1>Welcome v1</h1>

3. 10% 返回：

<h1>Welcome v2</h1>

五、金丝雀扩展与替换

如果测试验证 v2 稳定，可逐步调整 VirtualService 的权重：

• 50% / 50%
• 80% / 20%
• 100% v2，0% v1

直到 v1 可以安全下线。

六、总结

• 金丝雀发布 提供了一种平滑过渡新版本的方式，避免全量替换导致的生产事故。
• 借助 Kubernetes + Istio，我们可以超级灵活地对流量进行细粒度控制。
• 实战中，还可以结合 Prometheus + Grafana 进行监控，确保在金丝雀阶段及时发现问题。

这个案例可以直接在你的 K8s + Istio 环境落地运行。