> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Lab Solution DaemonSets optional > Guide to inspecting existing Kubernetes DaemonSets and creating a fluentd logging DaemonSet by converting a Deployment, with commands and verification steps In this lesson we inspect existing DaemonSets in the cluster and then create a simple fluentd logging DaemonSet by generating YAML from a Deployment and converting it to a DaemonSet. The steps below reproduce the commands, outputs, and edits needed to complete the lab. ## 1) How many DaemonSets exist in the cluster (all namespaces)? Run: ```bash theme={null} kubectl get daemonsets --all-namespaces ``` Example output: ```text theme={null} NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE kube-system kube-flannel-ds 1 1 1 1 1 24m kube-system kube-proxy 1 1 1 1 1 kubernetes.io/os=linux 24m ``` From the output above, there are two DaemonSets in the cluster: * `kube-flannel-ds` * `kube-proxy` Summary table | DaemonSet Name | Namespace | Desired | Ready | Node Selector | | - | - | - | - | - | | `kube-flannel-ds` | `kube-system` | 1 | 1 | `` | | `kube-proxy` | `kube-system` | 1 | 1 | `kubernetes.io/os=linux` | ## 2) Which namespace are the DaemonSets created in? Check the `NAMESPACE` column shown by `kubectl get daemonsets --all-namespaces` above. Both `kube-flannel-ds` and `kube-proxy` are in the `kube-system` namespace. Select `kube-system` when prompted in the lab. ## 3) Which of the following is a DaemonSet? From the list shown earlier, `kube-flannel-ds` and `kube-proxy` are DaemonSets. Other components such as `scheduler`, `coredns`, or `etcd-master` are not DaemonSets (they may be Deployments, static pods, or other controller types). ## 4) On how many nodes are the pods scheduled by the DaemonSet `kube-proxy`? Describe the DaemonSet in the `kube-system` namespace: ```bash theme={null} kubectl describe daemonset kube-proxy -n kube-system ``` Relevant excerpt (trimmed): ```text theme={null} Name: kube-proxy Selector: k8s-app=kube-proxy Node-Selector: kubernetes.io/os=linux Labels: k8s-app=kube-proxy Desired Number of Nodes Scheduled: 1 Current Number of Nodes Scheduled: 1 Number of Nodes Scheduled with Up-to-date Pods: 1 Number of Nodes Scheduled with Available Pods: 1 Pods Status: 1 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: k8s-app=kube-proxy Service Account: kube-proxy Containers: kube-proxy: Image: k8s.gcr.io/kube-proxy:v1.20.0 Command: /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=$(NODE_NAME) Environment: NODE_NAME: (v1:spec.nodeName) Mounts: /lib/modules from lib-modules (ro) /run/xtables.lock from xtables-lock (rw) ``` This output shows the DaemonSet is scheduling pods on 1 node. You can verify the cluster has one node with: ```bash theme={null} kubectl get nodes ``` Example output: ```text theme={null} NAME STATUS ROLES AGE VERSION controlplane Ready control-plane,master 26m v1.20.0 ``` So, in this cluster `kube-proxy` has pods scheduled on a single node. ## 5) What image is used by the pod deployed by the `kube-flannel-ds` DaemonSet? Describe `kube-flannel-ds`: ```bash theme={null} kubectl describe daemonset kube-flannel-ds -n kube-system ``` Relevant excerpt (trimmed): ```text theme={null} Name: kube-flannel-ds Selector: app=flannel Labels: app=flannel tier=node Desired Number of Nodes Scheduled: 1 Pods Status: 1 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: app=flannel tier=node Service Account: flannel Init Containers: install-cni: Image: quay.io/coreos/flannel:v0.13.1-rc1 Command: cp Args: -f /etc/kube-flannel/cni-conf.json /etc/cni/net.d/10-flannel.conflist Mounts: /etc/cni/net.d from cni (rw) /etc/kube-flannel/ from flannel-cfg (rw) Containers: kube-flannel: Image: quay.io/coreos/flannel:v0.13.1-rc1 Command: /opt/bin/flanneld ``` The `kube-flannel` container image is `quay.io/coreos/flannel:v0.13.1-rc1`. ## 6) Deploy a DaemonSet for fluentd logging You can author the DaemonSet manifest by hand or generate a resource YAML with `kubectl` and edit it. One convenient trick when a generator for a DaemonSet is not available is to generate a Deployment manifest and convert it to a DaemonSet by editing the file. You can generate YAML without creating the resource using `--dry-run=client -o yaml`. Generate the resource, edit the file to match DaemonSet semantics, and then apply it with `kubectl create -f` or `kubectl apply -f`. Follow these steps: 1. Generate a Deployment YAML for fluentd (dry run): ```bash theme={null} kubectl create deployment elasticsearch -n kube-system \ --image=k8s.gcr.io/fluentd-elasticsearch:1.20 \ --dry-run=client -o yaml > fluentd.yaml ``` The generated YAML will look similar to this (trimmed): ```yaml theme={null} apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: elasticsearch name: elasticsearch namespace: kube-system spec: replicas: 1 selector: matchLabels: app: elasticsearch template: metadata: creationTimestamp: null labels: app: elasticsearch spec: containers: - image: k8s.gcr.io/fluentd-elasticsearch:1.20 name: fluentd-elasticsearch resources: {} status: {} ``` 2. Edit `fluentd.yaml` to convert the Deployment into a DaemonSet: * Change `kind: Deployment` to `kind: DaemonSet`. * Remove `replicas` and any `strategy` fields (DaemonSets do not use them). * Ensure `.spec.selector.matchLabels` matches `.spec.template.metadata.labels`. * Add any necessary tolerations, volumes, and volumeMounts to match your cluster's logging needs. Warning: Make sure the DaemonSet selector matches the pod template labels exactly; otherwise `kubectl` will reject the manifest. If `.spec.selector.matchLabels` does not match `.spec.template.metadata.labels`, applying the manifest will fail. Always keep them in sync when converting Deployments to DaemonSets. After editing, the manifest might look like this example (trimmed for clarity): ```yaml theme={null} apiVersion: apps/v1 kind: DaemonSet metadata: labels: app: elasticsearch name: elasticsearch namespace: kube-system spec: selector: matchLabels: app: elasticsearch template: metadata: labels: app: elasticsearch spec: tolerations: - key: node-role.kubernetes.io/master operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true ``` (You can extend this manifest with additional volumes, config maps, or node selectors depending on your logging pipeline and cluster topology.) 3. Create the DaemonSet from the edited YAML: ```bash theme={null} kubectl create -f fluentd.yaml ``` Example output: ```text theme={null} daemonset.apps/elasticsearch created ``` 4. Verify the DaemonSet in the `kube-system` namespace: ```bash theme={null} kubectl get daemonsets -n kube-system ``` Example output after creation: ```text theme={null} NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE elasticsearch 1 1 0 1 0 10s kube-flannel-ds 1 1 1 1 1 29m kube-proxy 1 1 1 1 1 kubernetes.io/os=linux 29m ``` Note: In this simple example the newly created `elasticsearch` DaemonSet (the fluentd logging daemon) may take some time to become `READY`. Add required volumes, volume mounts, tolerations, and node selectors as appropriate for your cluster and logging pipeline. ## References * [DaemonSet — Kubernetes Concepts](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) * [kubectl create — Kubernetes CLI reference](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#create) * Fluentd images and examples: check the image repository used in your environment (for example, `k8s.gcr.io/fluentd-elasticsearch` and `quay.io/fluentd_elasticsearch/fluentd`) That completes the lab. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.