Istio实现 Kubernetes 多集群 Canary 部署
https://mp.weixin.qq.com/s/pxGBT9SXdjk0-Td4C1w_Jw
随着微服务架构的普及，企业对应用的高可用性和灵活性提出了更高的要求。在 Kubernetes 环境中，单集群的部署虽然简单，但在集群故障时会导致服务中断。通过 Istio，我们可以实现多集群服务网格，解决跨集群服务发现和通信的问题，同时还能实现 Canary 部署，以安全、渐进的方式发布新版本服务。
本文将带您深入了解如何使用 Istio 构建多集群服务网格，并实现 Canary 部署，以确保应用升级的安全性和稳定性。
@rarun.unofficial/implementing-canary-deployments-on-multi-cluster-kubernetes-with-istio-68241f7ed406"target="_blank"">https://medium.com/@rarun.unofficial/implementing-canary-deployments-on-multi-cluster-kubernetes-with-istio-68241f7ed406
Canary 部署的核心理念
Canary 部署的灵感来源于矿井中的“金丝雀”——通过让一小部分用户先行体验新版本，验证其稳定性和功能。如果新版本表现良好，则逐步增加流量直至全量发布；如果出现问题，则快速回滚，将影响控制在最小范围内。
在 Kubernetes 环境中，Canary 部署的关键在于流量分配的精准控制。而 Istio 通过其强大的路由规则和流量管理功能，成为实现这一目标的理想工具。
Istio 流量管理的核心组件
Istio 提供以下核心资源，帮助我们实现 Canary 部署：
• DestinationRule：定义服务的不同版本（子集），通过标签区分不同版本的 Pod，为流量分配奠定基础。
• VirtualService：定义流量路由规则，支持基于权重（weight）的流量分配，允许将特定比例的流量引导至不同版本。
Istio 的 Sidecar 代理（Envoy）将这些规则应用于服务间的通信，无需修改应用代码即可实现复杂的流量控制。
实战场景：多集群环境下的 Canary 部署
为了展示 Istio 在 Canary 部署中的强大能力，我们以一个多集群场景为例，逐步实现新版本的渐进式发布。
场景描述
假设我们有一个名为 “Bookinfo” 的微服务应用，部署在两个 Kubernetes 集群（分别位于eu-west和us-east region）中。这两个集群通过 Istio 组成统一的服务网格。初始状态下，productpage 和 reviews:v1 服务部署在两个集群中，实现跨集群负载均衡。
现在，我们需要发布 reviews 服务的 v2 版本。为了降低风险，我们选择在eu-west集群先行部署 v2 作为 Canary 版本，并将 20% 的流量引导至新版本。
初始架构图
初始架构图
步骤 1：定义服务版本（DestinationRule）
首先，在两个集群上应用 DestinationRule，让 Istio 识别 reviews 服务的不同版本。
# reviews-destination-rule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
namespace: sample
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
• host: reviews：指定规则应用于 reviews 服务。
• subsets：定义了 v1 和 v2 两个版本，通过 version 标签区分 Pod。
步骤 2：部署 Canary 版本（reviews:v2）
在eu-west集群中部署 reviews:v2 版本：
# 仅在eu-west集群执行
kubectl -n sample apply -f https://gist.githubusercontent.com/rathnaarun77/05ccb7b8d8fa51fec67096d18ba25a36/raw/
此时，即使 v2 版本已部署，由于没有路由规则指向它，流量仍不会到达新版本。Istio 将部署与发布完全解耦，确保新版本不会意外影响现有服务。
步骤 3：配置流量分配（VirtualService）
接下来，在两个集群上应用 VirtualService，将 20% 的流量分配给 v2 版本，80% 仍指向 v1 版本。
# reviews-virtual-service-canary.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
namespace: sample
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 80
- destination:
host: reviews
subset: v2
weight: 20• weight: 80 / weight: 20：Istio 将严格按照 80/20 的比例分配流量。即使 v2 版本部署在eu-west集群，来自us-east集群的请求也会有 20% 被路由到 v2，这一切对应用是完全透明的。
应用此规则后的架构如下：
Canary 部署架构图
Canary 部署架构图
步骤 4：验证与调整
• 验证效果：通过多次刷新 productpage 的 UI（访问地址：http://localhost:9080/productpage?u=normal），观察约 20% 的请求被路由到 v2 版本。同时，使用监控工具（如 Prometheus 和 Grafana）检查 v2 版本的性能指标。
• 逐步推广：若 v2 版本稳定，可逐步调整 VirtualService 中的 weight 值，例如将流量比例调整为 50/50，最终到 0/100，实现全量发布。
• 快速回滚：若 v2 版本出现问题，只需将 weight 值改回 100/0，即可在数秒内完成回滚。
Istio 在 Canary 部署中的优势
- 无侵入性：Istio 的流量管理完全在基础设施层实现，无需修改应用代码。
- 跨集群支持：即使新版本部署在远程集群，Istio 也能通过东西向网关（East-West Gateway）实现无缝路由。
- 灵活性：支持基于权重、HTTP 头、用户身份等多种规则的流量分配，满足复杂场景需求。
- 实时性：流量规则的变更几乎实时生效，支持快速调整和回滚。
总结
Istio 通过 DestinationRule 和 VirtualService 提供的强大流量管理能力，使 Canary 部署变得简单而高效。无论是单集群还是多集群环境，Istio 都能帮助团队以最小的风险交付新功能，真正实现敏捷开发与持续交付。
