作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。
我们上小节介绍了Node亲和性(Affinity)和反亲和性(Anti-affinity)本质上还是属于Node和Pod的之间的调度规则。如果我们有一个需求要求同一个Deployment下的Pod不能调度到同一个节点，避免将同一个应用全部调度到某台服务器。避免出现服务器宕机导致某一应用高可用失效的情况(虽然Kubernetes会在把Pod调度到其他节点，但是这个中间是有时间差的)。我在生产环境也是遇到过类似的故障。或者相反的要求一个控制器下的Pod必须和某个Pod在一起，则可以通过Pod亲和性(Affinity)和反亲和性(Anti-affinity)来解决。
Pod 亲和性
Pod 亲和性用于将新 Pod 安排到与现有 Pod 相近的位置，这些现有 Pod 可能是同一个应用的不同实例或者是相互协作的服务。以下是一个 Pod 亲和性的示例：
apiVersion: apps/v1
kind: Deployment
metadata:name: myapp-deployment
spec:replicas: 3selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:affinity:podAffinity:# 强制性（硬性）亲和性规则requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- myapptopologyKey: "kubernetes.io/hostname"# 不强制性（软性）亲和性规则preferredDuringSchedulingIgnoredDuringExecution:- weight: 1podAffinityTerm:labelSelector:matchExpressions:- key: appoperator: Invalues:- myapptopologyKey: "kubernetes.io/hostname"containers:- name: myapp-containerimage: myapp-image:latest强制亲和性：要求必须匹配标签：app：myapp的Pod，如果已经有一个带有标签 app: myapp 的 Pod 调度到了节点 A，那么当前的 Deployment 中的 Pod 副本也会尝试调度到节点 A。适合哪些强相关的应用，他们必须(尽量)要在一个节点，如果没有合适的标签Pod可能会导致导读失败。
Pod 反亲和性
Pod 反亲和性用于将新 Pod 安排到与具有特定标签的现有 Pod 不同的节点上，这有助于实现高可用性和故障隔离。以下是一个 Pod 反亲和性的示例：
apiVersion: apps/v1
kind: Deployment
metadata:name: myapp-deployment
spec:replicas: 3selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- myapptopologyKey: "kubernetes.io/hostname"首次调度：当第一个app=myapp Pod被调度时，由于没有其他app=myapp Pod存在，它可以被自由地分配到任何节点上。
后续调度：当你尝试创建第二个app=myapp Pod时，Kubernetes调度器会根据podAntiAffinity规则检查各个节点。如果某个节点上已经存在一个app=myapp Pod，则新的Pod不会被调度到该节点上。相反，它会被调度到另一个没有app=myapp Pod的节点上。从而就实现了一个Deployment被调度到不同的节点。
拓扑域：topologyKey 代表 Kubernetes 集群中的拓扑域，如节点、机架、区域、可用区等。它通常是一个节点标签的键，用于定义 Pod 亲和性和反亲和性规则的上下文，如果上面的拓扑域是Zone，则可以把Pod调度到不同的Zone，从而提供集群的可用性。
这里实际上一共有4个配置，我们可以根据自己的需求选择其中一个或者多个进行组合配置，以满足自己的特殊的需求。
Node的亲和性主要满足的是Pod和Node匹配关系，而Pod的亲和性主要满足的是Pod和Pod的之间的关系，虽然最后选择的也是用来选择Node。
到这里我们用了5个小节来讲解调度相关的内容，这些都是Kubernetes默认的自带的调度功能，如果不满足要求还可以自带定义调度器功能。
运维小路
一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！
