云服务器备考CKA：K8s调度策略深度解析

备考CKA认证时，云服务器是绕不开的实战工具。其中K8s（Kubernetes）调度策略作为核心考点，直接关系到容器编排的资源利用率与系统稳定性。无论是本地搭建测试集群，还是模拟生产环境调优，理解这些策略的底层逻辑和应用场景，都是备考的关键突破口。



K8s调度器的核心职责，是将Pod精准分配到合适的节点运行。它像一个智能裁判，通过预设规则评估节点资源（CPU、内存、存储）、拓扑位置（可用区、机房）、负载状态等维度，最终选出最优节点。这一过程涉及三类最常用的调度策略，我们逐一拆解。

最基础的抓手：节点选择器（Node Selector）

节点选择器是入门级调度手段，通过标签（Label）实现简单匹配。例如，为云服务器节点打上"disk=ssd"标签，再在数据库Pod的YAML文件中添加：
nodeSelector:
disk: ssd
Pod就会被强制调度到带SSD硬盘的节点上。这种策略适合对资源类型有明确要求的场景——比如将日志服务固定到高IO节点，或把测试环境Pod集中到低配云服务器，既能避免资源浪费，也方便统一管理。

更灵活的控制：节点亲和性与反亲和性

节点选择器的"非此即彼"在复杂场景中略显局限，这时候需要节点亲和性（Node Affinity）补位。它支持"软约束"（preferredDuringSchedulingIgnoredDuringExecution）和"硬约束"（requiredDuringSchedulingIgnoredDuringExecution）两种规则。比如为计算密集型Pod设置：
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: cpu-type
operator: In
values: ["amd-epyc"]
调度器会优先选择AMD EPYC芯片的云服务器节点，但如果没有符合条件的节点，Pod仍会被调度到其他节点（反亲和性则是"尽量避开"）。这种弹性设计在混合云环境中特别实用——当某类节点资源紧张时，系统不会直接卡住，而是降级运行。

更细粒度的协同：Pod亲和性与反亲和性

如果说前两种策略关注"节点与Pod"的关系，Pod亲和性（Pod Affinity）则聚焦"Pod与Pod"的协同。典型场景是让缓存Pod（如Redis）与应用Pod（如Web服务）尽量部署在同一云服务器节点，减少网络延迟。配置时需指定匹配规则，例如：
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values: ["web-service"]
topologyKey: kubernetes.io/hostname
反之，Pod反亲和性可避免同类Pod集中部署——比如将3个Nginx实例分散到3台云服务器，防止单节点故障导致服务大面积中断。这种策略在高可用架构中尤为重要，是CKA考试中高频考察的"故障隔离"考点。

在云服务器上备考时，建议通过实际操作加深理解：用Minikube或K3s快速搭建集群，分别创建带不同调度策略的Pod，观察调度结果；尝试修改标签、调整亲和性权重，模拟资源紧张场景验证策略效果。需要注意的是，真实生产环境中往往需要组合使用多种策略（如节点反亲和性+Pod亲和性），这就要求我们不仅要掌握单个策略，更要理解它们的优先级与冲突处理逻辑。

掌握K8s调度策略是CKA认证的核心能力，也是高效利用云服务器资源的关键。通过理论学习与云服务器上的实战操作，能更快提升容器编排水平，为认证考试和实际部署打下坚实基础。