StatefulSet

Systems that use leader election or consensus protocols (like Raft) have strict requirements for member identity and startup sequence, which StatefulSets enforce.

• Predictable Network Identifiers: The stable DNS names (etcd-0.etcd-headless.default.svc.cluster.local) allow cluster members to discover each other reliably, forming a stable cluster membership list.
• Ordered, Graceful Startup: The orderedReady pod management policy ensures Pod n-1 is fully ready before Pod n is created. This allows for safe cluster bootstrap where the first pod (etcd-0) often initializes the cluster.
• Safe Updates & Failures: During a rolling update, pods are terminated and recreated in reverse order, helping to preserve quorum and leadership stability.

Applications that implement custom data sharding, where each pod is responsible for a specific subset of data (a shard), depend on StatefulSets for pod-specific storage and identity.

• Shard-Pod Affinity: Each shard (e.g., shard-0-data) is permanently associated with a specific pod (e.g., data-pod-0) via its persistent volume. The shard's data moves with its pod.
• Direct Addressing: Clients can address requests directly to a specific shard by connecting to the stable DNS name of its corresponding pod (data-pod-2.data-service).
• Scaling Complexity: Adding a new shard requires adding a new pod (scale up), which will create a new PVC for the new shard's data. Removing a shard (scale down) requires safely migrating its data first, as the associated PVC is not automatically deleted.

While DaemonSets are typical for node-level agents, StatefulSets are used for monitoring components that require their own persistent state, such as time-series databases or log aggregators.

• Prometheus with Long-Term Storage: A Prometheus server deployed as a StatefulSet can use a large persistent volume to store its time-series database (TSDB) blocks, surviving pod restarts.
• Dedicated Storage per Instance: In multi-tenant or high-availability setups, each instance of a monitoring service can have its own dedicated, persistent configuration and cache.
• Predictable Service Discovery: Other services can discover a specific monitoring pod instance via its stable hostname for direct debugging or querying.

Understanding the alternatives clarifies the StatefulSet's role. Use a Deployment with a ReplicaSet when:

• Statelessness: The application is truly stateless or stores state externally (e.g., in a cloud database).
• Fungible Pods: Any pod replica is identical and can handle any request. Pods do not need unique, stable identities.
• Simple Scaling & Updates: You require fast, parallel scaling and rolling updates without ordered constraints.
• Shared Storage: All pods can read from and write to the same ReadWriteMany (RWX) persistent volume.

Use a DaemonSet when you need one pod per node for cluster-wide services like logging, monitoring, or storage drivers.

The primary Kubernetes controller for managing stateless applications. It ensures a specified number of identical pod replicas are running and facilitates declarative updates via Rolling Updates. Unlike a StatefulSet, pods are fungible; they have no stable identity, and storage is typically ephemeral. Use Deployments for web servers, APIs, or any service where pods are interchangeable.

A controller that ensures a copy of a pod runs on all (or a subset of) nodes in the cluster. It is used for cluster-level infrastructure services that must run on every node, such as:

• Logging agents (e.g., Fluentd)
• Monitoring agents (e.g., Prometheus Node Exporter)
• Storage daemons
• Network plugins Pods are created and managed by the DaemonSet controller, not a user-specified replica count.

The underlying controller that maintains a stable set of replica Pods running at any given time. It is the core replication mechanism used by both Deployments and StatefulSets. A ReplicaSet ensures a specified number of pod replicas are running. It is identified by its selector, which determines which pods it manages. While you can use a ReplicaSet directly, Deployments provide a higher-level abstraction with update orchestration.

A request for storage by a user. It is a crucial companion to StatefulSets. Each pod in a StatefulSet can have its own PersistentVolumeClaim template, which dynamically provisions a PersistentVolume (PV). This binding provides the pod with durable, pod-specific storage that persists even if the pod is rescheduled to another node. PVCs abstract the details of the underlying storage infrastructure (e.g., AWS EBS, GCP Persistent Disk).

A Kubernetes Service with its clusterIP set to None. It is a mandatory component for a StatefulSet. Instead of load-balancing, a Headless Service returns the DNS records of all the Pods in the StatefulSet, enabling direct pod-to-pod communication. Each pod gets a stable DNS hostname following the pattern: $(pod-name).$(service-name).$(namespace).svc.cluster.local. This stable network identity is fundamental for stateful applications like databases (e.g., MongoDB replica set members).

Controllers for managing finite, batch-oriented tasks.

• Job: Creates one or more Pods and ensures a specified number of them terminate successfully. Used for one-off tasks like data migration or computation.
• CronJob: A Job that runs on a time-based schedule defined by a cron expression (e.g., "0 * * * *" for hourly jobs). Used for periodic tasks like backups or report generation. These contrast with StatefulSets/Deployments, which manage long-running, continuous workloads.