给节点打安全专用污点必须用noschedule效果，因其能严格阻止不匹配pod调度，确保敏感业务独占高隔离节点；prefernoschedule仅倾向性避免，资源紧张时仍可能破坏隔离。
给节点打上安全专用污点必须用 NoSchedule 效果
敏感业务（如支付网关、密钥管理服务）需要独占高隔离性节点，不能和普通服务混跑。此时必须用 NoSchedule 而非 PreferNoSchedule —— 后者只是“尽量避免”，一旦其他节点资源耗尽，调度器仍可能把非敏感 Pod 塞进去，破坏隔离边界。
实操建议：
- 用
kubectl taint node <node-name> security=high:NoSchedule</node-name>添加污点，security=high是自定义键值，语义清晰且便于后续审计 - 避免使用空 value（如
security=:NoSchedule），否则在容忍配置中必须用operator: Exists，容易遗漏匹配逻辑 - 不要复用系统默认污点键名（如
node-role.kubernetes.io/master），防止与管控面行为耦合，增加排查复杂度
Pod 的 tolerations 必须显式声明 key、value 和 effect
只写 key 和 effect 但漏掉 value，或把 value 写错成大小写不一致的字符串（如 High vs high），都会导致容忍失效——Pod 卡在 Pending 状态，kubectl describe pod 里会明确提示 Tolerations: <none></none> 或 0/1 nodes are available: 1 node(s) had taint {security: high}, that the pod didn't tolerate.
正确写法示例：
tolerations: - key: "security" operator: "Equal" value: "high" effect: "NoSchedule"
注意：operator: Equal 是默认值，可省略；但 value 和 effect 缺一不可。
别忽略 Master 节点自带污点对安全节点配置的干扰
新集群初始化后，Master 节点默认带 node-role.kubernetes.io/control-plane:NoSchedule 污点。如果你把某台物理机同时标记为安全节点 + control-plane 角色（比如用 kubeadm init --control-plane-endpoint 部署的单点集群），它就同时承载两类污点。这时 Pod 的容忍必须全部覆盖，否则仍无法调度。
常见错误场景：
- 只容忍了
security=high，没处理 control-plane 污点 → Pod 无法上节点 - 误删 Master 污点（
kubectl taint node <name> node-role.kubernetes.io/control-plane:NoSchedule-</name>）→ 控制平面组件被挤占资源，集群不稳定
稳妥做法：专设独立 Worker 节点做安全节点，不混用角色；若必须复用，容忍列表需叠加声明，且严格测试控制面稳定性。
NoExecute 不适合长期安全隔离，仅用于维护窗口
有人想用 NoExecute 实现“绝对隔离”，这是误解。NoExecute 的核心用途是驱逐——一旦节点被打上该效果污点，所有未容忍的 Pod 会在几秒内被强制终止。这对在线敏感业务是灾难性的，不是隔离手段，而是中断手段。
真正需要的是稳定、可预期的调度边界，所以：
- 日常隔离一律用
NoSchedule -
NoExecute只应在节点下线、硬件检修等明确有维护窗口的场景临时启用，并配合tolerationSeconds给业务留出 graceful shutdown 时间 - 切勿在安全节点 YAML 中长期保留
NoExecute污点，它会让节点处于“随时可能清场”的脆弱状态
最易被忽略的一点：污点本身不加密、不鉴权，它只是调度层的逻辑标记。真正的安全隔离还需配合网络策略（NetworkPolicy）、运行时限制（seccomp、AppArmor）和节点 OS 层加固——污点只是第一道门禁，不是整堵墙。
