Deployment

Overview Both are Kubernetes controllers that manage sets of pods from a template, but they solve different problems: a Deployment treats pods as interchangeable, disposable replicas, while a StatefulSet gives each pod a stable name, network identity, and persistent storage that survives rescheduling. The choice matters because workloads like databases or clustered systems break if pod identity or storage isn’t preserved across restarts. Comparison Diagram DeploymentStatefulSetweb-7f9d4cweb-x9y8z2web-m4n5p6interchangeable, no stable identityweb-0web-1web-2pvc-0pvc-1pvc-2stable name, network ID & storage per pod Comparison Table Aspect Deployment StatefulSet Pod naming Random hash suffix per replica (web-7f9d4c-x2z9p), changes on every recreation Stable ordinal index (web-0, web-1, web-2) fixed for the pod’s lifetime Network identity Pods share a single Service VIP/DNS; individual pods have no predictable DNS name Requires a headless Service; each pod gets a stable DNS entry (web-0.svc.namespace) Storage PVCs, if used, aren’t guaranteed to reattach to the same pod on recreation volumeClaimTemplates provision a dedicated PVC per pod that persists and reattaches Scaling Creates or removes pods in parallel, in any order Scales one pod at a time in strict ordinal order (0, 1, 2, …) Rolling updates Replaces pods per maxSurge/maxUnavailable, order not guaranteed Updates pods one at a time in reverse ordinal order (N-1 down to 0) by default Failure recovery Replacement pod gets a new name and no guaranteed storage continuity Replacement pod keeps the same name/identity and reattaches its original PVC Typical workload Stateless web servers, APIs, workers that scale horizontally Databases, message queues, and clustered systems needing stable peers Key Differences Deployment pods get random names on every recreation, while StatefulSet pods keep a fixed ordinal name for life Only StatefulSet supports volumeClaimTemplates, giving each pod its own persistent volume that survives rescheduling StatefulSet requires a headless Service to give each pod a resolvable, stable DNS entry StatefulSet scales and updates pods in strict ordinal order; Deployment does both in parallel On node failure, Deployment pods lose their identity entirely, while StatefulSet pods are recreated with the same identity When to Use Each Deployment ...

Overview Immutable infrastructure treats servers as disposable artifacts — every change ships as a brand-new image that replaces the running instance rather than editing it. Mutable infrastructure instead updates in place, applying patches and config changes directly to long-lived servers. The choice determines how predictable, auditable, and drift-resistant your environments are. Comparison Diagram Immutable InfrastructureMutable InfrastructureImage v1Server v1terminatedImage v2Server v2live trafficchange = build new image,deploy new instance, discard oldServerv1 → v1.1 → v1.2patch in placechange = SSH in / run configmanagement, edit same instance Comparison Table Aspect Immutable Infrastructure Mutable Infrastructure Initial provisioning Instance built once from a versioned image or template Instance provisioned once, then edited repeatedly over its life Applying a change Rebuild the image with the change baked in SSH in, or run a config-management tool, against the live server Deployment mechanism Orchestrator replaces old instances with new ones (rolling/blue-green) Update scripts or agents (Ansible, Chef, Puppet) mutate the running instance Configuration drift Cannot occur — every instance matches its source image exactly Accumulates over time as ad hoc changes diverge from documented state Rollback Redeploy the prior image version, deterministic and fast Manually reverse changes on the server, often incomplete or unreliable Emergency hotfixes Requires rebuilding and redeploying an image, slower to react Can be patched directly on the box in seconds Auditability & reproducibility Image is a versioned artifact; environment is fully reproducible True state only knowable by inspecting the live server Pipeline & storage overhead Needs an image build pipeline and artifact/image registry Lower tooling overhead, no build pipeline required Key Differences Immutable instances are never touched after launch; mutable servers are patched in place. Immutable infrastructure eliminates configuration drift by construction. Rolling back immutable infra just means redeploying a prior image version. Mutable infra depends on ongoing config management tooling to keep state converged. Immutable workflows require an image build pipeline and registry that mutable setups skip. When to Use Each Immutable Infrastructure ...