Containers are typically designed to be ephemeral and stateless, but many real-world applications — like databases, session stores, and machine learning pipelines — require stateful behavior. Managing state in containerized environments is a nuanced challenge, especially when using orchestration platforms like Kubernetes or Docker Swarm.

In this post, we compare how Kubernetes and Docker Swarm handle container state, discuss their respective approaches to persistence, storage, scaling, and provide best practices for managing stateful workloads.

What Does “Container State” Mean?

Container state includes:

  • Ephemeral runtime state (e.g., in-memory sessions)
  • Persistent data (e.g., files, databases)
  • Configuration state (e.g., environment variables, volumes)
  • Network identity (e.g., IPs, ports, DNS)

Stateless services can restart freely without loss. Stateful containers, however, need mechanisms to preserve state across failures, restarts, and scaling events.

Docker Swarm: Simpler, but Limited

Docker Swarm is Docker’s native orchestrator. It offers:

  • Simplicity in setup and configuration
  • Built-in service discovery
  • Volume mounting with named volumes or bind mounts

However, it has limitations:

  • Limited support for dynamic storage provisioning
  • No native stateful set abstraction
  • Volume plugins are not as mature or extensible

To manage state in Swarm:

  • Use named volumes for persistence
docker service create \
--name redis \
--mount type=volume,source=redis-data,target=/data \
redis

  • Volumes are node-specific unless external plugins are used (e.g., NFS, GlusterFS)

  • Failover to another node may break the state unless storage is replicated or shared

Kubernetes: Stateful Workloads at Scale

Kubernetes provides more robust state management with:

  • PersistentVolume (PV) and PersistentVolumeClaim (PVC)
  • StatefulSets for stable identities and ordered startup/shutdown
  • Support for dynamic volume provisioning
  • Integration with Storage Classes, CSI plugins, and cloud-native block/file storage

Example: A Redis StatefulSet in Kubernetes

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: redis
spec:
serviceName: redis
replicas: 3
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: data
mountPath: /data
volumeClaimTemplates:
- metadata:
  name: data
  spec:
  accessModes: [ "ReadWriteOnce" ]
  resources:
  requests:
  storage: 1Gi

Benefits:

  • Each pod gets a unique volume
  • Ordered deployment for consistency
  • Supports automatic failover with volume reattachment in many cloud environments

Comparing Key Features

Feature Docker Swarm Kubernetes
Volume Management Basic (Named Volumes, Bind Mounts) PV, PVC, Dynamic Provisioning
Stateful Abstractions None StatefulSets, DaemonSets
Storage Integrations Limited (via plugins) CSI, Cloud-native (EBS, GCE, Azure Disk)
Identity Management Container IP may change Stable Network ID via Headless Services
Rescheduling with State Manual or plugin-based Automatic (if backed by persistent PVC)
Ease of Use Simpler CLI, easier onboarding More complex, but more powerful

Best Practices for Stateful Containers

  1. Decouple compute and storage
    Use volumes for persistence, not the container filesystem.

  2. Use external storage plugins
    In Swarm, leverage NFS, GlusterFS, or Portworx to share volumes across nodes.

  3. Prefer Kubernetes StatefulSets for databases
    Especially when you need stable identities and persistent volumes.

  4. Backup your state
    Use scheduled snapshotting, volume backup tools, or external replication.

  5. Avoid local-only volumes
    They don’t survive node failure or migration.

  6. Label your storage needs
    In Kubernetes, use StorageClasses to fine-tune IOPS, zone affinity, and replication.

When to Use What?

  • Choose Docker Swarm for:
    • Simpler setups
    • Small-scale clusters
    • Stateless microservices
    • Edge/IoT deployments with known nodes
  • Choose Kubernetes for:
    • Production-grade HA workloads
    • Stateful services (databases, ML pipelines)
    • Dynamic scaling and rolling updates
    • Cloud-native storage integrations

Conclusion

Handling container state is one of the most challenging aspects of container orchestration. While Docker Swarm offers a quick and simple approach, Kubernetes excels in managing stateful workloads with robust abstractions, storage integrations, and automation.

Understanding how each platform approaches container state helps you architect resilient, scalable, and production-ready applications — whether you’re deploying a simple web service or a distributed database cluster.