要让pod按预期分布，关键不是“禁止调度”，而是用亲和性规则主动引导调度器做选择：节点亲和性控制pod与节点关系，pod亲和/反亲和性控制pod间关系；硬约束必须满足，软约束带权重优先匹配；pod反亲和性通过topologykey（如hostname或zone）强制多副本分散，避免单点故障；组合使用节点亲和限定范围、pod反亲和实现分散，才能精准控制分布。
要让 Pod 按预期分布，关键不是“禁止调度”，而是用亲和性规则主动引导调度器做选择。节点亲和性管 Pod 和节点的关系，Pod 亲和/反亲和性管 Pod 和 Pod 的关系——组合使用才能精准控制分布。
节点亲和性：把 Pod 锁定到合适硬件上
适合绑定特定资源类型，比如 SSD、GPU 或特定可用区。它分硬约束（requiredDuringSchedulingIgnoredDuringExecution）和软约束（preferredDuringSchedulingIgnoredDuringExecution）。
- 硬约束必须满足，不满足就一直 Pending；软约束带权重，调度器会尽量选分高的节点
- 常用 operator 包括 In（值在列表中）、NotIn（排除某些节点）、Exists（只要标签存在就行）
- 如果同时用了 nodeSelector 和 nodeAffinity，两者都得满足才算通过
Pod 反亲和性：强制多副本分散部署
这是避免单点故障最直接的方式。尤其对 StatefulSet 或 Deployment 的多副本服务，用它能确保实例不挤在同一节点或同一可用区。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 核心字段是 topologyKey：设为 kubernetes.io/hostname 表示“不能同节点”；设为 failure-domain.beta.kubernetes.io/zone 表示“不能同可用区”
- 硬反亲和（requiredDuringSchedulingIgnoredDuringExecution）能保证严格分散，但集群节点不足时可能卡住调度
- 软反亲和（preferredDuringSchedulingIgnoredDuringExecution）更灵活，适合节点数有限但又希望尽量均衡的场景
亲和性 + 反亲和性：组合策略更可靠
单一策略容易冲突或覆盖不足。例如只用硬节点亲和，可能导致所有副本都跑到同一台 SSD 节点上；只用硬 Pod 反亲和，又可能因节点数不够而无法启动。
- 典型搭配：用节点亲和限定可选范围（如只允许跑在 GPU 节点），再用 Pod 反亲和在该范围内分散
- 拓扑键要匹配实际需求：hostname 级别隔离适用于防节点故障；zone 级别适用于跨可用区高可用
- 注意性能影响：Pod 亲和/反亲和需遍历集群中现有 Pod 做匹配，几百节点规模下会拖慢调度速度，慎用于高频扩缩容场景
实操前必查三件事
配置写得再准，若基础没打好，照样调度失败。
- 确认节点已打标：用 kubectl get nodes --show-labels 查看，标签名和值必须完全一致（区分大小写）
- 检查 labelSelector 是否匹配目标 Pod：反亲和里写的 app: redis，得确保已有 Redis Pod 确实带这个标签
- 验证 topologyKey 是否真实存在：比如 failure-domain.beta.kubernetes.io/zone 在公有云环境通常由平台自动注入，自建集群需手动补全
