Containers and Kubernetes

A is a standardized software execution unit that isolates an application process and its runtime dependencies from the rest of the host operating system. Unlike virtual machines, which virtualize physical hardware and run independent guest OS kernels, containers share the host Linux kernel while using kernel namespaces (for PID, network, mount, and IPC isolation) and cgroups (for CPU and memory resource boundaries). This lightweight model allows containers to start in sub-second timeframes, consume minimal baseline overhead, and behave identically across local development workstations, staging environments, and production clusters.

While individual containers solve packaging and local execution consistency, running dozens or hundreds of distributed containerized services across a pool of servers requires automated orchestration. has become the industry-standard control plane for this task. Given a cluster of underlying compute nodes and declarative specifications of your desired workloads, Kubernetes continuously reconciles the actual state of the cluster with that target state: scheduling containers onto appropriate nodes, monitoring health, restarting crashed processes, and replacing instances when hardware fails. Major cloud providers offer managed Kubernetes distributions, taking over control plane reliability, etcd quorum storage, and version upgrades while allowing you to focus on application deployment.

The image and the registry

A container launches from a —an immutable, layered filesystem archive containing application binaries, runtime interpreters, system libraries, and default configurations. Build tools compile these layers sequentially, allowing cached layers to be reused across builds to accelerate CI/CD pipelines.

Once built, images are pushed to a centralized . The registry stores versioned images and serves as the trusted distribution hub from which container hosts pull assets. Production deployments should always reference immutable tags (such as semantic versions or Git commit SHAs) or direct SHA-256 cryptographic digests. Reusing mutable tags like latest makes deployments non-reproducible and prevents reliable rollbacks when an incident occurs.

What Kubernetes gives you

Kubernetes coordinates containerized workloads using a small set of foundational abstractions:

• A represents the smallest deployable compute unit in Kubernetes. It encapsulates one or more containers that share a network namespace (including IP address and localhost loopback) and storage volumes. Pods are intentionally ephemeral; when a pod crashes or its host node suffers hardware degradation, the pod is terminated rather than repaired in place, and a replacement pod is scheduled elsewhere with a new internal IP address.
• A provides declarative management over a set of identical pods. It defines the desired replica count, the container image version, and update strategies (such as rolling updates with configurable surge and unavailability thresholds). When you update an application version, the deployment controller progressively replaces old pods with new ones, ensuring continuous availability without taking the entire service offline.
• A establishes a stable network abstraction and internal DNS name in front of a dynamically changing set of pods. Rather than tracking individual pod IP addresses, calling services send traffic to the service IP or DNS record, which automatically balances traffic across all healthy pods currently matching the service's selector.
• A is a physical or virtual machine that provides CPU and memory capacity to the cluster. Each node runs a container runtime, a network proxy, and the kubelet agent that communicates with the centralized control plane. In standard managed clusters, you configure and pay for node pools backed by virtual machines; modern managed offerings also provide serverless node modes that charge per requested pod resource without requiring direct node management.

By decoupling application instances into self-healing deployments and fronting them with durable internal services, Kubernetes ensures that underlying node failures, kernel reboots, or individual pod crashes remain invisible to upstream callers.

Requests and limits

The Kubernetes scheduler determines where to place pods based on declarative resource specifications. For each container, you define two critical values:

1. Requests: The baseline CPU and memory allocations required for the container to run. The scheduler uses requests to find a node with sufficient unallocated capacity (bin packing).
2. Limits: The absolute upper ceiling of resources the container may consume.

Configuring these boundaries correctly is vital to cluster stability. If resource requests are omitted, the scheduler can pack too many pods onto a single node, leading to severe resource starvation during traffic spikes. When a container exceeds its memory limit, the Linux kernel terminates the process immediately (an Out Of Memory or OOMKilled event), triggering pod crash loops. Conversely, setting overly generous requests leads to low hardware utilization and inflated infrastructure bills.

State

Because containers are designed for immutability and ephemerality, any data written to a container's local root filesystem is permanently destroyed when the container stops or restarts. Stateful workloads requiring durable data storage must mount a (PV).

Persistent volumes connect to cloud provider block storage or network file systems through standardized Container Storage Interface (CSI) drivers. When Kubernetes reschedules a stateful pod to a different physical node, the storage driver detaches the volume from the old host and attaches it to the new node. While this mechanism supports stateful components, storage attachment and detachment cycles introduce latency during node failovers. Consequently, many teams run stateless application tiers inside Kubernetes while relying on specialized managed services for SQL databases and NoSQL stores.

Getting traffic in

While Kubernetes services route traffic within the cluster's internal network, exposing services to external internet traffic requires an controller. An ingress acts as a reverse proxy, translating high-level HTTP/HTTPS routing rules, path prefixes, and hostnames into internal service destinations.

