feat: add anti affinity to coredns deployment #249
Conversation
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
| affinity: | ||
| podAntiAffinity: | ||
| preferredDuringSchedulingIgnoredDuringExecution: | ||
| - podAffinityTerm: |
There was a problem hiding this comment.
Let's try to summarize what this is expressing. Is it:
"Don't schedule coredns pods onto a node that already has a kube-dns-labeled pod in the same availability zone."
There was a problem hiding this comment.
Yes, except it will only try, if it can't it will schedule both pods on the same node if no other is available.
There was a problem hiding this comment.
Indeed, thanks. Hence the preferredDuringSchedulingIgnoredDuringExecution instead of requiredDuringSchedulingIgnoredDuringExecution.
|
This looks sane to me pending E2E. @mboersma or @CecileRobertMichon, would appreciate a 2nd opinion. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: CecileRobertMichon, sylr The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Reason for Change:
Improve resilience of the coredns service with anti-affinity.
Those will try to spread coredns pods across
failure-domain zonesandnodesat scheduling.See:
https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
Issue Fixed:
Requirements:
Notes: