1. 课程导论：什么是调度亲和性策略？为什么需要验证其容错能力？Istio故障注入在其中的角色
1.1 调度亲和性策略：云原生中的“座位安排”
在Kubernetes集群中，调度亲和性策略是一组规则，用于控制Pod应该被调度到哪些节点上运行。它决定了工作负载在集群物理或虚拟节点上的分布方式，是保障应用性能、合规性和高可用性的关键机制。
调度亲和性主要分为三类：
| 类型 | 描述 | 典型场景 |
|---|---|---|
| 节点亲和性 | 将Pod调度到具有特定标签（如GPU、SSD、可用区）的节点上 | AI推理Pod必须运行在GPU节点；数据库Pod优先调度到高性能存储节点 |
| Pod间亲和性 | 将Pod调度到与某些已有Pod相同的拓扑域（如同一节点、同一可用区） | 缓存层与计算层同节点部署以减少网络延迟 |
| Pod间反亲和性 | 将Pod调度到与某些已有Pod不同的拓扑域 | 将同一微服务的多个副本分散到不同节点或可用区，避免单点故障 |
关键认知： 调度亲和性策略本质上是有状态约束。一旦集群节点发生故障、扩缩容或网络分区，这些约束可能被打破，导致服务降级或不可用。因此，验证策略在故障下的容错能力是SRE的核心职责。
1.2 为什么需要验证调度亲和性策略的容错能力？
调度亲和性策略在理想状态下工作良好，但在故障场景下可能暴露出严重问题。SRE团队必须通过主动验证来回答以下关键问题：
- 单点故障风险： 如果反亲和性策略配置不当，所有副本可能仍被调度到同一故障域（如同一机架或同一网络交换机下），导致整个服务在单点故障时完全不可用。
- 级联故障效应： 一个节点的故障可能导致依赖该节点的Pod全部重新调度，如果亲和性约束过于严格，新Pod可能无法找到符合条件的节点，造成调度死锁。
- 资源碎片化： 严格的节点亲和性（如必须使用特定GPU型号）在节点故障后，可能导致剩余节点资源不足，Pod长时间处于Pending状态。
- 跨可用区延迟激增： Pod间亲和性强制将服务绑定在同一可用区，当该可用区故障时，流量被迫跨区转发，延迟可能从1ms飙升到50ms以上。
⚠️ 常见陷阱： 许多团队在配置调度亲和性时只考虑“正常情况下的最优分布”，而忽略了“故障情况下的最坏分布”。例如，将数据库主从通过Pod间亲和性强制调度到同一节点以降低延迟，一旦该节点宕机，主从同时丢失，导致数据持久化完全中断。
1.3 Istio故障注入在其中的角色
Istio服务网格提供了强大的故障注入能力，允许SRE在不修改应用代码的情况下，向服务间通信中注入延迟和异常。在验证调度亲和性策略的容错能力时，Istio故障注入扮演以下关键角色：
| 验证目标 | Istio故障注入方式 | 模拟的故障场景 |
|---|---|---|
| 节点级故障 | 对特定Pod注入HTTP 500或连接拒绝 | 模拟节点宕机后，调度器将Pod重新调度到其他节点的过程 |
| 可用区级故障 | 对跨可用区流量注入固定延迟（如2000ms） | 模拟整个可用区网络分区，验证反亲和性策略是否将副本分散到幸存区 |
| 资源争用 | 对健康检查端点注入延迟，使Pod被标记为不健康 | 模拟节点资源耗尽后，Pod被驱逐并触发重新调度的场景 |
| 级联故障 | 对关键依赖服务注入故障，观察上游服务的调度行为 | 模拟缓存层故障后，应用层Pod是否因亲和性约束而无法正常调度 |
通过Istio故障注入，SRE可以：
- 安全地模拟真实故障，无需实际破坏基础设施。
- 精确控制故障范围，只影响特定服务或特定流量比例。
- 可观测性集成，结合Prometheus、Kiali等工具实时观察调度变化和流量迁移。
- 自动化回归测试，将故障注入集成到CI/CD流水线中，每次策略变更后自动验证容错能力。
1.4 课程目标与学习路径
本课程将带领你从零开始，掌握使用Istio故障注入验证调度亲和性策略容错能力的完整方法。你将学到：
- 如何编写Kubernetes调度亲和性策略（节点亲和性、Pod间亲和性/反亲和性）。
- 如何使用Istio的VirtualService和DestinationRule配置故障注入规则。
- 如何设计故障注入实验，模拟节点故障、可用区故障和级联故障。
- 如何结合Kiali、Prometheus和Grafana观察故障注入后的调度变化和流量行为。
- 如何根据验证结果优化调度策略，提升系统的整体韧性。
💡 前置要求： 建议你具备Kubernetes基础（Pod、Node、调度器概念）和Istio基础（VirtualService、DestinationRule、Sidecar注入）。本课程将提供所有YAML配置示例，你可以直接在自己的集群中实践。