1. 课程导学与实验环境准备：服务网格与金丝雀发布概述、课程目标、实验环境（K8s集群 + Istio）搭建与验证
1.1 服务网格与金丝雀发布概述
在微服务架构中，服务间通信的复杂性呈指数级增长。传统的客户端负载均衡、重试、熔断等逻辑通常嵌入在业务代码中，导致基础设施逻辑与业务逻辑耦合，难以统一治理。服务网格（Service Mesh）通过将通信层抽象为独立的基础设施层，以Sidecar代理模式透明地接管所有服务间流量，实现了流量管理、可观测性、安全策略的集中管控。
金丝雀发布（Canary Release）是一种渐进式发布策略，将新版本服务逐步引入生产环境，通过实时监控和流量控制，在影响范围最小化的前提下验证新版本的稳定性与正确性。当与Istio等服务网格结合时，金丝雀发布可以基于HTTP Header、Cookie、权重等丰富规则进行精细化流量路由，无需修改任何业务代码。
核心价值： 服务网格 + 金丝雀发布 = 零信任、可观测、可回滚的渐进式交付体系。
1.2 课程目标与学习路径
本课程旨在帮助学员从零搭建一套完整的服务网格流量拓扑实战环境，并掌握全链路金丝雀发布与回滚的核心技能。完成本章后，你将能够：
- 理解服务网格架构：掌握Istio控制面与数据面的核心组件及其交互关系。
- 搭建生产级实验环境：在Kubernetes集群上部署Istio，并验证Sidecar注入与流量拦截机制。
- 设计金丝雀发布策略：基于权重、Header、镜像流量等规则实现精细化灰度发布。
- 构建全链路可观测性：集成Kiali、Prometheus、Grafana，实时监控金丝雀发布过程中的流量拓扑与指标。
- 实现自动化回滚：基于健康检查与异常检测，配置自动回滚策略，保障生产环境稳定性。
| 章节 | 核心知识点 | 实战产出 |
|---|---|---|
| 第1章 | 服务网格概述、金丝雀发布原理、环境搭建 | K8s集群 + Istio 验证环境 |
| 第2-5章 | Istio流量管理、VirtualService/DestinationRule | 权重路由、Header路由、镜像流量 |
| 第6-10章 | 全链路金丝雀发布、可观测性集成 | Kiali拓扑图、Prometheus指标、Grafana仪表盘 |
| 第11-15章 | 异常检测、自动回滚、多集群部署 | 自动化回滚策略、跨集群金丝雀 |
1.3 实验环境架构设计
本课程采用单控制面、多数据面的标准Istio部署模式。实验环境包含以下核心组件：
- Kubernetes集群：1个Master节点 + 2个Worker节点，版本 ≥ 1.25，支持Sidecar注入。
- Istio控制面：istiod（Pilot、Citadel、Galley合并），负责服务发现、证书签发、配置分发。
- Istio数据面：Envoy Sidecar代理，注入到每个业务Pod中，拦截所有入站/出站流量。
- 示例微服务：基于Bookinfo应用的改造版本，包含productpage、details、reviews、ratings四个服务，支持多版本部署。
- 可观测性组件：Kiali（流量拓扑可视化）、Prometheus（指标采集）、Grafana（仪表盘展示）、Jaeger（分布式追踪）。
1.4 实验环境搭建步骤
以下步骤将指导你在已有Kubernetes集群上快速部署Istio并验证环境。假设你已经拥有一个可用的K8s集群（本地Minikube或云厂商托管集群均可）。
步骤1：下载并安装Istio CLI
# 下载指定版本（本课程使用1.20.x）
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.3 sh -
cd istio-1.20.3
export PATH=$PWD/bin:$PATH
# 验证安装
istioctl version步骤2：部署Istio控制面
# 使用demo配置文件（包含完整可观测性组件）
istioctl install --set profile=demo -y
# 验证控制面Pod状态
kubectl get pods -n istio-system
# 预期输出：istiod-xxx Running 1/1步骤3：启用Sidecar自动注入
# 为default命名空间启用自动注入
kubectl label namespace default istio-injection=enabled
# 验证标签
kubectl get namespace -L istio-injection
# 预期输出：default Active enabled步骤4：部署示例微服务（Bookinfo）
# 部署Bookinfo应用
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
# 验证所有Pod是否都包含2个容器（业务容器 + Envoy Sidecar）
kubectl get pods
# 预期输出：每个Pod的READY列为2/2步骤5：配置Ingress Gateway并验证访问
# 部署Gateway和VirtualService
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
# 获取Ingress Gateway外部IP
kubectl get svc istio-ingressgateway -n istio-system
# 访问 http://<EXTERNAL-IP>/productpage
# 预期：看到Bookinfo应用页面
验证检查点： 如果productpage页面正常显示，且每个Pod的READY列为2/2，说明Sidecar注入和流量拦截已成功生效。你可以通过
kubectl logs <pod-name> -c istio-proxy 查看Envoy代理日志。
1.5 环境验证与金丝雀发布前置条件
在进入金丝雀发布实战之前，需要确认以下前置条件已满足：
| 检查项 | 验证命令 | 预期结果 |
|---|---|---|
| Istio控制面运行正常 | kubectl get pods -n istio-system | grep istiod |
istiod-xxx Running 1/1 |
| Sidecar注入正常 | kubectl get pods -n default |
每个Pod READY列为2/2 |
| Ingress Gateway可访问 | curl -I http://<EXTERNAL-IP>/productpage |
HTTP/1.1 200 OK |
| Kiali可访问 | istioctl dashboard kiali |
浏览器打开Kiali UI |
| Prometheus指标采集 | kubectl get pods -n istio-system | grep prometheus |
prometheus-xxx Running 2/2 |
1.6 常见问题与避坑指南
⚠️ 常见问题1：Sidecar注入失败
如果Pod启动后READY列为1/2或0/2，请检查命名空间标签是否正确设置，以及istio-proxy镜像是否可拉取。执行
如果Pod启动后READY列为1/2或0/2，请检查命名空间标签是否正确设置，以及istio-proxy镜像是否可拉取。执行
kubectl describe pod <pod-name> 查看事件，确认是否有ImagePullBackOff错误。
⚠️ 常见问题2：Ingress Gateway无法访问
如果无法通过外部IP访问productpage，请检查Service类型是否为LoadBalancer。在Minikube环境中，使用
如果无法通过外部IP访问productpage，请检查Service类型是否为LoadBalancer。在Minikube环境中，使用
minikube tunnel 或 kubectl port-forward 临时暴露服务。
💡 最佳实践： 建议在实验开始前，先使用
istioctl analyze 命令对整个集群进行配置检查，它会自动检测常见的配置错误和潜在问题。