Study guide
3.3 DaemonSets & StatefulSets Architecture
Certified Kubernetes Administrator CKA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CKA Exam Environment & Cluster Architecture
1.1 CKA Exam Mechanics, Scoring & Remote Terminal Environment 1.2 Kubernetes Control Plane & Worker Node Components 1.3 etcd Architecture, Clustering & Raft Consensus 1.4 Initializing Clusters with Kubeadm 1.5 Highly Available (HA) Control Plane Topologies 1.6 Cluster Lifecycle & Step-by-Step Upgrades 1.7 etcd Snapshot Backup and Restore Procedures
2 Chapter 2: Cluster Extensions, Packaging & RBAC
2.1 Kubernetes TLS Certificates & PKI Infrastructure 2.2 Managing Kubeconfig Files, Users, & Contexts 2.3 Installing Cluster Components with Helm & Kustomize 2.4 Role-Based Access Control (RBAC): Roles & RoleBindings 2.5 ClusterRoles & ClusterRoleBindings 2.6 Custom Resource Definitions (CRDs) & Operators 2.7 Pod Security Standards (PSS) & Admission Controllers
3 Chapter 3: Workloads, Lifecycle & Pod Scheduling
3.1 Pod Lifecycle, Multi-Container Patterns & Init Containers 3.2 Deployments: Rolling Updates, Rollouts & Rollbacks 3.3 DaemonSets & StatefulSets Architecture 3.4 Batch Workloads: Jobs & CronJobs 3.5 Managing ConfigMaps & Sensitive Data with Secrets 3.6 Resource Requests, Limits & Namespace ResourceQuotas 3.7 NodeSelectors, Node Affinity & Anti-Affinity 3.8 Node Taints & Pod Tolerations 3.9 Autoscaling: Horizontal Pod Autoscaler (HPA) & Custom Metrics
4 Chapter 4: Services, Networking & Ingress Architecture
4.1 Kubernetes IP-per-Pod Model & CNI Plugins (Flannel, Calico, Cilium) 4.2 Services Deep Dive: ClusterIP, NodePort, LoadBalancer & EndpointSlices 4.3 Kube-Proxy Service Dataplane: iptables, nftables, IPVS & eBPF 4.4 CoreDNS Configuration, Resolution & Custom Forwarding 4.5 NetworkPolicies: Ingress, Egress & Default-Deny Isolation 4.6 Ingress Architecture, Controllers & Path-Based Routing 4.7 Gateway API: GatewayClass, Gateway, HTTPRoute & Traffic Splitting 4.8 External Traffic Ingress: NodePort, Cloud LoadBalancers & MetalLB
5 Chapter 5: Storage Architecture & Persistent Volumes
5.1 Ephemeral Volumes, EmptyDir, HostPath & Config Volumes 5.2 PersistentVolumes (PV) & PersistentVolumeClaims (PVC) Lifecycle 5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes 5.4 Storage Access Modes, Reclaim Policies & Volume Expansion 5.5 Container Storage Interface (CSI) Architecture & Drivers 5.6 StatefulSet VolumeClaimTemplates & Persistent Storage Workflows
6 Chapter 6: Advanced Troubleshooting, Monitoring & Maintenance
6.1 Systematic Kubernetes Troubleshooting Methodology 6.2 Node Failure, Kubelet Diagnostics & Systemd Services 6.3 Control Plane Failures, Static Pods & Component Logs 6.4 etcd Troubleshooting, Quorum Loss & Database Defragmentation 6.5 Pod Startup Failures, CrashLoopBackOff & OOMKilled Diagnostics 6.6 Workload Scheduling Failures & Resource Constraint Resolution 6.7 Container & Node Logging Architecture, Journalctl & Fluentd 6.8 Metrics Server, Resource Utilization & Kubectl Top 6.9 Service, Endpoint & Ingress Connectivity Troubleshooting 6.10 Storage Failures: PVC Pending, Mount Failures & Multi-Attach Errors 6.11 NetworkPolicy Isolation & CoreDNS Resolution Diagnostics
3.3 DaemonSets & StatefulSets Architecture
Key Takeaways Explain This Topic AI
DaemonSets ensure a single copy of a designated Pod runs on all (or selected) nodes across the cluster, managed directly by the default kube-scheduler.
DaemonSets are the standard architecture for node-level agents, including CNI network plugins (Calico/Flannel), log shippers (Fluentd), and monitoring daemons (Node Exporter).
StatefulSets provide stable, unique network identities (predictable ordinal DNS names) and persistent storage bindings across Pod rescheduling and restarts.
A StatefulSet requires a dedicated Headless Service (clusterIP: None) to generate deterministic SRV and A records for peer discovery in distributed systems.
StatefulSet volumeClaimTemplates dynamically provision a dedicated PersistentVolumeClaim for each ordinal replica, which are intentionally retained upon Pod scale-down to protect state.
Last updated: August 2026
DaemonSets & StatefulSets Architecture
While Deployments manage stateless, interchangeable Pods, specialized workloads require distinct scheduling and identity guarantees. DaemonSets guarantee node-level infrastructure services (networking, logging, monitoring), while StatefulSets provide stable network identities, ordered rollouts, and persistent storage bindings for stateful distributed datastores (e.g., PostgreSQL, Kafka, Cassandra, ZooKeeper).
1. DaemonSet Architecture and Scheduling Mechanics
A DaemonSet ensures that all (or a subset of) nodes run exactly one copy of a Pod. As new nodes are added to the cluster, the DaemonSet controller automatically schedules the DaemonSet Pod onto them; as nodes are removed, those Pods are garbage collected. +-----------------------------------------------------------------------------------------+
- | DAEMONSET ARCHITECTURE |
- | |
- | +-----------------------+ |
- | | DaemonSet Controller | |
- | | (e.g., fluentd-logger)| |
- | +-----------------------+ |
- | | |
- | +----------------------------+----------------------------+ |
- | | | | |
- | v v v |
- | +---------------+ +---------------+ +---------------+ |
- | | Node 1 | | Node 2 | | Node 3 | |
- | | +-----------+ | | +-----------+ | | +-----------+ | |
- | | |DS Pod (1) | | | |DS Pod (2) | | | |DS Pod (3) | | |
- | | +-----------+ | | +-----------+ | | +-----------+ | |
- | +---------------+ +---------------+ +---------------+ |
- +-----------------------------------------------------------------------------------------+
- Primary Use Cases for DaemonSets
Cluster Network Routing (CNI) : kube-flannel-ds , calico-node , cilium .
Cluster Log Collection : fluentd , fluent-bit , promtail reading /var/log on host nodes.
Node Metrics & Hardware Monitoring : node-exporter , NVIDIA GPU device plugins.
Storage Daemons : ceph-osd , glusterd .
Modern DaemonSet Scheduling
In modern Kubernetes, DaemonSet Pods are scheduled by the standard kube-scheduler rather than the DaemonSet controller directly. The controller injects default Node Affinity terms ( spec.affinity.nodeAffinity ) matching kubernetes.io/hostname and automatically appends tolerations for built-in taints:
- node.kubernetes.io/not-ready:NoExecute
- node.kubernetes.io/unreachable:NoExecute
- node.kubernetes.io/disk-pressure:NoSchedule
- node.kubernetes.io/memory-pressure:NoSchedule
- node.kubernetes.io/unschedulable:NoSchedule apiVersion: apps/v1
- kind: DaemonSet
metadata:
- name: fluentd-logging
- namespace: kube-system
spec:
selector:
matchLabels:
name: fluentd-logger
template:
metadata:
labels:
name: fluentd-logger
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
- operator: Exists
- effect: NoSchedule
containers:
- name: fluentd
- image: fluent/fluentd-kubernetes-daemonset:v1.16-debian-elasticsearch
volumeMounts:
- name: varlog
- mountPath: /var/log
volumes:
- name: varlog
hostPath:
- path: /var/log
- DaemonSet Update Strategies
RollingUpdate (Default): Gradually terminates old DaemonSet Pods and creates new ones on each node. Supports maxUnavailable (default: 1) and maxSurge (Kubernetes 1.22+).
OnDelete : New Pods are only created when the old DaemonSet Pod on a node is manually deleted.
2. StatefulSet Architecture and Guarantees
StatefulSets manage stateful applications that require one or more of the following:
Stable, unique network identifiers .
Stable, persistent storage .
Ordered, graceful deployment and scaling .
Ordered, automated rolling updates . +-----------------------------------------------------------------------------------------+
- | STATEFULSET ARCHITECTURE |
- | |
- | StatefulSet: web (replicas: 3) |
- | Headless Service: nginx (clusterIP: None) |
- | |
- | [web-0] --------------------> Bound to PVC: [data-web-0] (PV-001) |
- | DNS: web-0.nginx.default.svc.cluster.local |
- | | |
- | v (Must be Ready before web-1 starts) |
- | [web-1] --------------------> Bound to PVC: [data-web-1] (PV-002) |
- | DNS: web-1.nginx.default.svc.cluster.local |
- | | |
- | v (Must be Ready before web-2 starts) |
- | [web-2] --------------------> Bound to PVC: [data-web-2] (PV-003) |
- | DNS: web-2.nginx.default.svc.cluster.local |
- +-----------------------------------------------------------------------------------------+
- Ordinal Indexing
For a StatefulSet with N N N replicas, each Pod is assigned an integer ordinal from 0 0 0 through N − 1 N-1 N − 1 . The Pod name is formatted as $(statefulset-name)-$(ordinal) (e.g., cassandra-0 , cassandra-1 , cassandra-2 ).
Headless Services ( clusterIP: None )
A StatefulSet requires a Headless Service ( spec.serviceName ) to govern the network domain. Because clusterIP is set to None , kube-DNS creates direct A records pointing to individual Pod IPs rather than a single virtual service IP:
- $(pod-name).$(service-name).$(namespace).svc.cluster.local
- Example: db-0.mysql-nodes.prod.svc.cluster.local
- 3. Persistent Volume Claim Templates ( volumeClaimTemplates )
Unlike Deployments where all Pods share the same PVC reference, a StatefulSet provisions a distinct PersistentVolumeClaim for each Pod replica using volumeClaimTemplates . apiVersion: apps/v1
kind: StatefulSet
metadata:
name: datastore
spec:
- serviceName: datastore-svc
- replicas: 3
selector:
matchLabels:
app: datastore
template:
metadata:
labels:
app: datastore
spec:
containers:
- name: redis
- image: redis:7.2-alpine
ports:
- containerPort: 6379
- name: redis
volumeMounts:
- name: redis-data
- mountPath: /data
volumeClaimTemplates:
- metadata:
name: redis-data
spec:
- accessModes: [ "ReadWriteOnce" ]
- storageClassName: "premium-ssd"
resources:
requests:
- storage: 50Gi
- Storage Lifecycle & Retention Policies
Scale-Down Non-Deletion : When a StatefulSet is scaled down (e.g., from 3 to 1), Pods datastore-2 and datastore-1 are deleted, but redis-data-datastore-2 and redis-data-datastore-1 are NOT deleted . This prevents data loss.
Pod Reattachment : If the StatefulSet is scaled back up to 3, the new datastore-1 and datastore-2 Pods automatically reattach to their existing corresponding PVCs.
persistentVolumeClaimRetentionPolicy (Kubernetes 1.27+ GA): Allows administrators to configure whether PVCs are deleted or retained when the StatefulSet is deleted ( whenDeleted ) or scaled down ( whenScaled ).
4. Deployment and Scaling Semantics
StatefulSets enforce strict ordering rules governed by spec.podManagementPolicy :
OrderedReady (Default)
Startup : Pods start sequentially from index 0 0 0 to N − 1 N-1 N − 1 . Pod i i i will not be created until Pod i − 1 i-1 i − 1 is fully Running and Ready .
Scale Down / Termination : Pods terminate in strict reverse order from N − 1 N-1 N − 1 down to 0 0 0 . Pod i i i must be completely shut down before Pod i − 1 i-1 i − 1 is terminated.
Parallel
Pods are created and scaled simultaneously without waiting for neighboring ordinals. Suitable for batch-style distributed compute tasks where order is irrelevant.
5. StatefulSet Partitioned Rolling Updates
StatefulSet RollingUpdate strategy supports canary testing via the partition parameter: spec:
updateStrategy:
type: RollingUpdate
rollingUpdate:
partition: 2
When partition: 2 is set on a 4-replica StatefulSet ( web-0 , web-1 , web-2 , web-3 ), only Pods with ordinal >= 2 ( web-2 and web-3 ) are updated to the new template.
Pods web-0 and web-1 continue running the old version.
Setting partition: 0 updates all remaining Pods.