目前我们部署应用是已deployment对象为单位，亲和度也是针对每个deployment来设置。先说明一下条件。
设置亲和度的条件：
设置亲和度首先机器数量有要求否则会反而引起副本集中在一台机器上,举个例子，比如mservice这个pod如果我们要起两个副本，如果要通过亲和度使得他自动的落在不同的机器节点上，这时就需要有3个机器节点才能够完成。就是机器节点数要比需求副本数多一个。（下面会解释原因）
先讲设置方法：
通过kubectl -n 命名空间 edit deployment deployment名字 添加如下配置两个井号之间的内容就是亲和度的配置，这里以mc为例子
template: metadata: annotations: com.kingdee.kcs.zid: "5" creationTimestamp: null labels: app: mc cluster: test sname: mc spec: ##亲和性配置 affinity: podAntiAffinity: # requiredDuringSchedulingIgnoredDuringExecution: （强制调度策略，没有足够机器时会导致多余的副本起不来） preferredDuringSchedulingIgnoredDuringExecution: #软调度策略，会尽量满足需求但是会以启动为优先 - podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - mc #这里是要跟据当前deployment的其中一个labels一致，注意要选唯一的值（别的） topologyKey: kubernetes.io/hostname weight: 1 ######### containers: - env: |
分两种策略解析一下逻辑：
1，当使用强制调度策略：
只有两台机器却启动两个mc副本，一开始启动的时候没问题，但是当我们需要重启mc时就会发现不能重启，因为重启的机制是先启动一个新的mc的pod再删除老的mc的pod，而这时因为只有两台机器，两台机器又都已经启动了对应的mc的pod，因此没有可用于启动新mc的机器。重启操作就会卡住。
2，当使用软调度策略时:
同样是重启的需求，新的pod能启动起来但是老的pod删除时会有一定的延时，这时两台机器都同样有这个pod的标签，就会导致判断失灵，不一定能保证pod还会继续的分配到不同的机器上。
推荐阅读