In cloud environments, ingress controllers integrate directly with provider APIs to automatically provision and configure cloud load balancers, wire health checks, and bind managed TLS certificates.

Deploying a new version

Roll out updates by changing the container image digest or tag in the deployment configuration.

1. Build the application image in a continuous integration pipeline and push it to the registry with a unique, immutable tag.
2. Update the Kubernetes deployment manifest to reference the newly published image tag.
3. Monitor the rolling update as new pods initialize and pass readiness probes while old pods drain connections.
4. If the new version fails health checks or throws errors, trigger a rollback to the previous deployment revision.

When Kubernetes is the right answer

Kubernetes delivers immense value for engineering organizations managing complex microservice architectures across dozens of autonomous engineering teams. It provides a universal, vendor-neutral API for deployment, service discovery, horizontal autoscaling, secret injection, and observability.

However, operating Kubernetes introduces substantial operational overhead. Teams must manage cluster version upgrades, debug complex networking overlays, tune scheduling policies, and maintain continuous control plane observability. For small engineering teams running a handful of web applications or APIs, adopting a full Kubernetes cluster is often unnecessary over-engineering. Modern managed container runtimes run standard container images with automatic scaling, zero node maintenance, and far simpler operational models.

Terms introduced

• Container: a process packaged with its dependencies and given its own view of the filesystem.
• Container image: the layered, versioned filesystem a container starts from.
• Container registry: the store a cluster pulls images from, addressed by tag.
• Kubernetes: software that places containers on a pool of machines and keeps them running.
• Pod: one or more containers scheduled together on one node, sharing an address.
• Deployment: the desired count and image for a set of pods, with rolling updates and rollback.
• Kubernetes service: a stable address in front of a changing set of pods.
• Node: a machine in the cluster's pool.
• Persistent volume: block storage that follows a pod between nodes.
• Ingress: a rule mapping an external hostname and path to a service inside the cluster.

---

How providers do it

Managed Kubernetes services form the centerpiece of container infrastructure across all three major clouds. While standard Kubernetes APIs and manifest files remain fully portable, providers differ in how they manage underlying worker nodes, container storage drivers, pod identity federation, and ingress controllers.

Concept	AWS	Azure	Google Cloud
Managed Kubernetes	Amazon Elastic Kubernetes Service (EKS)	Azure Kubernetes Service (AKS)	Google Kubernetes Engine (GKE)
Worker node pools	EC2 managed node groups	AKS node pools (backed by VMSS)	GKE node pools (backed by Compute Engine)
Serverless pod execution	AWS Fargate	Virtual Nodes, AKS Automatic	GKE Autopilot
Container image registry	Amazon Elastic Container Registry (ECR)	Azure Container Registry (ACR)	Google Cloud Artifact Registry
Cluster traffic ingress	AWS Load Balancer Controller	Application Gateway for Containers	GKE Ingress, Kubernetes Gateway API
Persistent volume drivers	EBS CSI driver; EFS CSI for shared files	Azure Disk CSI; Azure Files CSI	Persistent Disk CSI; Filestore CSI
Pod identity federation	EKS Pod Identity, IAM Roles for Service Accounts (IRSA)	Microsoft Entra Workload ID	Workload Identity Federation for GKE
Alternative orchestrator	Amazon ECS (proprietary task and service model)	No cluster alternative; Container Apps for serverless	No cluster alternative; Cloud Run for serverless

Every product name and technical mapping above is confirmed against official documentation. Cluster control plane pricing, AKS Automatic availability, and specific registry lifecycle dates are marked unconfirmed in the provider tabs below.

Orchestrator portability is an important architectural consideration:

• While Google Cloud and Azure concentrate their container roadmap exclusively on Kubernetes and serverless container runtimes, AWS maintains Amazon ECS (Elastic Container Service) as a proprietary, non-Kubernetes orchestrator. ECS provides a simpler operational model and tight AWS-native integration using task definitions and services. However, because ECS manifests and control plane primitives are proprietary to AWS, adopting ECS creates platform coupling that does not directly translate to other cloud environments.

AWS

What this maps to: AWS sells two orchestrators. Amazon EKS (Elastic Kubernetes Service) is managed Kubernetes. Amazon ECS (Elastic Container Service) is AWS's own orchestrator, simpler than Kubernetes and with its own vocabulary. Either one can run on EC2 nodes you manage, or on Fargate, where AWS runs the nodes for you and bills per task or pod.

