This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第 3 章 Using Jobs and DaemonSets
As an administrator, you can create and use daemon sets to run replicas of a pod on specific or all nodes in an OpenShift Container Platform cluster.
A daemon set ensures that all (or some) nodes run a copy of a pod. As nodes are added to the cluster, pods are added to the cluster. As nodes are removed from the cluster, those pods are removed through garbage collection. Deleting a daemon set will clean up the pods it created.
You can use daemon sets to create shared storage, run a logging pod on every node in your cluster, or deploy a monitoring agent on every node.
For security reasons, only cluster administrators can create daemon sets.
For more information on daemon sets, see the Kubernetes documentation.
Daemon set scheduling is incompatible with project’s default node selector. If you fail to disable it, the daemon set gets restricted by merging with the default node selector. This results in frequent pod recreates on the nodes that got unselected by the merged node selector, which in turn puts unwanted load on the cluster.
3.1.1. Scheduled by default scheduler 复制链接链接已复制到粘贴板!
A daemon set ensures that all eligible nodes run a copy of a pod. Normally, the node that a pod runs on is selected by the Kubernetes scheduler. However, previously daemon set pods are created and scheduled by the daemon set controller. That introduces the following issues:
-
Inconsistent pod behavior: Normal pods waiting to be scheduled are created and in Pending state, but daemon set pods are not created in
Pending
state. This is confusing to the user. - Pod preemption is handled by default scheduler. When preemption is enabled, the daemon set controller will make scheduling decisions without considering pod priority and preemption.
The ScheduleDaemonSetPods feature, enabled by default in OpenShift Container Platform, lets you to schedule daemon sets using the default scheduler instead of the daemon set controller, by adding the NodeAffinity
term to the daemon set 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 daemon set pod already exists, it is replaced. The daemon set controller only performs these operations when creating or modifying daemon set pods, and no changes are made to the spec.template
of the daemon set.
In addition, a node.kubernetes.io/unschedulable:NoSchedule
toleration is added automatically to daemon set pods. The default scheduler ignores unschedulable Nodes when scheduling daemon set pods.
3.1.2. Creating daemonsets 复制链接链接已复制到粘贴板!
When creating daemon sets, the nodeSelector
field is used to indicate the nodes on which the daemon set should deploy replicas.
Prerequisites
Before you start using daemon sets, disable the default project-wide node selector in your namespace, by setting the namespace annotation
openshift.io/node-selector
to an empty string:oc patch namespace myproject -p \ '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'
$ oc patch namespace myproject -p \ '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you are creating a new project, overwrite the default node selector:
`oc adm new-project <name> --node-selector=""`.
`oc adm new-project <name> --node-selector=""`.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure
To create a daemon set:
Define the daemon set yaml file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the daemon set object:
oc create -f daemonset.yaml
$ oc create -f daemonset.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To verify that the pods were created, and that each node has a pod replica:
Find the daemonset pods:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
hello-daemonset-cx6md 1/1 Running 0 2m hello-daemonset-e3md9 1/1 Running 0 2m
hello-daemonset-cx6md 1/1 Running 0 2m hello-daemonset-e3md9 1/1 Running 0 2m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow View the pods to verify the pod has been placed onto the node:
oc describe pod/hello-daemonset-cx6md|grep Node
$ oc describe pod/hello-daemonset-cx6md|grep Node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Node: openshift-node01.hostname.com/10.14.20.134
Node: openshift-node01.hostname.com/10.14.20.134
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe pod/hello-daemonset-e3md9|grep Node
$ oc describe pod/hello-daemonset-e3md9|grep Node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Node: openshift-node02.hostname.com/10.14.20.137
Node: openshift-node02.hostname.com/10.14.20.137
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- If you update a daemon set pod template, the existing pod replicas are not affected.
- If you delete a daemon set and then create a new daemon set with a different template but the same label selector, it recognizes any existing pod replicas as having matching labels and thus does not update them or create new replicas despite a mismatch in the pod template.
- If you change node labels, the daemon set adds pods to nodes that match the new labels and deletes pods from nodes that do not match the new labels.
To update a daemon set, force new pod replicas to be created by deleting the old replicas or nodes.