Overview Both controllers watch metrics and adjust Kubernetes workloads automatically, but they scale in different dimensions. The Horizontal Pod Autoscaler adds or removes pod replicas to handle load, while the Vertical Pod Autoscaler resizes the CPU and memory requests/limits of existing pods. Comparison Diagram Horizontal Pod AutoscalerVertical Pod Autoscalerbeforepodafter (load increases)podpodpodScale OUTmore replicas, same pod sizebeforepodafter (load increases)podCPU/mem ↑Scale UPbigger pod, same replica count Comparison Table Aspect Horizontal Pod Autoscaler Vertical Pod Autoscaler What it adjusts Number of pod replicas in a Deployment/ReplicaSet/StatefulSet CPU and memory requests/limits on the pod’s containers Metrics source Metrics Server or custom/external metrics (CPU, memory, custom queries) via metrics.k8s.io API Historical and current usage sampled by the VPA recommender component Trigger condition Observed metric crosses a target threshold averaged across pods Recommender detects requests are consistently over- or under-provisioned Action taken Creates or deletes pod replicas to match target replica count Evicts and recreates pods with new resource requests (or just recommends, depending on updateMode) Disruption to running pods None — existing pods are untouched, new ones are added or removed Pod restart required to apply new resource values, causing brief downtime unless using in-place resize Best fit for workload type Stateless, horizontally scalable services behind a Service/load balancer Single-instance or hard-to-replicate workloads, or right-sizing before enabling HPA Conflict risk Can fight with VPA if both manage CPU on the same workload Should not manage CPU/memory targeted by HPA on the same workload simultaneously Configuration object HorizontalPodAutoscaler resource with min/max replicas and target metrics VerticalPodAutoscaler resource with updateMode (Off, Initial, Recreate, Auto) Key Differences HPA changes replica count, VPA changes resource requests on existing pods. VPA updates typically require a pod restart to take effect, while HPA scaling adds/removes pods without disrupting the rest. Running both on the same metric (like CPU) causes conflicting decisions unless carefully scoped. VPA is often used in recommendation-only mode to right-size requests before HPA takes over scaling. HPA assumes the workload is stateless and replicable; VPA fits singleton or stateful workloads that can’t simply be duplicated. When to Use Each Horizontal Pod Autoscaler ...

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 Kubernetes uses liveness and readiness probes to answer two different questions about a running container: is it alive, and is it ready to serve requests. A failed liveness probe triggers a container restart, while a failed readiness probe only affects traffic routing by pulling the pod out of Service endpoints without killing it. Comparison Diagram Liveness ProbeReadiness ProbeContainerkubelet: is it alive?Fails?yesKill & Restart ContainernostaysrunningNo effect on Service trafficContainerkubelet: is it ready?Ready?yesAdded to Service EndpointsnoRemoved(not killed)Service / Load Balancer Comparison Table Aspect Liveness Probe Readiness Probe Core question Is the process still functioning? Is the process ready to accept traffic? Action on failure kubelet kills and restarts the container Container is left running, no restart Effect on Service endpoints None directly; pod may keep receiving traffic until restart completes Pod is removed from Service endpoints, stops receiving traffic Effect on rolling deployments Not consulted for rollout progress Must pass before the pod counts as available and rollout proceeds Restart count impact Increments the container restart count on each failure Never causes a restart Typical checks used Lightweight self-check for hangs or deadlocks Checks dependency health: DB connections, cache warm-up, config load Misconfiguration risk Too-aggressive thresholds cause restart loops (CrashLoopBackOff) Too-aggressive thresholds pull healthy pods out of rotation, cutting capacity Key Differences Liveness failure causes a container restart; readiness failure only removes the pod from Service endpoints. Liveness answers “is it alive,” readiness answers “is it ready for traffic.” Readiness gates rolling deployments; liveness has no say in rollout progress. Using a dependency check as a liveness probe risks a restart loop when the real problem is an external service, not the process. When to Use Each Liveness Probe ...

