whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify node affinity in ScheduleDaemonSetPods

Browse Source 
> If node affinity of the DaemonSet pod already exists, it is replaced.

The original statement made it sound like the original node affinity was ignored when selecting the target node. Added clarification it is not the case. 

For reference, the DaemonSet controller behavior. 
https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/daemon/daemon_controller.go#L1194
This commit is contained in:
jqmichael
2020-05-09 18:40:18 -07:00
committed by GitHub
parent 2139b50702
commit 691f8667c6
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -125,7 +125,7 @@ That introduces the following issues:
scheduler instead of the DaemonSet controller, by adding the `NodeAffinity` term
to the DaemonSet pods, instead of the `.spec.nodeName` term. The default
scheduler is then used to bind the pod to the target host. If node affinity of
the DaemonSet pod already exists, it is replaced. The DaemonSet controller only
the DaemonSet pod already exists, it is replaced (the original node affinity was taken into account before selecting the target host). The DaemonSet controller only
performs these operations when creating or modifying DaemonSet pods, and no
changes are made to the `spec.template` of the DaemonSet.