EKS Advanced Controllers StatefulSets & DaemonSets

In Kubernetes, we have different “Controllers” for different jobs. Think of it like a construction site: you have a general contractor for the house (Deployment), a specialist for the foundation (StatefulSet), and a security guard for the perimeter (DaemonSet).

1. StatefulSets: The “Pet” Model

Standard Deployments treat Pods like “Cattle”—if one dies, a new one replaces it with a random name and a random IP. StatefulSets treat Pods like “Pets”—each one is unique, has a permanent name, and its own dedicated hard drive.

• Ordered Startup: Pods start one by one (Pod-0, then Pod-1, then Pod-2).
• Stable Network ID: If database-0 crashes, the replacement will be named database-0, not a random string.
• Stable Storage: If you have 3 Pods, each gets its own unique Persistent Volume. If Pod-1 moves to a different node, it takes its specific “Volume-1” with it.
• Use Case: Relational databases (PostgreSQL), NoSQL databases (MongoDB, Cassandra), and message queues (Kafka).

2. DaemonSets: The “Everywhere” Model

A DaemonSet ensures that all (or some) Nodes run a copy of a specific Pod. As you add more Worker Nodes to your EKS cluster, the DaemonSet automatically adds the Pod to the new nodes. If you remove a node, the Pod is garbage collected.

• No Replicas Needed: You don’t say “I want 3 replicas.” You just say “Run this everywhere.”
• Use Case: Log collectors (Fluentbit, Splunk), Monitoring agents (Datadog, Prometheus Node Exporter), and Networking plugins (AWS VPC CNI).

3. Comparison Table

Feature	Deployment	StatefulSet	DaemonSet
Naming	Random (web-abc12)	Ordered (db-0, db-1)	Node-specific
Scaling	Random/Parallel	Sequential (Ordered)	Automated per Node
Storage	Shared or None	Unique per Pod	Usually Host-path
Best For	Frontend/Stateless	Databases/Stateful	Logging/Monitoring

---

The comparison table at the end got a little compressed in your text, so I have formatted it into a clean layout below.

Kubernetes Controllers Comparison

Feature	Deployment	StatefulSet	DaemonSet
Naming	Random (e.g., web-abc12)	Ordered (e.g., db-0, db-1)	Node-specific
Scaling	Random / Parallel	Sequential (Ordered)	Automated per Node
Storage	Shared or None	Unique per Pod	Usually Host-path
Best For	Frontend / Stateless	Databases / Stateful	Logging / Monitoring

A Few Enhancements to Consider

If you are putting this together as a guide or reference material, here are a couple of quick additions that could make it even more comprehensive:

• DaemonSets & Taints/Tolerations: You accurately noted that DaemonSets run on “all (or some) Nodes.” It’s worth briefly mentioning that to run on some nodes (like GPU-only nodes or strictly worker nodes), DaemonSets rely on nodeSelector, affinity, or tolerating specific node Taints.
• DaemonSet Security: Since DaemonSets are often used for log collectors (like Fluent Bit) or security monitors (like Aqua or Datadog), they frequently require elevated privileges (like hostPath mounts) compared to standard Deployment pods.

To complete your construction site analogy, you might also want to include Jobs and CronJobs—the “temporary contractors” who come in to execute a specific, finite task (like a database migration or a nightly backup) and leave once the work is successfully completed.