Overview Helm packages Kubernetes manifests as parameterized charts rendered through a Go templating engine, then tracks each install as a versioned release. Kustomize takes plain manifests and applies declarative overlays that patch a base configuration per environment, with no templating language or release state at all. Comparison Diagram HelmKustomizeCharttemplates/*.yaml + values.yamlhelm template / installRendered manifeststracked as a ReleaseClusterbase/plain manifestsoverlays/prodpatcheskustomize buildMerged manifestsno state trackedCluster Comparison Table Aspect Helm Kustomize Configuration model Go template engine that generates YAML text before it’s parsed Native Kubernetes objects patched via strategic merge or JSON patch Input format Chart with templates/, values.yaml, and Chart.yaml metadata Plain, valid YAML manifests plus a kustomization.yaml Parameterization Placeholder values injected as text, so output can become invalid YAML if misused Structured patches applied to already-valid objects, so output stays schema-correct Environment customization Layered values files (values-prod.yaml) merged into one chart Overlay directories per environment referencing a shared base Packaging & distribution Versioned, shareable chart archives published to chart repositories or OCI registries No packaging format; kustomization directories are just checked into git Dependency management Subcharts declared in Chart.yaml and pulled via helm dependency update Bases and components composed by referencing other directories Deployment execution helm install/upgrade tracks a named release and its revision history kustomize build pipes to kubectl apply with no release object created Rollback & drift helm rollback reverts to a stored prior release revision No built-in rollback; relies on git revert or kubectl’s own history Key Differences Helm renders manifests through text templating, while Kustomize edits already-parsed objects via structural patches Helm tracks installs as stateful releases with revision history; Kustomize has no release state at all Helm charts are packaged and versioned for reuse; Kustomize configs are just plain manifests in git Kustomize is built into kubectl directly, while Helm requires installing a separate CLI/tool Many teams combine both: a Helm chart as the base, customized per environment with Kustomize’s overlay patches When to Use Each Helm ...

Overview An API gateway sits at the edge of your system, managing traffic between external clients and your services. A service mesh operates inside the cluster, managing traffic between services themselves. Confusing the two leads teams to either duplicate cross-cutting concerns or push edge-only features into infrastructure that was never designed for public-facing traffic. Comparison Diagram API GatewayService MeshClientAPI GatewayauthN · rate limitrouting · transformclusterService AService BService Csidecar proxymTLS · retriesnorth–south: client-to-serviceeast–west: service-to-service Comparison Table Aspect API Gateway Service Mesh Traffic direction North-south: external clients entering the system East-west: internal service-to-service calls Deployment topology Centralized cluster of edge instances fronting all traffic Sidecar proxy injected alongside every service instance Primary concerns AuthN/authZ, rate limiting, request/response transformation, API versioning mTLS, load balancing, retries, circuit breaking between services Routing basis Public API path, host, or version mapped to a backend service Service identity and destination within the internal network Observability scope Per-endpoint metrics: request volume, latency, errors by client Full service dependency graph: per-hop latency and error rates Failure containment Blocks or throttles bad traffic before it reaches any backend Isolates failures at individual hops so one bad service doesn’t cascade Operational overhead Few instances to scale and configure centrally One proxy per workload, plus a control plane to manage them all Key Differences An API gateway is the single entry point clients hit; a service mesh has no single entry point, it’s woven through every service. Gateways enforce policy once at the edge; meshes enforce policy per sidecar on every call. Gateways typically run as a small number of centralized instances; meshes scale linearly with your service count. Meshes give you mTLS and retries between internal services, something a gateway never sees because that traffic never reaches it. Many production systems run both together, not as alternatives, since they solve problems at different layers. When to Use Each API Gateway ...

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 ...

Overview Both aim to automate software delivery, but they differ in who initiates the deployment and where the source of truth lives. Traditional CI/CD pushes changes into infrastructure from an external pipeline, while GitOps has an in-cluster agent continuously pull and reconcile state against a Git repository. The distinction matters most for security posture, drift handling, and auditability in Kubernetes-native environments. Comparison Diagram Traditional CI/CD push-based GitOps pull-based Git Repo merge trigger CI/CD Pipeline kubectl apply (holds cluster creds) Production Cluster external system pushes with cluster creds Git Repo Production Cluster (GitOps agent) pulls & diffs state agent auto-reconciles drift, no external creds Comparison Table Aspect Traditional CI/CD GitOps Deployment trigger Pipeline job runs on merge/tag and executes a deploy step In-cluster agent continuously polls or watches the Git repo for changes Source of truth Pipeline scripts and job history define what was deployed Git repository is the sole declarative source of desired state Cluster access model CI server holds cluster credentials and pushes from outside the network Agent runs inside the cluster; no external system needs cluster credentials Drift detection None built-in; manual kubectl edits go unnoticed until the next run Agent continuously compares live state to Git and flags or corrects drift Rollback Re-run the pipeline against a previous artifact or commit git revert triggers an automatic re-sync to the prior state Audit trail Split across CI logs, deploy scripts, and any manual changes Single, complete history captured in Git commit log Multi-cluster scaling Pipeline needs explicit logic and credentials per target environment Each cluster runs its own agent watching the same or a branched repo Key Differences CI/CD is push-based from an external system; GitOps is pull-based from inside the cluster GitOps treats the Git repo as the exclusive source of truth; CI/CD’s truth lives in pipeline state CI/CD requires the pipeline to hold cluster credentials; GitOps keeps them inside the cluster boundary GitOps performs automatic drift correction; CI/CD has no ongoing reconciliation Rollback in GitOps is a simple git revert instead of re-running a pipeline job When to Use Each Traditional CI/CD ...

Overview Docker packages an application and its dependencies into a portable container image and runs it on a single host, while Kubernetes schedules, scales, and heals many containers across a cluster of machines. They aren’t direct substitutes — Kubernetes typically runs containers built by Docker (or another OCI-compatible tool), sitting one layer above it. Comparison Diagram DockerKubernetesSingle Hostapp Aapp Bapp Cidledocker runmanual, per-hostif host dies, all lostControl PlaneNode 1Node 2Node 3scheduler places podsauto-reschedules on failuredeclarative, cluster-wide Comparison Table Aspect Docker Kubernetes Core purpose Build, package, and run containers from a single image spec Orchestrate and manage many containers across a fleet of machines Unit of work Container, defined by a Dockerfile and run via docker run Pod, a group of one or more containers scheduled together Deployment scope Single host (or manually scripted across hosts) Multi-node cluster with a control plane scheduling workloads Configuration model Imperative CLI commands or docker-compose.yml Declarative YAML manifests reconciled continuously toward desired state Networking & discovery User-defined bridge networks and container name resolution Cluster-wide Services, DNS, and Ingress across nodes Scaling Manual — start more containers or use docker-compose scale Automated via ReplicaSets and Horizontal Pod Autoscaler Failure recovery No built-in restart across host failure; relies on restart policies per host Self-healing — reschedules pods automatically if a node or container fails Rollouts & updates Rebuild image and manually restart containers Rolling updates and rollbacks managed declaratively per Deployment Key Differences Docker operates at the level of a single container; Kubernetes operates at the level of a cluster. Kubernetes doesn’t replace Docker — it typically schedules containers that Docker (or another container runtime) built and runs. Docker’s model is largely imperative, while Kubernetes is fundamentally declarative, continuously reconciling actual state to desired state. Kubernetes adds self-healing and autoscaling that plain Docker has no native concept of. For a single app on one machine, Kubernetes’ control plane overhead is often unjustified complexity. When to Use Each Docker ...

Overview CI (Continuous Integration) and CD (Continuous Delivery/Deployment) are two connected stages of the same pipeline, not synonyms. CI focuses on automated testing of every code change as it merges, while CD focuses on automated deployment of that validated code into staging or production. Teams that only automate the first half often assume they have full ‘CI/CD’ when they’ve really just automated build-and-test. Comparison Diagram CICDCommitBuildTestPackageStagingProductionRuns automatically on every commitDelivery: manual approval before ProductionDeployment: fully automatic, no gateCI verifies the code — CD gets it running Comparison Table Aspect CI (Continuous Integration) CD (Continuous Delivery/Deployment) Trigger Code commit or push to a shared repository A successful CI run producing a new build artifact Core process Compile, run unit/integration tests, static analysis Package the artifact, provision environments, run deployment scripts Primary output A verified, mergeable build artifact A running release in staging and/or production Environment scope Build server or ephemeral test environment Staging and/or production environments Human gate None — fully automated on every commit Optional manual approval (Delivery) or none (Deployment) Release cadence N/A — runs per commit, not a release event Can range from multiple times a day to once per commit Failure consequence Blocks the merge; breaks the build for the team Blocks or rolls back the release; production stays on the last good version Primary goal Catch integration bugs early, keep the main branch releasable Get every releasable build to users quickly and safely Key Differences CI’s output is a verified build artifact, not a live release CD adds environment provisioning and deployment steps that CI never performs A CI failure blocks the merge; a CD failure blocks the rollout instead Continuous Delivery keeps a manual approval gate before production, while Continuous Deployment removes it CI runs on every single commit; CD can be throttled by environment or business readiness When to Use Each CI (Continuous Integration) ...

Overview Blue-green and canary deployment are both techniques for releasing new code with minimal downtime, but they differ in how traffic moves to the new version. Blue-green performs an instant cutover between two full environments, while canary performs a gradual rollout to a small slice of live traffic before expanding. Comparison Diagram Blue-GreenCanaryRouterBlueactiveGreenidle100%0%instant switch on cutoverRouterStable v195%Canary v25%gradual shift by percentage Comparison Table Aspect Blue-Green Deployment Canary Deployment Environment topology Two full, identical production environments (blue and green) Single environment with a small subset of new-version instances alongside the old Traffic routing Router/load balancer switches all traffic at once between environments Load balancer incrementally shifts a percentage of traffic from old to new Rollout progression Binary cutover: 0% or 100% to the new environment Staged progression, e.g. 5% -> 25% -> 50% -> 100% Validation approach New version smoke-tested in green before it receives any live traffic New version validated using real live traffic on a limited subset Rollback speed Instant - flip the router back to the blue environment Fast but partial - reduce canary percentage to 0, though some users already saw it Failure blast radius Zero pre-cutover, but 100% of users once switched Limited to whatever percentage of traffic is on the canary at the time Infrastructure cost Requires double full production capacity during the deploy window Requires only incremental capacity for the canary instances Tooling requirement Needs environment provisioning and DB/schema compatibility between versions Needs real-time metrics and automated analysis to judge canary health Key Differences Blue-green performs an instant router cutover; canary shifts traffic incrementally over stages. Blue-green requires duplicate infrastructure; canary needs only a small extra pool of instances. Canary limits failures to a traffic percentage, while blue-green exposes 100% of users the moment it cuts over. Canary depends on live metrics to progress safely; blue-green relies on pre-cutover testing in an isolated environment. When to Use Each Blue-Green Deployment ...