Pod亲和性使新Pod倾向调度到有特定标签Pod的节点，反亲和性则避开；节点亲和性通过matchExpressions等基于标签约束调度；调度仅依据requests值，limits仅运行时限制。
什么是Pod亲和性与反亲和性
Pod亲和性（Affinity）控制新Pod倾向于调度到哪些已有Pod所在的节点上；反亲和性（Anti-Affinity）则让Pod尽量避开某些节点。它比老式的red">nodeSelector更灵活，支持基于标签的拓扑感知匹配（比如“同区域”、“同机架”），还能区分“硬性要求”（requiredDuringSchedulingIgnoredDuringExecution）和“软性偏好”（preferredDuringSchedulingIgnoredDuringExecution）。
如何配置节点亲和性（Node Affinity）
节点亲和性用于将Pod绑定到满足特定节点标签条件的机器上。常见写法包括：
- 用matchExpressions定义多条件组合，如
key: "disktype", operator: "In", values: ["ssd"] - requiredDuringSchedulingIgnoredDuringExecution表示强制约束，不满足就一直Pending
- preferredDuringSchedulingIgnoredDuringExecution是打分式偏好，Kube-scheduler会按权重加成调度分数
- 注意：节点标签需提前通过
kubectl label nodes添加key=value
怎么设置Pod间亲和与反亲和规则
适用于有依赖或需隔离的场景，例如数据库主从不共节点、微服务避免单点故障等：
- 使用topologyKey指定拓扑域，如
topology.kubernetes.io/zone确保跨可用区部署 - 反亲和常用
operator: NotIn或Exists来避开带某标签的Pod - 若多个Pod共享同一label selector，它们之间会相互触发反亲和逻辑
- 注意：反亲和对性能有一定影响，大规模集群中慎用
required模式
资源请求（requests）与限制（limits）如何影响调度
Kubernetes调度器只看requests值做决策——即容器启动前必须保证节点有足够CPU和内存余量。而limits仅在运行时做cgroup限制，不影响调度结果。
- CPU requests以核心数为单位（如
100m= 0.1核），内存以字节为单位（如256Mi） - 未设置requests时，调度器可能把Pod塞进资源紧张的节点，导致OOM或CPU饥饿
- 建议requests和limits设为相同值（即“严格限制”），便于容量规划和水平扩缩容计算
- 配合ResourceQuota和LimitRange可实现命名空间级资源管控
