StatefulSet Architectures with EKS

Kubernetes was initially designed for Stateless applications, but today it successfully manages Stateful workloads like databases (PostgreSQL, MongoDB), message queues (Kafka, RabbitMQ). On Amazon EKS, the StatefulSet resource is used for such applications.

Deployment vs StatefulSet

• Deployment: Pods are identical, names are random (app-5f4b-xyz). If one dies, a new one comes, identity doesn't matter.
• StatefulSet: Pods have a unique and persistent identity (app-0, app-1). They start and stop sequentially. Their persistent disks (PVC) also match the pod.

Storage: EBS vs EFS vs Local NVMe

There are 3 main storage options for StatefulSets on EKS:

1. Amazon EBS (gp3): Most common block storage. High performance. Disadvantage: Bound to a single AZ. Pod cannot move to another AZ.
2. Amazon EFS: File system. Supports Multi-AZ (Pod can run anywhere). Disadvantage: Slightly slower than EBS (Latency).
3. Local NVMe: Physical disk on EC2 instance. Highest performance. Disadvantage: If node dies, data is lost (Application must handle data replication, e.g., Cassandra, ElasticSearch).

Headless Service

A Headless Service (ClusterIP: None) is usually used with StatefulSet. This service does not perform load balancing; instead, it returns the DNS addresses of pods (e.g., redis-0.redis.default.svc.cluster.local) directly. This way, database members (Master/Slave) recognize each other.

Managing StatefulSet on EKS should be considered together with disk backup (Snapshot) and disaster recovery plans.