NodeSelector

背景与问题界定 在大型 Kubernetes 集群中，Pod 调度直接影响应用性能和集群资源利用率。我们曾遇到一个典型场景：一个日活超千万的微服务集群，由于 Pod 被随机调度到不同可用区和机架，导致跨节点网络延迟增加 40%，P99 延迟从 50ms 飙升到 120ms。更严重的是，GPU 密集型任务被调度到没有 GPU 能力的工作节点，造成大量重调度和资源浪费。Kubernetes 调度器虽然有默认的 predicates 和 priorities 机制，但在超大规模集群（2000+ 节点）下，默认策略无法满足复杂拓扑约束和性能需求，必须通过精细化的调度策略来优化资源编排。 目标拆解与工程约束 多维度拓扑亲和性要求：Pod 需要优先调度到同一可用区（AZ）以降低跨 AZ 流量费用和延迟，同时避免将同一服务的多个副本聚集在同一故障域，防止单点故障导致整个服务不可用。 异构资源感知：集群混合部署了 CPU 密集型、内存密集型和 GPU 加速型工作负载，调度器必须能够感知节点上的 GPU 型号、本地 NVMe 磁盘等特殊资源，避免资源错配。 调度性能和稳定性：在 2000+ 节点的集群中，每个 Pod 的调度延迟需要控制在 100ms 以内，调度器高可用必须保证故障切换时不会丢失已有的调度决策和数据。 动态资源竞争：高峰期资源争抢严重，需要实现优先级抢占（Priority Preemption），确保关键业务 Pod 在资源不足时能够抢占低优先级 Pod 的资源，同时保证被抢占 Pod 的优雅终止。 方案设计 我们采用分层调度策略体系来应对上述挑战。第一层是基础的 nodeSelector 和 nodeAffinity，用于硬性约束——通过 nodeSelector 将 GPU 工作负载固定到带有 gpu=true 标签的节点池，避免调度到 CPU 节点。第二层引入 Pod 间亲和性（podAffinity）和反亲和性（podAntiAffinity），使用 topologyKey: topology.kubernetes.io/zone 将同服务的多个副本分散到不同的可用区，同时将缓存层和数据层调度到同一节点以降低延迟。 第三层是拓扑感知调度（Topology Aware Scheduling），这是 Kubernetes 1.27 进入 GA 的关键特性。我们利用 topologySpreadConstraints 实现跨拓扑域的最大均匀分布。例如对于日志采集 DaemonSet，配置 maxSkew: 1 确保每个可用区的 Pod 数量偏差不超过 1，避免单区过载。对于有状态服务 StatefulSet，通过 whenUnsatisfiable: ScheduleAnyway 配合 minDomains 实现软约束，保证节点滚动更新时调度器不会过度分散导致 Pod 创建失败。 ...