1. 课程导论：K8s 调度与网络拓扑的关系、TC 在排查中的价值、样本抽检的必要性

1.1 K8s 调度与网络拓扑：从“资源匹配”到“拓扑感知”

Kubernetes 调度器的核心职责是将 Pod 绑定到最合适的 Node 上。传统调度主要关注 CPU、内存等计算资源的供需匹配，但在生产环境中，网络拓扑对应用性能的影响往往被低估。Pod 之间的通信延迟、带宽瓶颈、跨可用区（AZ）流量成本，都与调度决策直接相关。

调度器通过 topologySpreadConstraints、nodeAffinity、podAntiAffinity 等机制实现拓扑感知，但默认调度器并不感知底层网络设备的实际负载与链路质量。这就导致了一个关键鸿沟：调度器认为的“最优节点”，在网络层面可能并非最优。

1.2 TC（Traffic Control）在排查中的价值

TC 是 Linux 内核提供的流量控制框架，负责管理网络接口上的数据包队列、整形、调度和过滤。在 K8s 网络排查中，TC 的价值体现在三个层面：

TC 的独特优势在于：它工作在 OSI 第 2~3 层，不依赖应用层代理，能直接反映内核网络栈的真实行为。在 K8s 环境中，结合 ip link、ss、ethtool 使用，可以快速定位“调度器认为正常，但网络实际异常”的隐蔽问题。

1.3 样本抽检的必要性

在大型 K8s 集群（数千 Node、数万 Pod）中，全量采集所有网络路径的 TC 状态是不现实的。样本抽检成为平衡排查深度与系统开销的关键策略。

样本抽检的核心原则：

• 分层抽样： 按 Node 角色（Master/Worker）、Pod 类型（业务 Pod/系统 Pod）、网络路径（同 Node/跨 Node/跨 AZ）分层选取样本。
• 异常导向： 优先抽检调度器最近 5 分钟调度失败的 Node、TCP 重传率 > 1% 的 Node、以及 CNI 插件日志报错的 Node。
• 时间窗口： 每次抽检覆盖 30 秒的 TC 统计快照，避免瞬时抖动干扰。

通过样本抽检，SRE 团队可以在不引入大规模 Agent 采集的前提下，持续获得网络拓扑的健康快照，并与调度器的历史决策进行关联分析。

1.4 调度与网络拓扑的关联模型

下图展示了调度决策、Pod 运行状态与底层网络拓扑之间的数据流关系，以及 TC 在其中的观测位置：

1.5 课程核心路径：从 TC 追踪到调度优化

本课程将围绕以下关键路径展开：

1. TC 基础与 K8s 环境适配： 掌握 qdisc、class、filter 三大核心概念，以及如何在容器网络命名空间中执行 TC 命令。
2. 网络拓扑感知调度： 深入 topologySpreadConstraints 与 nodeAffinity 的底层实现，理解调度器如何读取 Node 拓扑标签。
3. TC 追踪实战： 通过 5 个真实案例（Pod 带宽限速失效、跨 AZ 延迟突增、Service 流量漂移等），演示 TC 的排查步骤。
4. 样本抽检系统设计： 基于 Prometheus + eBPF 实现轻量级 TC 指标采集与抽检调度。
5. 调度优化闭环： 将 TC 观测结果反馈至调度器，实现动态拓扑感知调度。