Concept	On AWS	Status
Managed Kubernetes	EKS. AWS runs the control plane; you pay an hourly fee for it plus the nodes	confirmed
Nodes	EC2 instances in a managed node group, or Fargate profiles for nodeless pods	confirmed
Container registry	Amazon ECR (Elastic Container Registry). Private by default, per region	confirmed
Ingress	The AWS Load Balancer Controller turns an Ingress into an Application Load Balancer	confirmed
Persistent volume	EBS through the EBS CSI driver (one pod, one zone). EFS through the EFS CSI driver for shared, multi-zone volumes	confirmed
Pod identity	EKS Pod Identity or IAM Roles for Service Accounts (IRSA) bind a Kubernetes service account to an IAM role	confirmed
Add-ons and upgrades	Kubernetes version upgrades are yours to start; AWS supports each version for a fixed window and charges extended support after it	unconfirmed; check the current version calendar

ECS vocabulary, for when you meet it

Kubernetes says	ECS says
Pod	Task
Deployment	Service
Pod spec	Task definition
Node pool	Capacity provider (EC2 or Fargate)

Where to look

The EKS console lists clusters and node groups, with the Kubernetes version each is on. For anything below that level you'll need kubectl against the cluster.

Last verified: never.

Azure

What this maps to: Azure Kubernetes Service (AKS).

Concept	On Azure	Status
Managed Kubernetes	AKS. The control plane is free on the standard tier or charged for an uptime SLA and larger scale	unconfirmed; check current tier pricing
Nodes	Virtual Machine Scale Sets in node pools, spread across zones if you ask. Virtual nodes run pods on Azure Container Instances without a VM	confirmed
Container registry	Azure Container Registry (ACR), with geo-replication on the premium tier	confirmed
Ingress	The application routing add-on (managed NGINX) or Application Gateway for Containers	confirmed
Persistent volume	Managed disks through the Azure Disk CSI driver; Azure Files for shared volumes	confirmed
Pod identity	Microsoft Entra Workload ID binds a Kubernetes service account to an Entra identity	confirmed
Upgrades	Auto-upgrade channels for the control plane and node images, within a planned maintenance window	confirmed
Automatic mode	AKS Automatic, a preconfigured cluster with node autoprovisioning, the nearest equivalent to GKE Autopilot	unconfirmed; check current availability
Simpler alternatives	Azure Container Apps for services without a cluster, covered on the serverless page. Azure Container Instances for a single container on demand	confirmed

Their vocabulary

Standard term	Their term
Node pool	Node pool, backed by a scale set
Managed container runtime	Container Apps
Workload identity	Entra Workload ID

Where to look

The AKS resource's Workloads and Services blades mirror kubectl. Container insights in Azure Monitor shows node and pod resource use.

Last verified: never.

Google Cloud

What this maps to: Google Kubernetes Engine (GKE). Kubernetes came out of Google, so GKE is usually the most current of the three managed offerings.

Concept	On Google Cloud	Status
Managed Kubernetes	GKE, in two modes. Standard gives you node pools to size. Autopilot hides the nodes and bills per pod's requested CPU and memory	confirmed
Nodes	Compute Engine VMs in node pools, zonal or regional. A regional cluster spreads the control plane and nodes across zones	confirmed
Container registry	Artifact Registry. Container Registry was retired in its favour	unconfirmed; check the retirement date
Ingress	GKE Ingress or the Gateway API controller, both creating a Cloud Load Balancing external load balancer	confirmed
Persistent volume	Persistent Disk or Hyperdisk through the built-in CSI driver; Filestore for shared volumes	confirmed
Pod identity	Workload Identity Federation for GKE binds a Kubernetes service account to a Google service account	confirmed
Upgrades	Release channels (rapid, regular, stable) upgrade the control plane and nodes automatically within maintenance windows	confirmed
Autopilot pricing	Per pod resource request, with a flat cluster fee; you never pay for empty nodes	confirmed

Their vocabulary

Standard term	Their term
Managed container runtime	Cloud Run, covered on the serverless page
Node pool	Node pool
Nodeless	Autopilot

Where to look

The GKE console shows workloads, services, and the cluster's release channel and version. kubectl shows the rest.

Last verified: never.

---

Check your understanding

0 of 4 answered

1. In Kubernetes, what keeps the right number of copies of an application running?

   The deployment.The pod.The service.The ingress.
2. A pod's address changes when Kubernetes moves it to another node. How do other services keep reaching it?

   They call a service, which is a stable address that finds whichever pods are alive.They look up the new address from the node.Kubernetes keeps the address the same by reserving it on every node.They retry until the pod comes back on the original node.
3. Why do most teams run their databases outside the Kubernetes cluster?

   Storage that follows a pod between nodes is slower and more fragile than storage fixed to one machine, and managed databases already solve failover and backups.Kubernetes cannot attach persistent storage to a pod.Databases need more memory than a node can offer.The cluster's network cannot reach a database.
4. A pod works for a while under load and then restarts, over and over. What is the first thing to check?

   Whether it exceeded its memory limit and was killed.Whether the image tag was overwritten.Whether the ingress rule matches the hostname.Whether the node pool is in the right zone.