如何设计 Kubernetes 多可用区的 Topology Aware Routing？
题目与背景
一个三可用区 Kubernetes 集群运行跨区访问成本较高的服务。团队希望请求优先发送到来源区的 Pod，同时在某区容量不足、流量倾斜或节点故障时保持可用。请设计 Topology Aware Routing 的启用、端点分布、回退、观测与回滚。
面试官考察什么
- 能否区分 EndpointSlice hints、kube-proxy 消费逻辑和 Service 的流量策略。
- 能否识别“每区至少三个端点”和流量来源均衡等前提，而不是默认同区永远更好。
- 能否设计无 hints 时的全局回退、故障保护和热点监控。
- 能否量化跨区成本、延迟、端点负载与发布风险。
先问清楚的澄清问题
流量与目标
请求来源是否均匀分布在各区？目标是降低 p95 延迟、跨区流量成本，还是满足数据驻留？跨区访问是否比返回错误更可接受？
端点与扩缩容
每个 zone 有多少 ready Pod？扩缩容、滚动发布和 PodDisruptionBudget 是否会暂时低于安全端点数？Service 是否有本地节点流量需求？
故障与观测
故障域是 zone、节点还是网络？如何发现某区端点过载、hints 缺失或 kube-proxy 回退？是否允许按服务逐步启用？
30 秒回答框架
我会先确认来源流量和端点分布满足同区路由的前提，再通过 EndpointSlice hints 或 Service 的流量分布配置逐步启用。控制面在端点不足、区域不均或条件不满足时回退到全局端点，保证可用性。监控跨区字节、p95 延迟、每区请求和端点负载，canary 验证后扩大范围；发现热点或故障就关闭 hints，恢复全局路由。
深入解答步骤
1. 明确控制面与数据面
EndpointSlice controller 根据端点拓扑生成 hints，kube-proxy 等组件消费 hints 影响流量选择。Topology Aware Routing 的目标是偏好来源区端点，不保证所有请求都严格同区。系统设计应把控制面计算、EndpointSlice 传播和节点数据面行为分开观测。
2. 检查启用前提
官方文档建议每个 zone 至少有三个端点；在三可用区集群中通常意味着至少九个端点，端点不足时控制器可能不生成 hints。来源流量严重集中在单一区域也可能把该区端点压满，因此先用历史流量和容量数据验证假设。
3. 选择配置方式
可以使用 Service 的 topology mode 或相关 trafficDistribution 能力表达偏好。示例配置应与目标 Kubernetes 版本匹配：
apiVersion: v1
kind: Service
metadata:
name: checkout
annotations:
service.kubernetes.io/topology-mode: "Auto"
spec:
selector:
app: checkout
ports:
- port: 443
targetPort: 8443不要把旧的 topology-aware-hints 注解、当前 topology-mode 和版本特定字段混用；发布前确认 API 版本、feature gate 和 kube-proxy 行为。
4. 设计安全回退
控制面或 kube-proxy 在端点不足、hints 无效或分配不安全时应使用集群范围端点。回退路径必须可观测，不能静默地把跨区流量误判成同区优化成功。故障演练覆盖整区失联、EndpointSlice 延迟、节点标签错误和 kube-proxy 版本不一致。
5. 防止热点与不均衡
同区偏好会缩小候选端点集合。按 zone 统计请求数、连接数、CPU、队列和错误率；当某区来源比例过高或端点数偏少时，降低同区偏好或临时回退。扩缩容与滚动发布必须保持每区的 ready 端点和 PDB 余量。
6. 评估成本与延迟
同时记录跨区流量字节、请求 p50/p95/p99、连接复用、端点负载和失败率。用同一流量窗口比较启用前后，避免把缓存命中或客户端重试变化归因于拓扑路由。成本下降不能以错误率和尾延迟恶化为代价。
7. 分阶段发布与回滚
先在非关键 Service 或单一区域 canary 启用，验证 EndpointSlice hints、kube-proxy 选择和回退事件，再扩大到同类服务。回滚只需移除偏好配置并确认全局端点恢复；保留配置版本、指标窗口和故障演练记录。
高质量示例回答
我会把拓扑偏好当作可回退的性能优化。先确认每区端点和来源流量足以避免热点，再让 EndpointSlice controller 生成 hints，由节点数据面消费。端点不足、区域失衡或组件不兼容时自动回到全局端点。监控跨区字节、每区负载、延迟、错误率和回退次数，先 canary 后扩展；任何区过载或故障都通过关闭偏好恢复可用性。
常见错误
- 假设 hints 存在就一定严格同区路由。
- 忽略每区端点数量和来源流量均衡的前提。
- 只看跨区成本，不看某区端点过载和尾延迟。
- 把旧注解、版本字段和 feature gate 当成通用 API。
- 没有无 hints 时的全局回退和演练。
- 发布或缩容时让某区 ready 端点低于安全余量。
追问与回答
为什么端点不足时要回退？
拓扑偏好会缩小候选集合；端点太少会增加单点过载和故障风险。回退到全局端点能优先保持可用性。
三个端点是硬规则吗？
这是官方文档给出的适用建议，用于让每区分配更均衡，并非所有工作负载的绝对保证。应结合流量、容量和故障目标验证。
如果所有请求都来自一个 zone 呢？
同区偏好可能把压力集中到该区。应降低偏好、增加该区端点或回退全局路由，并用负载和延迟指标确认选择。
如何验证 kube-proxy 真的消费了 hints？
检查 EndpointSlice 的 hints、节点组件版本和实际请求分布；用跨区字节与每区端点命中率做端到端验证，不能只看控制面对象。
回滚是否需要重建 Service？
通常只需移除或调整拓扑偏好配置，并确认 EndpointSlice 与节点数据面恢复全局选择；仍要保留一次回滚演练和指标证据。