pod Affinity与pod antiaffinity
Pod Affinity与anti-affinity简介：
-
Pod亲和性与反亲和性可以基于已经在node节点上运行的Pod的标签来约束新创建的Pod可以调度到的 目的节点，注意不是基于node上的标签而是使用的已经运行在node上的pod标签匹配。
-
其规则的格式为如果 node节点 A已经运行了一个或多个满足调度新创建的Pod B的规则，那么新的 Pod B在亲和的条件下会调度到A节点之上，而在反亲和性的情况下则不会调度到A节点至上。
-
其中规则表示一个具有可选的关联命名空间列表的LabelSelector，只所以Pod亲和与反亲和需可以通 过LabelSelector选择namespace，是因为Pod是命名空间限定的而node不属于任何nemespace所以 node的亲和与反亲和不需要namespace，因此作用于Pod标签的标签选择算符必须指定选择算符应用 在哪个命名空间。
-
从概念上讲，node节点是一个拓扑域(具有拓扑结构的区域、宕机的时候的故障域)，比如k8s集群中的 单台node节点、一个机架、云供应商可用区、云供应商地理区域等，可以使用topologyKey来定义亲 和或者反亲和的颗粒度是node级别还是可用区级别，以便kubernetes调度系统用来识别并选择正确的 目的拓扑域。
-
Pod 亲和性与反亲和性的合法操作符(operator)有 In、NotIn、Exists、DoesNotExist。
-
在Pod亲和性配置中，在requiredDuringSchedulingIgnoredDuringExecution和 preferredDuringSchedulingIgnoredDuringExecution中，topologyKey不允许为空(Empty topologyKey is not allowed.)。
-
在Pod反亲和性中配置中，requiredDuringSchedulingIgnoredDuringExecution和 preferredDuringSchedulingIgnoredDuringExecution 中，topologyKey也不可以为空(Empty topologyKey is not allowed.)。
-
对于requiredDuringSchedulingIgnoredDuringExecution要求的Pod反亲和性，准入控制器 LimitPodHardAntiAffinityTopology被引入以确保topologyKey只能是 kubernetes.io/hostname，如果希 望 topologyKey 也可用于其他定制拓扑逻辑，可以更改准入控制器或者禁用。
-
除上述情况外，topologyKey 可以是任何合法的标签键。
case4-4.1：部署web服务
-
编写yaml文件，在magedu anmespace部署一个nginx服务，nginx pod将用于后续的pod 亲和及反亲和测 试，且pod的label如下：
-
app: python-nginx-selector
-
project: python
-
-
部署nginx web服务：
-
kubectl apply -f case4-4.1-nginx.yaml
-
deployment.apps/python-nginx-deployment created
-
service/python-nginx-service created
-
-