Create a DaemonSet

A DaemonSet ensures that each node in the cluster runs only one pod provisioned by the DaemonSet. If a new node is added to the cluster, a new pod is provisioned by the DaemonSet and is scheduled to the node. Daemonsets are suitable for deploying log collection components, such as Fluentd, and node monitoring agents, such as Prometheus Node Exporter. This topic introduces DaemonSets and describes how to create a DaemonSet in the Container Service for Kubernetes (ACK) console or by using kubectl.

Introduction to DaemonSets

By default, a DaemonSet ensures that each node in the cluster runs only one pod provisioned by the DaemonSet. However, the scheduling result of a DaemonSet is affected by the following scheduling policies. For more information about scheduling policies, see Scheduling.

Taints and tolerations: DaemonSet pods are not scheduled to nodes with taints that are not tolerated by the DaemonSets. By default, DaemonSets tolerate the following taints:
- node.kubernetes.io/unschedulable:NoSchedule
- node.kubernetes.io/not-ready:NoExecute: The pod remains on a node with this taint for 300 seconds before the pod is evicted.
- node.kubernetes.io/unreachable:NoExecute: The pod remains on a node with this taint for 300 seconds before the pod is evicted.
Node selectors: DaemonSet pods are scheduled based on the nodeSelector parameter. For example, if nodeSelector: { disktype: ssd } is specified in the configurations of a DaemonSet, the pods provisioned by the DaemonSet are scheduled only to nodes that have the disktype=ssd label.
Affinity rules: DaemonSet pods are scheduled based on node affinity, node anti-affinity, pod affinity, and pod anti-affinity rules.

Note

DaemonSets are not designed to meet pod scheduling requirements based on various scheduling policies. If you require complex pod scheduling, use Deployments. For information about how DaemonSets, see DaemonSet.

View kube-proxy pods

kube-proxy, a default component of Kubernetes, is deployed on each node as a DaemonSet. You can run the following command to view the pods of kube-proxy:

kubectl get pods --all-namespaces -o wide | grep kube-proxy

The following output shows that each node runs a kube-proxy pod. kube-proxy uses the host network of the node (hostNetwork: true). Therefore, the kube-proxy pods use the IP addresses of the nodes that host the pods.

kube-system     kube-proxy-worker-hfzkh     1/1     Running     0          2d21h   192.168.*.92    cn-shanghai.192.168.*.92   <none>           <none>
kube-system     kube-proxy-worker-pxnnf     1/1     Running     0          2d21h   192.168.*.11    cn-shanghai.192.168.*.11   <none>           <none>
kube-system     kube-proxy-worker-r2t26     1/1     Running     0          2d21h   192.168.*.7     cn-shanghai.192.168.*.7    <none>           <none>

You can use the ACK console or kubectl to create a DaemonSet.

ACK console

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. In the left-side pane, choose Workloads > DaemonSets.
In the upper-right corner of the DaemonSets page, click Create from Image.
Due to the characteristics of DaemonSets, application parameters in the following steps vary from those when you create a Deployment:
- Basic Information: The Replicas parameter is unavailable because the number of pods provisioned by a DaemonSet depends on the number of nodes in the cluster.
- Advanced: The Scaling section is unavailable because the number of pods provisioned by a DaemonSet depends on the number of nodes in the cluster.
Other parameters are the same as those when you create a Deployment. For more information about how to configure other parameters, see Create a stateless application by using a Deployment.

kubectl

Important

Before you create a workload, make sure that you have connected to the cluster by using kubectl. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Create a file named daemonset.yaml and copy the following content to the file:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-test
  namespace: default  # Change the namespace based on your business requirements.
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        resources:
          limits:
            cpu: '1'
            memory: 2Gi
          requests:
            cpu: 500m
            memory: 512Mi

Run the following command to create the DaemonSet:
```
kubectl apply -f daemonset.yaml
```
Expected output:
```
daemonset.apps/nginx-test created
```

Run the following command to query the details of the DaemonSet:

kubectl get pods --all-namespaces -o wide | grep nginx-test

The following output shows that each node runs a pod provisioned by the DaemonSet:

default     nginx-test-8mqvh     1/1     Running     0          3m38s   192.168.*.**    cn-shanghai.192.168.**.250   <none>           <none>
default     nginx-test-ltlx6     1/1     Running     0          3m38s   192.168.*.**    cn-shanghai.192.168.**.98    <none>           <none>
default     nginx-test-n6zrv     1/1     Running     0          3m38s   192.168.*.**    cn-shanghai.192.168.**.17    <none>           <none>

References

For more information about how to resolve the issues that occur when you create a workload, see FAQ about workloads.
For more information about how to troubleshoot pod exceptions, see Pod troubleshooting.