Kubernetes

Overview The Sidecar Pattern is the general technique of running a helper container alongside your app in the same pod to add any cross-cutting capability — logging, metrics, config sync, or a mesh proxy. The Ambassador Pattern is a specific flavor of that sidecar dedicated to one job: sitting between the app and the network, so the app talks to localhost while the ambassador handles the real, often messy, connection to an external service. ...

Overview Docker Swarm and Kubernetes are both container orchestration platforms that manage deployment, scaling, and networking of containerized applications, but they differ sharply in operational complexity and feature depth. Swarm prioritizes simplicity, integrating directly into the Docker CLI for fast setup, while Kubernetes offers a far more extensible, battle-tested platform built for large-scale, production-grade workloads. Comparison Diagram Docker SwarmKubernetesSwarm ManagerRaft consensus storeWorker NodeTaskTaskTaskWorker NodeTaskTask2 node roles: manager + workerControl PlaneAPI ServeretcdSchedulerController MgrWorker NodekubeletPodWorker NodekubeletPodLayered control plane + kubelet-managed pods Comparison Table Aspect Docker Swarm Kubernetes Setup & installation Single command: docker swarm init/join Multi-step: kubeadm, managed service, or install tool Cluster architecture Manager nodes (Raft consensus) + worker nodes Control plane (API server, etcd, scheduler, controller manager) + worker nodes with kubelet Deployment unit Service made of identical Tasks, one container each Pod: one or more co-located, co-scheduled containers Networking Built-in overlay network, configured automatically Pluggable via CNI plugins (Calico, Cilium, Flannel) Service discovery & load balancing Built-in DNS plus routing mesh VIP kube-proxy with Service objects and Ingress controllers Scaling & scheduling Basic spread or binpack placement strategies Fine-grained scheduling with affinity rules, taints, and resource requests Self-healing & updates Restarts failed tasks, basic rolling updates Reconciliation loops, rolling updates, rollbacks, HPA/VPA autoscaling Ecosystem & extensibility Minimal, small plugin ecosystem Vast ecosystem: CRDs, Operators, Helm, service meshes Key Differences Docker Swarm favors simplicity, built directly into the Docker CLI, while Kubernetes requires setting up a separate control plane. Swarm deploys single-container Tasks, whereas Kubernetes groups containers into Pods that share network and storage. Kubernetes offers far more granular scheduling controls than Swarm’s basic spread strategy. Kubernetes’ ecosystem of CRDs, Operators, and Helm dwarfs Swarm’s, at the cost of a steeper learning curve. Swarm networking is automatic overlay by default, while Kubernetes relies on pluggable CNI plugins requiring explicit choice. When to Use Each Docker Swarm ...

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 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 Role and ClusterRole are both Kubernetes RBAC objects that define sets of permission rules (verbs on resources), but they differ in scope: a Role only applies within a single namespace, while a ClusterRole is defined once for the whole cluster and can be bound either cluster-wide or scoped down to one namespace. Understanding this distinction is essential for applying least-privilege access control in multi-tenant clusters. Comparison Diagram RoleClusterRoleNamespace: devRoleRoleBindingUserlimited to this namespaceCluster scopeClusterRoleRoleBindingClusterRoleBindingUserthis ns onlyUserall namespacesone definition, reused via either binding Comparison Table Aspect Role ClusterRole API object scope Namespaced object; exists only within one Namespace Cluster-scoped object; exists once for the entire cluster Resources it can grant access to Only namespaced resources (pods, configmaps, secrets, etc.) within its own namespace Namespaced resources cluster-wide plus cluster-scoped resources such as nodes, persistentvolumes, and namespaces Non-resource URLs (e.g. /healthz, /metrics) Cannot reference non-resource URLs Can include rules for non-resource URLs Binding object required RoleBinding only, created in the same namespace RoleBinding for a namespace-scoped grant, or ClusterRoleBinding for a cluster-wide grant Effective grant when bound Permissions always limited to the Role’s own namespace Spans every namespace when bound via ClusterRoleBinding, or just one namespace when bound via RoleBinding Reuse across namespaces Must be duplicated in each namespace that needs the same rules Defined once, reused across many namespaces or cluster-wide via separate bindings Aggregation support None; rules are static within the object Supports aggregationRule to auto-combine rules from other ClusterRoles by label selector Typical built-in examples None shipped by default; teams author their own per namespace cluster-admin, admin, edit, view, and system: component roles ship as default ClusterRoles Key Differences Role is namespace-scoped while ClusterRole is cluster-scoped by definition, regardless of how it’s later bound. Only ClusterRole can grant access to cluster-scoped resources like nodes or to non-resource URLs such as /metrics. A ClusterRole can still be restricted to one namespace by binding it with a RoleBinding instead of a ClusterRoleBinding. ClusterRole supports aggregation to compose permissions from labeled ClusterRoles; Role has no equivalent mechanism. Kubernetes ships default admin/edit/view permission sets as built-in ClusterRoles, never as Roles. When to Use Each Role ...