StatefulSets Arrive: Running Stateful Workloads on Kubernetes

Introduction

Stateless microservices were Kubernetes’ bread and butter in early 2016. Running databases, queues, and other persistent systems demanded bespoke orchestration. Kubernetes 1.3 introduced PetSets (renamed to StatefulSets in 1.5), bringing ordered deployment, stable network identities, and persistent storage claims to the platform.

Why StatefulSets Matter

Stable Pod Identity: Pods receive deterministic names (mydb-0, mydb-1) and maintain their ordinal across restarts.
Persistent Storage: Each replica automatically attaches a unique PersistentVolumeClaim via volumeClaimTemplates.
Ordered Semantics: Pods deploy, scale, and update in sequence, honoring readiness before progressing.
Graceful Rolling Updates: Focused on OrderedReady strategy, ensuring N+1 updates don’t break quorum-based systems.

PetSets to StatefulSets

1.3 PetSets (Alpha): Introduced the core API behind a feature gate, limited to Kubernetes 1.3 and apps/v1alpha1.
1.5 Rename & Beta: Renamed to StatefulSets (apps/v1beta1), improving controller logic, scale operations, and storage integration.
API Evolution: Added podManagementPolicy and updateStrategy in beta, giving operators more control over start order and rolling updates.

Best Practices in 2016

Headless Services: Pair each StatefulSet with a headless service (clusterIP: None) to expose stable DNS (pod.service.namespace.svc.cluster.local).
Storage Classes: Use dynamic provisioning (GCE PD, AWS EBS) to automatically fulfill PVCs.
Init Containers: Seed data or run migrations per-pod before the main container starts.
PodDisruptionBudgets: Prevent voluntary disruptions from evicting too many replicas at once.
Backup Strategies: Combine StatefulSets with scheduled snapshots or database-specific backup jobs.

Example Manifest

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:3.2
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

Limitations & Roadmap

No Automated Failover: StatefulSets ensure ordering but leave database-specific failover logic to the application.
Volume Migration: Moving pods between zones/regions remained cloud-specific; multi-zone storage classes were just emerging.
Scaling Down: Deleting replicas does not remove PersistentVolumeClaims; clean up manually to reclaim storage.
Future Enhancements: Planned features included parallel pod management, rolling update partitioning, and volume resize.

Conclusion

StatefulSets turned Kubernetes from a stateless-only platform into a contender for persistent workloads. Combined with dynamic provisioning and improved controllers, operators could finally run databases, Kafka clusters, and other stateful systems with first-class primitives.

Table of Contents