Pod亲和性使新Pod倾向调度到有特定标签Pod的节点，反亲和性则避开；节点亲和性通过matchExpressions等基于标签约束调度；调度仅依据requests值，limits仅运行时限制。

什么是Pod亲和性与反亲和性

Pod亲和性（Affinity）控制新Pod倾向于调度到哪些已有Pod所在的节点上；反亲和性（Anti-Affinity）则让Pod尽量避开某些节点。它比老式的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可实现命名空间级资源管控