VPS云服务器K8s集群：调度策略与故障排查指南

做了五年系统运维，最常遇到的K8s集群问题，十有八九和调度有关——尤其是用VPS云服务器搭建的集群里。上周刚处理过一个典型案例：某团队用VPS云服务器搭了K8s集群，新部署的Pod总卡在Pending状态，怎么都调度不到节点上。今天就借这个案例，拆解K8s调度策略的核心逻辑。

### 从Pending故障看预选阶段：资源门槛是第一道关

问题出现后，团队先查Pod状态，发现事件日志里反复提示"0/3 nodes are available"。这说明K8s调度器在预选阶段就过滤掉了所有节点。预选阶段是调度的第一关，调度器会按Pod配置的资源请求（CPU、内存等），逐一检查节点是否满足基础条件。

比如案例中的Pod配置了"requests: memory: 2Gi"，意味着它至少需要节点剩余2GB内存才能被调度。当时团队用`kubectl describe node`命令查看节点详情，发现三台节点的可用内存分别是1.8Gi、1.5Gi和1.2Gi——都不满足Pod的最低要求，自然过不了预选阶段。这种情况的解决方法很直接：要么扩容VPS云服务器集群（加节点），要么调小Pod的内存请求（需评估业务压力）。

### 优选阶段：亲和性/反亲和性规则的隐性限制

假设节点资源充足，Pod还是Pending，问题可能出在优选阶段。这一步调度器会在通过预选的节点中，根据负载均衡、亲和性/反亲和性等规则选出"最优解"。

亲和性规则像"偏好设置"，比如给Pod配置`nodeAffinity`，要求调度到带标签`disk=ssd`的节点。反亲和性则是"排除选项"，比如设置`podAntiAffinity`，让同应用的Pod不调度到同一节点（避免单点故障）。案例团队后来检查Pod配置，发现误加了一条反亲和性规则：`requiredDuringSchedulingIgnoredDuringExecution: topologyKey=kubernetes.io/hostname`。这条规则要求同一应用的Pod必须分布在不同主机，但当时集群只有3个节点，新Pod调度时已存在3个同应用Pod，导致无节点可选。调整规则为"preferred"（优先而非强制）后，问题很快解决。

### 进阶控制：污点与容忍度的精细管理

除了上述策略，VPS云服务器集群中常用的还有污点（Taint）与容忍度（Toleration）。污点打在节点上，标记"不接受某些Pod"；容忍度写在Pod里，声明"我能接受某个污点"。比如为存储节点打污点`disk=ssd:NoSchedule`，再给需要高速存储的Pod加容忍度，就能确保这类Pod只调度到SSD节点，避免普通Pod抢占资源。

需要注意的是，规则越复杂，调度失败风险越高。曾见过有团队为追求"精准调度"，同时设置5条亲和性规则+3条反亲和性规则，结果集群里80%的Pod都卡在Pending。后来简化为2条核心规则，问题迎刃而解。

在VPS云服务器上用K8s，调度策略不需要"大而全"，关键是"准而稳"。先确保预选阶段的资源匹配，再用亲和性/反亲和性做基础分流，最后用污点容忍度做精细控制——这三步走完，90%的调度故障都能避免。毕竟集群稳定运行的核心，从来不是堆复杂规则，而是让Pod在该去的节点上，干好该干的事。