From e837312f1fb63baddbf1500af92ab811fa07f776 Mon Sep 17 00:00:00 2001 From: Janet Kuo Date: Thu, 3 Dec 2020 17:20:22 -0800 Subject: [PATCH] Remove problems in DaemonSet fixed by controllerRef The sentence describes a problem that's solved by the introduction of controllerRef (ownerRef with controller==true) feature. Removing it. --- content/en/docs/concepts/workloads/controllers/daemonset.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index ecf884884a..4dd784d905 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -87,12 +87,6 @@ When the two are specified the result is ANDed. If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API. -Also you should not normally create any Pods whose labels match this selector, either directly, via -another DaemonSet, or via another workload resource such as ReplicaSet. Otherwise, the DaemonSet -{{< glossary_tooltip term_id="controller" >}} will think that those Pods were created by it. -Kubernetes will not stop you from doing this. One case where you might want to do this is manually -create a Pod with a different value on a node for testing. - ### Running Pods on select Nodes If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will