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

Merge pull request #6240 from tkellen/patch-2

Browse Source 
updates for clarity on daemonset alternatives
This commit is contained in:
Qiming
2017-11-28 10:23:11 +08:00
committed by GitHub
parent edcb39d46c 3c5e4d225c
commit e342007415
1 changed files with 5 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/workloads/controllers/daemonset.md
+5 -9
View File
@@ -66,10 +66,10 @@ A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/user-guide/pod
The `.spec.selector` field is a pod selector. It works the same as the `.spec.selector` of The `.spec.selector` field is a pod selector. It works the same as the `.spec.selector` of
a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
As of Kubernetes 1.8, you must specify a pod selector that matches the labels of the As of Kubernetes 1.8, you must specify a pod selector that matches the labels of the
`.spec.template`. The pod selector will no longer be defaulted when left empty. Selector `.spec.template`. The pod selector will no longer be defaulted when left empty. Selector
defaulting was not compatible with `kubectl apply`. Also, once a DaemonSet is created, defaulting was not compatible with `kubectl apply`. Also, once a DaemonSet is created,
its `spec.selector` can not be mutated. Mutating the pod selector can lead to the its `spec.selector` can not be mutated. Mutating the pod selector can lead to the
unintentional orphaning of Pods, and it was found to be confusing to users. unintentional orphaning of Pods, and it was found to be confusing to users.
The `spec.selector` is an object consisting of two fields: The `spec.selector` is an object consisting of two fields:
@@ -119,7 +119,7 @@ they will not be evicted when there are node problems such as a network partitio
due to hard-coded behavior of the NodeController rather than due to tolerations). due to hard-coded behavior of the NodeController rather than due to tolerations).
They also tolerate following `NoSchedule` taints: They also tolerate following `NoSchedule` taints:
- `node.kubernetes.io/memory-pressure` - `node.kubernetes.io/memory-pressure`
- `node.kubernetes.io/disk-pressure` - `node.kubernetes.io/disk-pressure`
@@ -162,8 +162,6 @@ You will need to force new Pod creation by deleting the Pod or deleting the node
In Kubernetes version 1.6 and later, you can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet. In Kubernetes version 1.6 and later, you can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet.
Future releases of Kubernetes will support controlled updating of nodes.
## Alternatives to DaemonSet ## Alternatives to DaemonSet
### Init Scripts ### Init Scripts
@@ -174,8 +172,6 @@ running such processes via a DaemonSet:
- Ability to monitor and manage logs for daemons in the same way as applications. - Ability to monitor and manage logs for daemons in the same way as applications.
- Same config language and tools (e.g. Pod templates, `kubectl`) for daemons and applications. - Same config language and tools (e.g. Pod templates, `kubectl`) for daemons and applications.
- Future versions of Kubernetes will likely support integration between DaemonSet-created
Pods and node upgrade workflows.
- Running daemons in containers with resource limits increases isolation between daemons from app - Running daemons in containers with resource limits increases isolation between daemons from app
containers. However, this can also be accomplished by running the daemons in a container but not in a Pod containers. However, this can also be accomplished by running the daemons in a container but not in a Pod
(e.g. start directly via Docker). (e.g. start directly via Docker).