K3s节点执行cordon或drain后Pod无法调度，主因是污点未容忍、亲和性限制过强、资源不足及K3s特有因素（如local-path PV绑定、DaemonSet干扰、etcd状态异常）。
K3s 节点执行 cordon 或 drain 后，Pod 未能调度到其他节点，通常不是单一原因导致，而是多个调度约束、资源状态或配置细节共同作用的结果。以下是最常见、最易被忽略的几类原因。
节点污点（Taint）未被容忍（Toleration）
K3s 默认不会自动为新节点添加容忍，而 drain 过程中若原节点带有自定义污点（如 node.kubernetes.io/unschedulable:NoSchedule），且 Pod 模板未显式声明对应 tolerations，则调度器会跳过所有带该污点的节点——包括其他正常节点，只要它们也继承了相同污点（例如通过 K3s 的 auto-deployed node-labeling 或手动打污点）。
- 检查节点污点：
kubectl describe node <node-name> | grep Taints - 检查 Pod 是否含匹配容忍：
kubectl get pod <pod-name>> -o yaml | yq '.spec.tolerations'（或用kubectl describe pod） - 若需跨节点容忍，应在 Deployment/StatefulSet 的
spec.template.spec.tolerations中显式添加
Pod 亲和性/反亲和性（Affinity/Anti-affinity）限制过强
尤其是 requiredDuringSchedulingIgnoredDuringExecution 类型的硬性亲和规则，会导致调度器直接拒绝将 Pod 放到不满足条件的节点上。例如：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 要求必须与某标签的 Pod 在同一节点（
podAffinity），但目标 Pod 已被驱逐且未在其他节点重建 - 设置
topologyKey: topology.kubernetes.io/zone但集群仅单可用区，而其他节点未打对应 label - 使用
nodeAffinity锁定特定nodeSelectorTerms，但其他节点缺少匹配的 label
验证方式：kubectl get pod <pod-name> -o yaml 查看 affinity 字段，并用 kubectl get nodes --show-labels 对照节点标签。
资源不足或资源请求未满足
cordon 不影响资源计算，但 drain 后大量 Pod 需重调度，容易暴露真实资源瓶颈：
- 其他节点的
allocatableCPU/内存已满（kubectl describe nodes查看 “Allocated resources” 和 “Capacity”） - Pod 设置了过高
requests（尤其 memory），而节点虽有空闲capacity，但allocatable因系统预留（K3s 默认预留 100m CPU + 256Mi 内存）不足 - 存在
ResourceQuota限制 namespace 级别总资源，导致新调度失败（kubectl get quota -A）
K3s 特有因素：轻量级组件干扰与默认行为差异
K3s 为精简，默认启用 local-path-provisioner 和 traefik，这些可能隐式引入调度依赖：
-
local-pathPV/PVC 绑定到特定节点，Pod 带volumeClaimTemplates或静态 PVC 时，因volumeBindingMode: Immediate导致无法跨节点调度（需改为WaitForFirstConsumer并确保 StorageClass 支持） - DaemonSet 控制的 Pod（如
metrics-server、helm-install）不响应drain，其关联的普通 Pod 可能因podAntiAffinity规则被间接卡住 - K3s 内置 etcd 成员未及时更新（如节点
drain后仍显示Ready,SchedulingDisabled但 etcd member 未 remove），导致控制平面不稳定，影响调度器工作
