kubernetes - 由于节点亲和性和 pod 亲和性，无法部署更新 Deployment

Question

所以我有 4 个节点。 1是System，1是Dev，1是Qa，1是UAT。

我的亲和性如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
  namespace: dev
  labels:
    app: auth
    environment: dev
    app-role: api
    tier: backend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
        environment: dev
        app-role: api
        tier: backend
      annotations:
        build: _{Tag}_
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - auth
            topologyKey: kubernetes.io/hostname
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: environment
                operator: In
                values:
                - dev
      containers:
        - name: companyauth
          image: company.azurecr.io/auth:_{Tag}_
          imagePullPolicy: Always
          env:
            - name: ConnectionStrings__DevAuth
              value: dev
          ports:
            - containerPort: 80
      imagePullSecrets:
        - name: ips

我打算确保在我的生产集群上，它在 3 个不同的可用性区域中有 3 个节点。所有 Pod 都将安排在不同的节点/可用区上。但是，如果我已经在节点上安排了 pod，那么当我进行部署时，它似乎不会覆盖已经存在的 pod。

0/4 个节点可用:1 个节点不匹配 pod 亲和性/反亲和性，3 个节点不匹配节点选择器。

但是，如果我删除 podAffinity，它会正常工作并且会用部署中的新 pod 覆盖当前节点。执行此操作的正确方法是什么，以确保我在生产集群上的部署始终在不同可用区的不同节点上安排一个 pod，并且还能够更新现有节点？

Answer 1

您的目标可以仅使用 PodAntiAffinity 来实现.

我已经使用我的 GKE 测试集群对此进行了测试，但它在 Azure 上的工作应该类似。

当前问题

在您当前的设置中，您已将 podAntiAffinity 设置为 nodeAffinity。

Pod anti-affinity can prevent the scheduler from locating a new pod on the same node as pods with the same labels if the label selector on the new pod matches the label on the current pod.

在您的Deployment 设置中，新的 pod 将具有 labels喜欢:

• app: auth
• 环境:dev
• app-role: api
• 层:后端

PodAntiAffinity 被配置为不允许部署新的 pod，如果已经有带有标签的 pod:app: auth。

NodeAffinity 被配置为仅在节点上 标签environment: dev 部署。

总结一下，你的错误:

0/4 nodes are available: 1 node(s) didn't match pod affinity/anti-affinity, 3 node(s) didn't match node selector.

1 node(s) didn't match pod affinity/anti-affinity

您的设置只允许在标签为 environment:dev 的节点上部署，并且只有一个标签为 app:auth 的 pod。

正如你所说

if I already have pods scheduled on a node, then when I do a deployment it will not overwrite the pods that already exist.

PodAntiAffinity 行为有效并且不允许部署带有标签 app: auth 的新 pod，因为已经有一个。

3 node(s) didn't match node selector.

NodeAffinity 允许仅在标签为 environment: dev 的节点上部署 pod。其他节点可能有标签，如 environment: system、environment: uat、environment: qa 与 environment: dev< 不匹配 标签因此与 node selector 不匹配。

解决方案

最简单的方法是删除 NodeAffinity。

虽然TolpologyKey在PodAntiAffinity中设置为kubernetes.io/hostname就足够了。

The topologyKey uses the default label attached to a node to dynamically filter on the name of the node.

更多信息请查看this article .

如果您将使用 kubernetes.io/hostname 描述您的 nodes 并 grep 它们，您将获得唯一值:

$ kubectl describe node | grep kubernetes.io/hostname
                    kubernetes.io/hostname=gke-affinity-default-pool-27d6eabd-vhss
                    kubernetes.io/hostname=gke-affinity-default-pool-5014ecf7-5tkh
                    kubernetes.io/hostname=gke-affinity-default-pool-c2afcc97-clg9

测试

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
  labels:
    app: auth
    environment: dev
    app-role: api
    tier: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
        environment: dev
        app-role: api
        tier: backend
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - auth
            topologyKey: kubernetes.io/hostname
      containers:
        - name: nginx
          image: nginx
          imagePullPolicy: Always
          ports:
            - containerPort: 80

部署此 YAML 之后。

$ kubectl get po -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP         NODE                                      NOMINATED NODE   READINESS GATES
auth-7fccf5f7b8-4dkc4   1/1     Running   0          9s    10.0.1.9   gke-affinity-default-pool-c2afcc97-clg9   <none>           <none>
auth-7fccf5f7b8-5qgt4   1/1     Running   0          8s    10.0.2.6   gke-affinity-default-pool-5014ecf7-5tkh   <none>           <none>
auth-7fccf5f7b8-bdmtw   1/1     Running   0          8s    10.0.0.9   gke-affinity-default-pool-27d6eabd-vhss   <none>           <none>

如果您将副本数增加到 7，则不会部署更多的 pod。当 antiPodAffinity 工作时，所有新的 pod 将停留在 Pending 状态(每个节点已经有标签为 app:dev 的 pod)。

$ kubectl get po -o wide
NAME                    READY   STATUS    RESTARTS   AGE    IP         NODE                                      NOMINATED NODE   READINESS GATES
auth-7fccf5f7b8-4299k   0/1     Pending   0          79s    <none>     <none>                                    <none>           <none>
auth-7fccf5f7b8-4dkc4   1/1     Running   0          2m1s   10.0.1.9   gke-affinity-default-pool-c2afcc97-clg9   <none>           <none>
auth-7fccf5f7b8-556h5   0/1     Pending   0          78s    <none>     <none>                                    <none>           <none>
auth-7fccf5f7b8-5qgt4   1/1     Running   0          2m     10.0.2.6   gke-affinity-default-pool-5014ecf7-5tkh   <none>           <none>
auth-7fccf5f7b8-bdmtw   1/1     Running   0          2m     10.0.0.9   gke-affinity-default-pool-27d6eabd-vhss   <none>           <none>
auth-7fccf5f7b8-q4s2c   0/1     Pending   0          79s    <none>     <none>                                    <none>           <none>
auth-7fccf5f7b8-twb9j   0/1     Pending   0          79s    <none>     <none>                                    <none>           <none>

High-Availability Deployment of Pods on Multi-Zone Worker Nodes 中描述了类似的解决方案博客。