Shulou(Shulou.com)06/02 Report--

What is DaemonSet? Write DaemonSet specification required fields Pod template Pod Selector only runs Pod on certain nodes how to schedule Daemon Pod and Daemon Pod communication update DaemonSet DaemonSet alternative init script bare Pod static Pod Replication Controller

What is DaemonSet?

DaemonSet ensures that a copy of Pod is running on all (or some) nodes. When nodes join the cluster, a new Pod will also be added for them. These Pod are also recycled when nodes are removed from the cluster. Deleting a DaemonSet will delete all Pod that it creates.

Some typical uses of using DaemonSet:

Run the cluster storage daemon, such as glusterd and ceph on each node. Run log collection daemon on each node, such as fluentd, logstash. Run a monitoring daemon, such as Prometheus Node Exporter, collectd, Datadog agent, New Relic agent, or Ganglia gmond, on each node.

A simple use is to start a DaemonSet on all nodes, which will be used as each type of daemon. A slightly more complex use is to use multiple DaemonSet separately for each daemon type, but with different flags, and / or different memory and CPU requirements for different hardware types.

Write DaemonSet protocol

Required field

As with all other Kubernetes configurations, DaemonSet requires apiVersion, kind, and metadata fields. For basic information about configuration files, see the document deploying applications, configuration containers, and resource management.

DaemonSet also requires a .spec configuration segment.

Pod template

The only required field for .spec is .spec.template.

.spec.template is a Pod template. It has the same schema as Pod, except that it is nested and does not have apiVersion or kind fields.

In addition to the Pod required fields, the Pod template in DaemonSet must specify a reasonable label (see Pod Selector).

The Pod template in DaemonSet must have a RestartPolicy with a value of Always, or no value specified, and the default is Always.

Pod Selector

The .spec.selector field represents Pod Selector, which has the same effect as .spec.selector of Job or other resources.

Spec.selector represents an object, which consists of the following two fields:

MatchLabels-has the same effect as .spec.selector of ReplicationController. MatchExpressions-allows you to build more complex Selector by specifying key, value lists, and operators related to key and value lists.

When both fields are specified, the result represents an AND relationship.

If .spec.selector is specified, it must match .spec.template.metadata.labels. If not specified, they are equivalent by default. If it does not match their configuration, it will be rejected by API.

If the label of the Pod matches the selector, or is directly based on another DaemonSet, or Controller (such as ReplicationController), no Pod can be created. Otherwise, DaemonSet Controller will assume that it created those Pod. Kubernetes will not prevent this. In one scenario, you might want to manually create a Pod on a node with different values for testing.

Run Pod only on certain nodes

If .spec.template.spec.nodeSelector is specified, DaemonSet Controller creates a Pod on a node that can match Node Selector. In a similar case, you can specify .spec.template.spec.benchmark, and then DaemonSet Controller will create a Pod on a node that can match Node Affinity. If it is not specified at all, DaemonSet Controller creates a Pod on all nodes.

How to schedule Daemon Pod

Normally, it is up to the Kubernetes scheduler to choose which machine Pod runs on. However, the Pod created by Daemon Controller has determined which machine it is on (.spec.nodeName was specified when Pod was created), so:

DaemonSet Controller does not care about the unschedulable field of a node. DaemonSet Controller can create a Pod, even if the scheduler is not started yet, which is very helpful for cluster startup.

Daemon Pod cares about Taint and Toleration, which create a Toleration with NoExecute for node.kubernetes.io/not-ready and node.alpha.kubernetes.io/unreachable that do not specify tolerationSeconds. This ensures that node failures, such as network partitions, occur when the TaintBasedEvictions of the alpha feature is enabled, and they will not be cleared (when the TaintBasedEvictions feature is not enabled, it will not be cleared in these scenarios, but it will be cleared because of the hard-coding behavior of NodeController, not because of Toleration).

Communicate with Daemon Pod

To communicate with Pod in DaemonSet, several possible modes are as follows:

Push: configure Pod in DaemonSet to send updates to other Service, such as statistical databases. They don't have clients. NodeIP and known ports: Pod in DaemonSet can use hostPort so that Pod can be accessed through node IP. The client can know the node IP list in some way, and the port can also be known based on this. DNS: create a Headless Service with the same Pod Selector and then discover the DaemonSet by using the endpoints resource or retrieving multiple A records from the DNS. Service: create a Service with the same Pod Selector and use that Service to randomly access the daemon on a node (there is no way to access a specific node).

Update DaemonSet

If the node label (Label) is modified, DaemonSet immediately adds Pod to the node on the new match and removes the Pod on the node that has recently failed to match.

We can modify the Pod created by DaemonSet. However, updates to all fields of Pod are not allowed. The next time the node is created (even if it has the same name), DaemonSet Controller also uses the original template.

You can delete a DaemonSet. If you use kubectl and specify the-- cascade=false option, Pod is left on the node. You can then create a new DaemonSet with different templates. New DaemonSet with different templates will be able to match and identify all existing Pod by tags. It does not modify or delete them, even if they mismatch the Pod template. You can force the creation of a new Pod by deleting the Pod or by deleting the node.

In Kubernetes 1.6 or later, rolling upgrades can be performed on DaemonSet.

Future versions of Kubernetes will support controlled updates of nodes.

Alternative options for DaemonSet

Init script

We probably want to start the daemon process directly on a node (for example, using init, upstartd, or systemd). This is great, but there are some benefits to running these processes based on DaemonSet:

Like an application, it has the ability to monitor and manage logs for daemon. Use the same configuration language and tools (such as Pod templates, kubectl) for daemon and applications. Future versions of Kubernetes may support the integration of DaemonSet creation Pod and node upgrade workflow. Running daemon in a container with limited resources can increase the isolation of daemon and application containers. However, this also makes it possible to run daemon in a container, but not in Pod (for example, starting directly based on Docker).

Naked Pod

You may want to create a Pod directly, while specifying that it runs on a specific node. However, DaemonSet replaces Pod that has been deleted or terminated for any reason, such as node failure, routine node maintenance, kernel upgrade. For this reason, we should use DaemonSet instead of creating a Pod separately.

Static Pod

You may need to create a Pod by writing a file in a specified directory that is monitored by Kubelet. These Pod are called static Pod. Unlike DaemonSet, static Pod is not managed by kubectl and other Kubernetes API clients. Static Pod does not depend on apiserver, which makes them useful when a cluster is started. Moreover, static Pod may be abandoned in the future.

Replication Controller

DaemonSet is very similar to Replication Controller in that they both create Pod, and the processes corresponding to these Pod do not want to be terminated (for example, Web server, storage server). Using Replication Controller for stateless Service, such as front-end (Frontend) services, to expand and smoothly upgrade the number of replicas is much more important than precisely controlling the Pod to run on a host. When a copy of Pod is required to always run on all or specific hosts and needs to be started before other Pod, Daemon Controller should be used when this is considered very important

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.