In the context of the Certified Kubernetes Administrator (CKA) exam, DaemonSets and StatefulSets are specialized controllers used for specific workload requirements that standard Deployments cannot handle efficiently.
DaemonSets ensure that a copy of a Pod runs on all (or a selected subset of) nod…In the context of the Certified Kubernetes Administrator (CKA) exam, DaemonSets and StatefulSets are specialized controllers used for specific workload requirements that standard Deployments cannot handle efficiently.
DaemonSets ensure that a copy of a Pod runs on all (or a selected subset of) nodes in the cluster. Unlike Deployments, which manage a specific count of replicas, DaemonSets focus on node coverage. They are primarily used for system daemons and background processes, such as log collectors (e.g., Fluentd), monitoring agents (e.g., Prometheus Node Exporter), or network proxies (e.g., kube-proxy). When a new node is added to the cluster, the DaemonSet controller automatically schedules a Pod onto it. In the exam, you may need to configure these using `nodeSelector` or Node Affinity to restrict them to specific hardware types.
StatefulSets are designed for stateful applications requiring unique, persistent identities and stable storage. While Deployments treat Pods as interchangeable (stateless), StatefulSets assign a sticky identity to each Pod with a deterministic name (e.g., `web-0`, `web-1`) and ordered deployment. They use `volumeClaimTemplates` to dynamically provision PersistentVolumeClaims (PVCs) for each replica, ensuring that if a Pod is rescheduled, it reattaches to its specific storage volume. This is critical for databases (like PostgreSQL or Cassandra) and distributed systems (like Zookeeper) where data consistency and network identity are paramount. A key CKA detail is that deleting a StatefulSet does not automatically delete the associated PVCs, protecting data from accidental loss.
Mastering DaemonSets and StatefulSets for CKA
Overview In the Certified Kubernetes Administrator (CKA) exam, understanding Workloads goes beyond standard Deployments. You must demonstrate competence in managing specific scheduling requirements and stateful applications using DaemonSets and StatefulSets.
1. DaemonSets What it is: A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Why it is important: They are crucial for cluster operational tasks that must run everywhere, regardless of application demand. Use Cases: - Cluster storage daemons (e.g., glusterd, ceph). - Log collection daemons (e.g., fluentd, logstash). - Node monitoring daemons (e.g., Prometheus Node Exporter). How it works: Unlike Deployments which focus on maintaining a specific number of replicas, the DaemonSet controller watches for Node creation. It respects Node Selectors and Affinity rules; if a node matches specific criteria, the DaemonSet ensures a Pod is scheduled there.
2. StatefulSets What it is: A workload API object used to manage stateful applications. It manages the deployment and scaling of a set of Pods, providing guarantees about the ordering and uniqueness of these Pods. Why it is important: Standard Deployments treat pods as interchangeable and stateless. Databases and distributed systems often require persistent identities and storage that survive pod restarts. Key Features: - Stable Network ID: Pods get predictable names (e.g., web-0, web-1) rather than random hashes. - Stable Storage: Uses volumeClaimTemplates to ensure each Pod gets its own PersistentVolumeClaim (PVC) that reattaches if the Pod is rescheduled. - Ordered Deployment: Pods are created sequentially (0, then 1, then 2).
Exam Tips: Answering Questions on DaemonSets and StatefulSets Tip 1: Identify the Requirement Look for keywords in the question. If it mentions "ensure a log agent runs on every node" or "run on all control-plane nodes," you need a DaemonSet. If it mentions "stable network identity,""ordered scaling," or "persistent storage per pod," you need a StatefulSet.
Tip 2: Generating YAML kubectl does not have a create command for DaemonSets or StatefulSets (e.g., there is no kubectl create daemonset). - For DaemonSets: Create a Deployment YAML first: kubectl create deploy my-ds --image=nginx --replicas=1 --dry-run=client -o yaml > ds.yaml. Open the file, change kind: Deployment to kind: DaemonSet, remove the replicas field, and remove the strategy field. - For StatefulSets: It is often faster to copy a skeletal manifest from the official Kubernetes documentation (allowed during the exam) rather than writing it from scratch, specifically to get the syntax for volumeClaimTemplates correct.
Tip 3: The Headless Service StatefulSets usually require a Headless Service (a service with clusterIP: None) to control the domain of its Pods. If an exam question asks you to deploy a StatefulSet, verify if you also need to create the accompanying Service to allow internal DNS resolution (e.g., web-0.nginx.default.svc.cluster.local).
Tip 4: Updates and Rollouts Remember that modifying a DaemonSet will trigger a rolling update on all nodes. In the exam, you might be asked to update the image of a DaemonSet. You can do this simply via kubectl set image ds/<name> <container-name>=<new-image>.