Kubernetes PodAffinity not able to deploy pods

user_6716204 0
Viewed 1079

So I have this problem, and try to implement podAffinity to solve it.

I have 3 nodes and want to deploy 2 pods on the same node. In the Deployment YAML files I have service:git under metadata.labels, and the following is the affinity setting:

  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: service
            operator: In
            values:
            - git
        topologyKey: kubernetes.io/hostname

But the pods failed to deploy, I got the following error:

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

Are there any problems with my configuration?

If not, I guess maybe it is because when the first pod is deployed, the system will try to find a node that contains a pod with the label service: git and fail (because it is the first one), and another pod also fail because of the same reason. Is this correct?

But then how to solve the problem (without resorting to workarounds)?

kubernetes-pod kubernetes
2 Answers
  • You are using "requiredDuringSchedulingIgnoredDuringExecution:" so it will be looking a "running(already)" pod which has a label "service: git" and itseems you do not already have any pod with that label. so following a is a quick workaround where a test pod will be created with label "service: git" . so that podAffinity rule will find a destination node ( that would be the node where this testpod will be running)

kubectl run testpod --image=busybox --labels="service=git" -- sleep infinite

  • Once above pod is UP .. all the pods in your deployment also should get created. if not delete the deployment and re-apply it.

  • If you need a elegant solution then you can consider using "preferredDuringSchedulingIgnoredDuringExecution" instead of "requiredDuringSchedulingIgnoredDuringExecution"

user_36380810

Update Sept 2022:

The "requiredDuringSchedulingIgnoredDuringExecution:" is effectively ignored when it is the first pod of the deployment and the pod does in fact get scheduled - otherwise if no pods are there then not even the first one will be able to be deployed. The second pod will then obviously see that first pod running and satisfy the rule and so on. This has been confirmed by testing.

user_197489730
Related