OpenShift DaemonSet Concepts: Difference between revisions
| (10 intermediate revisions by the same user not shown) | |||
| Line 10: | Line 10: | ||
=Overview= | =Overview= | ||
A ''DaemonSet'' is a project-scoped OpenShift component that creates its associated pods and ensures they run on all (or some) nodes of a cluster. It is one of the [[OpenShift Concepts#Controller|pod controller]] types available in OpenShift. | A ''DaemonSet'' is a project-scoped OpenShift component that creates its associated pods and ensures they run on all (or some) nodes of a cluster. It is one of the [[OpenShift Pod Concepts#Controller|pod controller]] types available in OpenShift. | ||
If a node is added to the cluster, the DaemonSet insures that its associated pod will be scheduled on that node. When nodes are removed, the associated pods are shut down. Typical uses for DaemonSets are to run log collection agents ([[fluentd]], logstash), node monitoring agents (collectd) or a cluster storage daemon (glusterd, ceph). Usually, a DaemonSet is needed for each type of daemon. | If a node is added to the cluster, the DaemonSet insures that its associated pod will be scheduled on that node. When nodes are removed, the associated pods are shut down. Typical uses for DaemonSets are to run log collection agents ([[fluentd]], logstash), node monitoring agents (collectd) or a cluster storage daemon (glusterd, ceph). Usually, a DaemonSet is needed for each type of daemon. | ||
| Line 18: | Line 18: | ||
{{Internal|OpenShift DaemonSet Definition|DaemonSet Definition}} | {{Internal|OpenShift DaemonSet Definition|DaemonSet Definition}} | ||
The | The DamonSet picks nodes to place pods on based on a [[OpenShift Concepts#Node_Selector|node selector]] expression. The labels that are part of the node selector expression must be declared in the DaemonSet definition as shown below: | ||
... | ... | ||
spec: | |||
template: | |||
spec: | |||
nodeSelector: | |||
logging-infra-fluentd: "true" | |||
... | ... | ||
In order to become eligible for scheduling, the node must also be configured to expose the same labels. | |||
When a pod is managed by a DaemonSet, the node the pod is scheduled to run on is selected by the DaemonSet, so the [[OpenShift Concepts#Scheduler|scheduler]] ignores it. The "unschedulable" field of a node is not respected by the DaemonSet controller. Also, the DaemonSet controller can make pods even if the scheduler has not been started, and this helps with cluster bootstrap. The DaemonSet | When a pod is managed by a DaemonSet, the node the pod is scheduled to run on is selected by the DaemonSet, so the [[OpenShift Concepts#Scheduler|scheduler]] ignores it. The "unschedulable" field of a node is not respected by the DaemonSet controller. Also, the DaemonSet controller can make pods even if the scheduler has not been started, and this helps with cluster bootstrap. | ||
The DaemonSet decides whether it manages a pod or not based on the [[OpenShift Concepts#Selector|label selector]] expression specified in its [[OpenShift DaemonSet Definition#spec_selector|definition]]: | |||
... | ... | ||
spec: | |||
selector: | |||
matchLabels: | |||
component: fluentd | |||
provider: openshift | |||
... | ... | ||
In order to become eligible to be managed by the DaemonSet, the pod definition must declare the same labels, in the pod template’s [[OpenShift DaemonSet Definition#template_metadata_labels|label selector]]. | |||
[[Image:DaemonSet.png]] | [[Image:DaemonSet.png]] | ||
After a successful placement, the node selector expression is [[OpenShift Concepts#successful_node_selector_recorded |recorded in the pod's definition]]. | After a successful placement, the node selector expression is [[OpenShift Concepts#successful_node_selector_recorded |recorded in the pod's definition]]. | ||
==DaemonSet Operations | =Accessing Node Resources= | ||
==Accessing Node Directories== | |||
Node directories can be accessed as a [[OpenShift_Volume_Concepts#hostPath|hostPaths]]. | |||
=DaemonSet Operations= | |||
* [[OpenShift_DaemonSet_Operations#Obtaining_Information_about_DaemonSets|Obtaining information about DaemonSets]] | * [[OpenShift_DaemonSet_Operations#Obtaining_Information_about_DaemonSets|Obtaining information about DaemonSets]] | ||
* [[OpenShift_DaemonSet_Operations#Updating_Pods_Managed_by_DaemonSets|Updating pods managed by DaemonSets]] | |||
* [[OpenShift_DaemonSet_Operations#Creating_Daemon_Sets|Creating DaemonSets]] | * [[OpenShift_DaemonSet_Operations#Creating_Daemon_Sets|Creating DaemonSets]] | ||
Latest revision as of 01:13, 28 February 2018
External
- https://docs.openshift.com/container-platform/latest/dev_guide/daemonsets.html
- https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
Internal
Overview
A DaemonSet is a project-scoped OpenShift component that creates its associated pods and ensures they run on all (or some) nodes of a cluster. It is one of the pod controller types available in OpenShift.
If a node is added to the cluster, the DaemonSet insures that its associated pod will be scheduled on that node. When nodes are removed, the associated pods are shut down. Typical uses for DaemonSets are to run log collection agents (fluentd, logstash), node monitoring agents (collectd) or a cluster storage daemon (glusterd, ceph). Usually, a DaemonSet is needed for each type of daemon.
Example of DaemonSet definition:
The DamonSet picks nodes to place pods on based on a node selector expression. The labels that are part of the node selector expression must be declared in the DaemonSet definition as shown below:
...
spec:
template:
spec:
nodeSelector:
logging-infra-fluentd: "true"
...
In order to become eligible for scheduling, the node must also be configured to expose the same labels.
When a pod is managed by a DaemonSet, the node the pod is scheduled to run on is selected by the DaemonSet, so the scheduler ignores it. The "unschedulable" field of a node is not respected by the DaemonSet controller. Also, the DaemonSet controller can make pods even if the scheduler has not been started, and this helps with cluster bootstrap.
The DaemonSet decides whether it manages a pod or not based on the label selector expression specified in its definition:
...
spec:
selector:
matchLabels:
component: fluentd
provider: openshift
...
In order to become eligible to be managed by the DaemonSet, the pod definition must declare the same labels, in the pod template’s label selector.
After a successful placement, the node selector expression is recorded in the pod's definition.
Accessing Node Resources
Accessing Node Directories
Node directories can be accessed as a hostPaths.