强制高频数据库容器调度至高IO物理机，须用nodeAffinity硬性约束requiredDuringSchedulingIgnoredDuringExecution配合精准节点标签（如io-capacity=high、storage-type=nvme），确保调度时仅匹配目标节点，不支持运行时强绑定。
要强制将高频数据库容器调度到高IO物理机，核心是用 nodeAffinity 的硬性约束（requiredDuringSchedulingIgnoredDuringExecution），配合提前打好的节点标签。关键不在“绑定”，而在“调度时只允许落在满足条件的节点上”——Kubernetes 不支持运行时强绑定或锁死，但能确保 Pod 从一开始就不会被调度到非目标节点。
给高IO节点打上明确标签
先识别并标记真实具备高IO能力的物理节点（如配备 NVMe SSD、低延迟存储栈的机器）：
- 执行命令打标签，例如：
kubectl label nodes node-io-01 io-capacity=high storage-type=nvme - 建议使用语义清晰、业务可读的键值对，避免泛用
role=database这类易歧义的标签 - 用
kubectl get nodes --show-labels确认标签已生效，且仅打在目标节点上
在Pod或Deployment中声明硬性亲和规则
在容器 spec 中嵌入 affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution，要求节点必须同时满足多个IO相关标签：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 推荐用
matchExpressions组合多个条件，例如：
- key: io-capacity
operator: In
values: ["high"]
- key: storage-type
operator: In
values: ["nvme", "ssd"] - 不要混用
matchFields，它基于节点字段（如 metadata.name），不适用于IO能力描述 - 若集群中高IO节点还分代际（如 nvme-gen4 / nvme-gen5），可在 values 中细化，提升匹配精度
验证调度结果与常见失败点
部署后立即检查，避免 Pod 卡在 Pending 状态：
- 运行
kubectl get pod -o wide，确认 Pod 所在节点是否为预期的高IO节点 - 若状态为
Pending，用kubectl describe pod <name>查看 Events，常见原因是：
– 没有节点同时满足所有matchExpressions条件
– 标签拼写错误（如io_capacity写成io-capacity）
– 节点处于NotReady或资源不足（亲和性不检查资源余量，需额外配 resource requests） - 注意：该策略只管调度那一刻，节点后续标签变更或宕机不影响已运行 Pod —— 这正是
IgnoredDuringExecution的含义
进阶建议：搭配资源请求与拓扑分布
单靠亲和性还不够稳健，尤其对高频数据库：
- 务必设置合理的
resources.requests（尤其是 memory 和 hugepages），防止被挤占IO带宽 - 若部署多副本，加上
topologySpreadConstraints，按topologyKey: topology.kubernetes.io/zone分散到不同可用区，避免单点故障 - 避免与
nodeSelector同时使用：两者需同时满足，容易过度限制；优先统一用nodeAffinity，表达更灵活
