Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to use the DaemonSet controller. The article is rich in content and analyzes and describes it from a professional point of view. I hope you can get something after reading this article.

Let's quickly experience the DaemonSet controller with a few simple examples.

Environmental preparation

We use the Kind tool to create a cluster of three nodes, using the following configuration:

[root@ecs-d8b6 book] # cat config_kind.yaml kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4nodes:- role: control-plane- role: worker- role: worker- role: worker

Then, create a v1.18.0 Kubernetes cluster:

[root@ecs-d8b6 book] # kind create cluster-- config config_kind.yaml-- image=kindest/node:v1.18.0Creating cluster "kind"... ✓ Ensuring node image (kindest/node:v1.18.0)? ✓ Preparing nodes?? ✓ Writing configuration?? ✓ Starting control-plane?? ️ ️ ️ ️️️️✓ Installing CNI? ✓ Installing StorageClass? ✓ Joining worker nodes? Set kubectl context to "kind-kind" You can now use your cluster with:kubectl cluster-info-context kind-kind

After the cluster is created, check whether each node is working properly:

[root@ecs-d8b6 book] # kubectl get nodesNAME STATUS ROLES AGE VERSIONkind-control-plane Ready master 3m6s v1.18.0kind-worker Ready 2m30s v1.18.0kind-worker2 Ready 2m31s v1.18.0kind-worker3 Ready 2m30s v1.18.0

You can see that all the nodes are in the Ready state, so next we create a DaemonSet object that ensures that a copy of the Pod is created on each working node.

Create

First, let's save the following configuration to a file named daemonset.yaml.

[root@ecs-d8b6 manifests] # cat daemonset.yaml apiVersion: apps/v1kind: DaemonSetmetadata: name: nginx-daemonset labels: app: nginxspec: selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.19.0

This configuration creates a DaemonSet object, and then the DaemonSet controller creates a copy of the Pod on each node based on the object information.

Next, use the kubectl create command to promote the configuration to kube-apiserver, as follows:

[root@ecs-d8b6 manifests] # kubectl create-f daemonset.yaml daemonset.apps/nginx-daemonset created View

First take a look at the DaemonSet object you just created:

[root@ecs-d8b6 manifests] # kubectl get daemonset NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGEnginx-daemonset 3 3 3 5m6s

The meanings of the fields in the command line output are as follows:

NAME: DaemonSet object name, same as metadata.name in configuration

DESIRED: the number of copies required. Since there is no deliberate filtering of nodes, the number of copies is equal to the number of nodes.

CURRENT: the number of copies currently created

READY: the number of copies in the Ready state

UP-TO-DATE: the number of Pod created by the latest Pod template

AVAILABLE: number of copies available

NODE SELECTOR: node selector. In this case, we have no choice, and the value is empty.

AGE: the time experienced since its creation.

In the above fields, in addition to NODE SELECTOR, we have already described it in the previous section. In fact, Node Selector is not a specific configuration of DaemonSet objects. It is a configuration used in Pod templates to match nodes for Pod. DaemonSet controllers use this Node Selector to filter nodes that need to create replicas. If not specified, all nodes are selected by default.

Next, look at the Pod copy information created by the DaemonSet controller:

[root@ecs-d8b6 manifests] # kubectl get pods-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-daemonset-78dbc 1 kind-worker3 nginx-daemonset-gmpdg 1 Running 0 5m13s 10.244.3.2 kind-worker3 nginx-daemonset-gmpdg 1 Running 0 5m13s 10.244.1.2 kind-worker2 Nginx-daemonset-l6wn4 1/1 Running 0 5m13s 10.244.2.2 kind-worker

As you can see, a copy is created on each node, as expected.

Update

Next we try to adjust the Pod deployment strategy. We only want Pod to run on a node named kind-worker, so we only need to configure the spec.template.spec.nodeSelector of the DaemonSet object to select the node.

There is a label that identifies the node in the node of the kind-worker:

Kubernetes.io/hostname: kind-worker

So the spec.template.spec.nodeSelector configuration of the DaemonSet object is as follows:

ApiVersion: apps/v1kind: DaemonSetmetadata:... spec:... Template:... Spec:... NodeSelector: kubernetes.io/hostname: kind-worker

Use the kubectl edit command to modify the configuration, and then observe the DaemonSet object and the copy of Pod again:

[root@ecs-d8b6 manifests] # kubectl get daemonsetsNAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGEnginx-daemonset 1 1 1 kubernetes.io/hostname=kind-worker 37m [root@ecs-d8b6 manifests] # kubectl get pods-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-daemonset-66gk2 1/1 Running 0 10s 10.244.2.3 kind-worker

You can find that in the DaemonSet status, NODE SELECTOR correctly reflects our changes, and the number of Pod copies of the requirements has become 1, as expected. The original 3 copies of Pod were reduced to 1, and only run on the node we selected.

Delete

Like other Pod controllers, when you delete a DaemonSet object, the Pod it manages is deleted by default, as follows:

[root@ecs-d8b6] # kubectl delete daemonsets nginx-daemonset daemonset.apps "nginx-daemonset" deleted [root@ecs-d8b6 ~] # kubectl get pods No resources found in default namespace. The above is the editor for you to share how to use the DaemonSet controller, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.