Kubernetes调度中的Pod亲和性
abstract.png
Pod亲和性
节点亲和性，是基于节点的标签对Pod进行调度。而Pod亲和性则可以实现基于已经在节点上运行Pod的标签来约束新Pod可以调度到的节点。具体地，如果X上已经运行了一个或多个满足规则Y的Pod，则这个新Pod也应该运行在X上。其中，X可以是节点、机架、可用性区域、地理区域等。可通过topologyKey字段定义拓扑域X，其取值是节点标签的键名Key；而Y则是Kubernetes尝试满足的规则。可以通过标签选择器的形式来定义。此外，Pod亲和性使用podAffinity字段，其下支持两种亲和性：
「requiredDuringSchedulingIgnoredDuringExecution」：requiredDuringScheduling表明其是一个强制性的调度，调度器只有在规则被满足的时候才能执行调度；而IgnoredDuringExecution则表明其不会影响已在节点上运行的Pod
「preferredDuringSchedulingIgnoredDuringExecution」：preferredDuringScheduling表明其是一个偏好性的调度，调度器会根据偏好优先选择满足对应规则的节点来调度Pod。但如果找不到满足规则的节点，调度器则会选择其他节点来调度Pod。而IgnoredDuringExecution则表明其不会影响已在节点上运行的Pod
强制性调度
这里提供了一个存在5个工作节点的K8s集群，然后我们使用Deployment部署了应用的前端服务
# 应用的前端服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-frontendspec: # Pod副本数量 replicas: 2 selector: matchLabels: app: frontend # Pod模板 template: metadata: # 标签信息: 应用的前端服务 labels: app: frontend spec: # 容器信息 containers: - name: my-app-frontend image: jocatalin/kubernetes-bootcamp:v1效果如下所示，可以看到前端服务运行了2个Pod。分别在my-k8s-cluster-multi-node-worker2、my-k8s-cluster-multi-node-worker3节点上
figure 1.jpeg
现在我们来部署应用的后端服务，这里我们期望后端服务的Pod能够运行在前端服务的Pod所在的节点上。这时就可以通过节点亲和性实现。具体地：
首先，使用podAffinity来定义Pod亲和性规则，使用requiredDuringSchedulingIgnoredDuringExecution定义强制性的调度规则
然后，使用标签选择器来确定Pod的范围，这里我们显然选择的是前端服务的Pod
最后，使用topologyKey来定义拓扑域信息，这里我们使用的是节点主机名。对于 此时即将被调度的新Pod 与 标签选择器所确定的Pod 来说，它们各自运行节点的主机名是相同的。即，后端服务的Pod 必须被调度到 与前端服务的Pod所在节点拥有相同主机名 的节点上
这样即可实现后端服务的Pod所在的节点上，一定存在前端服务的Pod
# 应用的后端服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-backendspec: # Pod副本数量 replicas: 4 selector: matchLabels: app: backend # Pod模板 template: metadata: # 标签信息: 应用的后端服务 labels: app: backend spec: # 亲和性 affinity: # Pod亲和性规则 podAffinity: # 强制性的调度规则, 但不会影响已在节点上运行的Pod requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostname # 标签选择器 labelSelector: matchLabels: app: frontend # 容器信息 containers: - name: my-app-backend image: tutum/dnsutils command: - sleep - infinity效果如下所示。后端服务的5个Pod均运行在my-k8s-cluster-multi-node-worker2、my-k8s-cluster-multi-node-worker3节点上
figure 2.jpeg
偏好性调度
这里提供了一个存在5个工作节点的K8s集群，然后我们使用Deployment部署了应用的前端服务
# 应用的后端服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-backendspec: # Pod副本数量 replicas: 2 selector: matchLabels: app: backend # Pod模板 template: metadata: # 标签信息: 应用的后端服务 labels: app: backend spec: # 容器信息 containers: - name: my-app-backend image: tutum/dnsutils command: - sleep - infinity效果如下所示，可以看到后端服务运行了2个Pod。分别在my-k8s-cluster-multi-node-worker、my-k8s-cluster-multi-node-worker3节点上。而通过标签信息可知，这两个节点都位于上海
figure 3.jpeg
现在我们来部署应用的缓存服务，这里我们期望 缓存服务Pod所在的节点 能够尽可能与 前端服务Pod所在的节点 在通过一个地理区域，以减少网络通讯的延迟。
首先，使用podAffinity来定义Pod亲和性规则，使用preferredDuringSchedulingIgnoredDuringExecution定义偏好性的调度规则。可通过权重值来定义对节点偏好，权重值越大优先级越高。其中，权重范围: 1~100
然后，使用标签选择器来确定Pod的范围，这里我们显然选择的是前端服务的Pod
最后，使用topologyKey来定义拓扑域信息，这里我们使用的是节点的Region标签地理位置。此时即将被调度的新Pod 将会更倾向于调度到 与标签选择器所确定的Pod的所在节点 具有相同Region标签值的节点当中。即，缓存服务的Pod的所在节点 与 后端服务的Pod的所在节点 将会尽可能得位于同一个地理区域（具有相同Region标签值）
# 应用的缓存服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-redisspec: # Pod副本数量 replicas: 4 selector: matchLabels: app: redis # Pod模板 template: metadata: # 标签信息: 应用的后端服务 labels: app: redis spec: # 亲和性 affinity: # Pod亲和性规则 podAffinity: # 偏好性的调度规则, 但不会影响已在节点上运行的Pod preferredDuringSchedulingIgnoredDuringExecution: - weight: 70 # 权重范围: 1~100, 权重值越大, 优先级越高 podAffinityTerm: topologyKey: Region # 标签选择器 labelSelector: matchLabels: app: backend # 容器信息 containers: - name: my-app-redis image: redis:3.2-alpine效果如下所示。缓存服务的4个Pod均运行同样位于上海的节点上。需要注意的是，由于这里是偏好性调度。故如果当上海的节点由于某种原因导致无法调度Pod到其上运行，调度器选择其他地域的节点进行调度也是合法的、允许的。比如这里位于广州的节点
figure 4.jpeg
Pod反亲和性
而Pod反亲和性，同样也是基于已经在节点上运行Pod的标签来约束新Pod可以调度到的节点。只不过其与Pod亲和性恰恰相反。即，如果X上已经运行了一个或多个满足规则Y的Pod，则这个新Pod不应该运行在X上。此外，Pod反亲和性使用podAntiAffinity字段，其下同样支持两种反亲和性：requiredDuringSchedulingIgnoredDuringExecution 强制性调度、preferredDuringSchedulingIgnoredDuringExecution 偏好性调度
强制性调度
这里提供了一个存在5个工作节点的K8s集群，然后我们使用Deployment部署了应用的后端服务。这里为了便于后续演示，我们规定后端服务的Pod只允许运行在上海的节点上
# 应用的后端服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-backendspec: # Pod副本数量 replicas: 5 selector: matchLabels: app: backend # Pod模板 template: metadata: # 标签信息: 应用的后端服务 labels: app: backend spec: # 配置节点选择器, 要求K8s只将该Pod部署到包含标签Region=ShangHai的节点上 nodeSelector: Region: ShangHai # 容器信息 containers: - name: my-app-backend image: tutum/dnsutils command: - sleep - infinity效果如下所示，可以看到后端服务运行了5个Pod。分别运行在位于上海的my-k8s-cluster-multi-node-worker、my-k8s-cluster-multi-node-worker3、my-k8s-cluster-multi-node-worker5节点上
figure 5.jpeg
现在我们来部署应用的前端服务，同时基于某种特殊原因的考量，我们期望该应用的前、后端服务的Pod分别运行在不同区域。即前端服务的Pod的运行在位于上海的节点，则我们希望后端服务的Pod运行在除上海之外的节点当中。这时就可以通过节点反亲和性实现。具体地：
首先，使用podAntiAffinity来定义Pod反亲和性规则，使用requiredDuringSchedulingIgnoredDuringExecution定义强制性的调度规则
然后，使用标签选择器来确定Pod的范围，这里我们显然选择的是后端服务的Pod
最后，使用topologyKey来定义拓扑域信息，这里我们使用的是节点的Region标签地理位置。对于 此时即将被调度的新Pod 与 标签选择器所确定的Pod 来说，它们各自运行节点的地理位置是不同的。即，后端服务的Pod 必须被调度到 与前端服务的Pod所在节点拥有不同地理位置 的节点上
# 应用的前端服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-frontendspec: # Pod副本数量 replicas: 5 selector: matchLabels: app: frontend # Pod模板 template: metadata: # 标签信息: 应用的前端服务 labels: app: frontend spec: # 亲和性 affinity: # Pod反亲和性规则 podAntiAffinity: # 强制性的调度规则, 但不会影响已在节点上运行的Pod requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: Region # 标签选择器 labelSelector: matchLabels: app: backend # 容器信息 containers: - name: my-app-frontend image: jocatalin/kubernetes-bootcamp:v1效果如下所示。前端服务的5个Pod均运行在位于广州的my-k8s-cluster-multi-node-worker2、my-k8s-cluster-multi-node-worker4节点上
figure 6.jpeg
偏好性调度
这里提供了一个存在5个工作节点的K8s集群，然后我们使用Deployment部署了应用的后端服务
# 应用的后端服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-backendspec: # Pod副本数量 replicas: 2 selector: matchLabels: app: backend # Pod模板 template: metadata: # 标签信息: 应用的后端服务 labels: app: backend spec: # 容器信息 containers: - name: my-app-backend image: tutum/dnsutils command: - sleep - infinity效果如下所示，可以看到前端服务运行了2个Pod。分别在my-k8s-cluster-multi-node-worker、my-k8s-cluster-multi-node-worker4节点上
figure 7.jpeg
现在我们来部署应用的缓存服务，这里由于后端服务、缓存服务都非常占用资源。故我们提出下述调度要求
缓存服务Pod所在的节点 能够尽可能与 前端服务Pod所在的节点 不是同一个节点
缓存服务Pod所在的节点 能够尽可能与 前端服务Pod所在的节点 不在同一个地理区域
上诉2点均为偏好性要求，且第1点优先级是最高的
首先，使用podAntiAffinity来定义Pod反亲和性规则，使用preferredDuringSchedulingIgnoredDuringExecution定义偏好性的调度规则。可通过权重值来定义偏好，权重值越大优先级越高。其中，权重范围: 1~100
然后，使用标签选择器来确定Pod的范围，这里我们显然选择的是前端服务的Pod
最后，使用topologyKey来定义拓扑域信息。这里我们分别使用了节点主机名、地理位置。以此实现即将被调度的新Pod 将会更倾向于调度到 与标签选择器所确定的Pod的所在节点 具有不同节点 或 不同地理区域的节点上
# 应用的缓存服务apiVersion: apps/v1kind: Deploymentmetadata: name: my-app-redisspec: # Pod副本数量 replicas: 4 selector: matchLabels: app: redis # Pod模板 template: metadata: # 标签信息: 应用的后端服务 labels: app: redis spec: # 亲和性 affinity: # Pod反亲和性规则 podAntiAffinity: # 偏好性的调度规则, 但不会影响已在节点上运行的Pod preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 # 权重范围: 1~100, 权重值越大, 优先级越高 podAffinityTerm: topologyKey: kubernetes.io/hostname # 标签选择器 labelSelector: matchLabels: app: backend - weight: 1 # 权重范围: 1~100, 权重值越大, 优先级越高 podAffinityTerm: topologyKey: Region # 标签选择器 labelSelector: matchLabels: app: backend # 容器信息 containers: - name: my-app-redis image: redis:3.2-alpine效果如下所示。缓存服务的4个Pod均运行在与后端服务Pod所在节点不同的节点上。但这里由于是偏好性调度，当最终结果未满足两个服务运行在不同的地理位置时，即调度器选择相同地理位置的节点进行调度也是合法的、允许的
figure 8.jpeg
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
