Kubernetes Fundamentals: Pods, Services & Deployments (2026)
You've got a Docker container running on your laptop. Now you need to run fifty of them across ten servers, restart crashed ones automatically, and roll out updates without downtime. That's the problem Kubernetes solves. Google open-sourced it in 2014 after running billions of containers internally, and it has since become the standard for orchestrating containerized workloads at scale.
This guide walks through the core building blocks from scratch: what a Pod actually is, how Services expose your apps, how Deployments manage rolling updates, and how to talk to your cluster with kubectl. By the end you'll have working YAML for each concept and a clear mental model of how the pieces connect.
-
✓Docker basics You know what a container image is and can run
docker run. See cloud compute fundamentals if needed. -
✓Terminal comfort You can navigate directories and run commands without a GUI.
-
✓YAML syntax You understand indentation-based key-value files. Spaces matter; tabs will break things.
-
✓A local cluster Minikube, kind, or k3d installed. Cloud option: any managed cluster on AWS, Azure, or Google Cloud.
Your Learning Path
What Is Kubernetes and Why Does It Exist?
Running a single Docker container is straightforward. Running hundreds of containers across a fleet of servers is a logistics problem. Which server has capacity? What happens when a container crashes at 2 a.m.? How do you push a new version without taking the service down? These questions existed inside Google at massive scale long before most teams faced them.
Govern the data behind your AI. The AI Data Governance & Quality Assessment: a checklist to keep your data trustworthy.
Your purchase helps keep our hubs free to read.
Google's internal system, called Borg, handled this for years. In 2014, Google open-sourced a redesigned version called Kubernetes, which means "helmsman" or "pilot" in Greek. The abbreviation K8s replaces the 8 letters between K and s. It joined the Cloud Native Computing Foundation (CNCF) and has since graduated as a top-level project within the Linux Foundation ecosystem.
Kubernetes is not a replacement for Docker. Docker builds and runs containers. Kubernetes decides where containers run, keeps them running, and routes traffic to them. The two are complementary, not competing.
The Control Plane and Worker Nodes
Every Kubernetes cluster has two kinds of machines. The control plane runs the management software that makes decisions about your cluster. Worker nodes are where your actual application containers run.
The four control plane components, per the official Kubernetes documentation, are:
- API Server - The front door to the cluster. Every kubectl command, every CI/CD pipeline, every internal component talks through this.
- etcd - A distributed key-value store that holds all cluster state. If etcd is lost, the cluster's memory is gone.
- Scheduler - Assigns new Pods to nodes based on resource availability and constraints.
- Controller Manager - Runs control loops that compare desired state to actual state and reconcile the difference.
Each worker node runs three components: kubelet (the agent that executes Pod specs), kube-proxy (network proxy for routing), and a container runtime (such as containerd).
If you're coming from a background in cloud compute basics, think of the control plane as the cluster's brain and the nodes as the muscle.
Core Building Blocks: Pods, ReplicaSets, and Deployments
Pods: The Smallest Unit
A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share the same network namespace and storage volumes. Most Pods contain a single container, but multi-container Pods are used for tightly coupled processes such as sidecar logging agents.
You don't create containers directly in Kubernetes. You describe a Pod, and Kubernetes places that Pod on an appropriate node. The Pod gets an IP address within the cluster, but that address is temporary. If the Pod restarts, the IP changes. This is why you rarely talk to Pods directly.
ReplicaSets: Maintaining Copies
A ReplicaSet ensures a specified number of Pod copies are running at all times. If a Pod crashes, the ReplicaSet controller notices and schedules a replacement. You rarely write ReplicaSet manifests directly; you let Deployments manage them.
Deployments: Declarative Updates
A Deployment is the recommended way to run stateless applications. It manages a ReplicaSet and adds the ability to do rolling updates: gradually replacing old Pods with new ones without downtime. Here's a production-pattern Deployment manifest:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.25-alpine
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
The resources block deserves attention. requests tell the Scheduler how much resource this container needs (minimum guaranteed). limits cap the maximum. CPU is measured in millicores: 250m is one-quarter of a CPU core. Memory uses standard suffixes: 64Mi is 64 mebibytes. Per the Kubernetes resource management documentation, omitting limits means a container can consume unlimited node resources.
Apply this manifest with: kubectl apply -f deployment.yaml
maxUnavailable: 0 for zero-downtime deploys.Networking in Kubernetes: Services and Ingress
Pods are ephemeral. Their IP addresses change when they restart. A Service solves this by giving you a stable endpoint that load-balances traffic across all healthy Pods matching a label selector. The Service IP never changes even as Pods come and go behind it.
Service Types
- ClusterIP (default): Internal-only. Reachable from within the cluster but not from the internet. Use this for database connections, internal APIs, and microservices that should never be exposed externally.
- NodePort: Exposes the Service on each node's IP at a static port (30000-32767). Workable for development; not recommended for production because it exposes a raw port on every node.
- LoadBalancer: Provisions an external load balancer from your cloud provider. Works on EKS, AKS, and GKE. Not available on bare-metal without a load balancer controller like MetalLB.
Here's a ClusterIP Service that routes traffic to the nginx Deployment from the previous section, per the Kubernetes Services documentation:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
The selector: app: nginx matches all Pods with the label app: nginx. Kubernetes automatically updates the list of Pod IPs behind this Service as Pods are added or removed.
Ingress: HTTP Routing
An Ingress resource adds HTTP-level routing rules: route traffic to different Services based on the URL path or hostname. This requires an Ingress controller (nginx-ingress and AWS ALB Ingress Controller are common choices). Ingress is how most teams expose web applications in production: one LoadBalancer Service for the Ingress controller, and Ingress rules handle routing from there.
For more on cloud networking fundamentals, see our guide to cloud compute infrastructure.
Working With kubectl: Your First Commands
kubectl is the command-line tool for talking to your cluster's API Server. Every command is a request to the API. Here are the commands you'll use in every session, per the kubectl reference documentation:
# Apply a manifest (create or update) kubectl apply -f deployment.yaml # List resources kubectl get pods kubectl get pods -n kube-system # In a specific namespace kubectl get deployments -o wide # Wide output with more columns # Inspect a specific resource kubectl describe pod nginx-deployment-abc123 # Check rollout status kubectl rollout status deployment/nginx-deployment # View live differences before applying kubectl diff -f deployment.yaml # View logs kubectl logs nginx-deployment-abc123 kubectl logs nginx-deployment-abc123 -f # Follow (streaming) # Execute a command inside a running container kubectl exec -it nginx-deployment-abc123 -- /bin/sh # Delete a resource kubectl delete -f deployment.yaml
The kubectl diff command is underused by beginners. Before applying any change to production, running kubectl diff -f yourfile.yaml shows exactly what will change, the same way git diff shows code changes. This is the key concept behind infrastructure as code approaches generally: declare what you want, verify the diff, then apply.
Context matters. kubectl commands run against whatever cluster is set as your current context. Run kubectl config current-context before any destructive operation to confirm you're targeting the right cluster. Accidentally running a delete command against production is a career-defining event for the wrong reasons.
Organizing Resources: Namespaces, Labels, and Resource Limits
Namespaces: Logical Clusters Within a Cluster
A namespace provides a scope for resource names. You can have a Deployment called api-server in both the production and staging namespaces without conflict. Namespaces also let you apply resource quotas and RBAC policies per environment.
# Create a namespace kubectl create namespace staging # Deploy into a specific namespace kubectl apply -f deployment.yaml -n staging # List all Pods across all namespaces kubectl get pods --all-namespaces
Labels: The Kubernetes Selector System
Labels are key-value pairs attached to any Kubernetes object. They have no meaning to Kubernetes itself; you define what they mean. Services use label selectors to find their Pods. Deployments use them to manage their ReplicaSets. Per the Kubernetes namespaces documentation, well-designed labels are the foundation of operational clarity in large clusters.
Resource Limits: Protecting Your Nodes
Without resource limits, a single misbehaving container can consume all available memory on a node and starve every other container. The resource block from the earlier Deployment example sets requests (Scheduler guarantees) and limits (hard caps). Here's a standalone container snippet:
containers:
- name: api
image: myapp:v2.1
resources:
requests:
memory: "128Mi" # 128 mebibytes guaranteed
cpu: "100m" # 0.1 CPU core guaranteed
limits:
memory: "256Mi" # Container is killed if it exceeds this
cpu: "500m" # Container is throttled at this ceiling
CPU limits cause throttling: the container keeps running but gets less CPU time. Memory limits cause OOM kills: the container is terminated and restarted. Set memory limits conservatively; set CPU limits more generously to avoid unnecessary throttling on bursty workloads.
Health Checks: Readiness and Liveness Probes
Kubernetes needs to know two different things about a running Pod: is it alive, and is it ready to receive traffic? These are different questions, and mixing them up causes subtle production failures.
- livenessProbe: "Is this container still functioning?" A failure causes the container to be restarted. Use this for detecting deadlocks or stuck processes that the container cannot recover from on its own.
- readinessProbe: "Is this container ready to serve requests?" A failure removes the Pod from all Service endpoints temporarily. Use this for startup delays, dependency checks, or temporary overload conditions.
- startupProbe: "Is this slow-starting container still initializing?" Disables liveness and readiness probes until the startup probe succeeds, preventing premature kills during long initialization sequences.
Per the Kubernetes probe documentation, here's a Deployment with both probes configured:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 2
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web
image: myapp:v2.1
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /healthz/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3
livenessProbe:
httpGet:
path: /healthz/live
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
failureThreshold: 3
initialDelaySeconds gives the container time to start before Kubernetes begins checking. periodSeconds controls how often the check runs. failureThreshold: 3 means the probe must fail three consecutive times before action is taken. Your health endpoints should be lightweight: no database calls, no heavy computation. They should return a fast response confirming the process is alive and ready.
A common mistake: making the readinessProbe too lenient. If your endpoint returns 200 even when the app can't connect to its database, Kubernetes routes traffic to a broken Pod. Health endpoints should check critical dependencies, not just that the HTTP server started.
Kubernetes in the Cloud: EKS, AKS, and GKE
Running your own Kubernetes control plane means maintaining etcd, upgrading the API Server, handling control plane failures, and managing certificates. Managed Kubernetes services handle all of that for you. You get a cluster API endpoint; the cloud provider operates the control plane. You pay for worker nodes and, in most cases, a control plane management fee.
The three dominant managed offerings map to the three major clouds:
- Amazon EKS (Elastic Kubernetes Service) runs on AWS. The control plane runs separately from your nodes; pricing is approximately $0.10 per cluster per hour at the time of writing. Verify current pricing at aws.amazon.com/eks/pricing before budgeting.
- Azure AKS (Azure Kubernetes Service) runs on Microsoft Azure. The control plane is currently provided at no additional charge; you pay only for worker nodes and associated resources. Verify at azure.microsoft.com/pricing/details/kubernetes-service before planning.
- Google GKE (Google Kubernetes Engine) runs on Google Cloud, where the project originated. GKE Standard includes a cluster management fee approximately $0.10 per hour per cluster. GKE Autopilot charges per Pod resource usage. Verify at cloud.google.com/kubernetes-engine/pricing.
All three offerings support kubectl identically. The main differences are in node pool management, autoscaling approaches, and cloud-specific integrations (IAM, load balancers, storage classes). If you're already heavily invested in one cloud, the corresponding managed Kubernetes service is almost always the right choice for production.
If you want to certify your Kubernetes skills, the Linux Foundation offers the Certified Kubernetes Administrator (CKA) exam. Verify current exam fees and prerequisites at training.linuxfoundation.org. The cloud certifications roadmap covers CKA in context of other cloud credentials.
From an infrastructure-as-code perspective, Terraform can provision and manage EKS, AKS, and GKE clusters alongside the rest of your cloud infrastructure, keeping cluster creation reproducible and version-controlled.
Common Errors and How to Fix Them
Diagnosis: Run
kubectl describe pod and check the Events section at the bottom. "Insufficient cpu" or "Insufficient memory" means your nodes are full. "0/3 nodes are available" with a reason tells you exactly what constraint is unmet.Fix: Reduce resource requests, add more nodes, or check for incorrect node selectors/taints.
Diagnosis:
kubectl logs --previous shows logs from the previous (crashed) container instance. The application error is almost always in there.Fix: Fix the application error. Common causes: missing environment variables, failed database connections, missing configuration files, or the entrypoint command is wrong.
Diagnosis:
kubectl describe pod shows the exact pull error in Events. "not found" means the image tag is wrong. "unauthorized" means authentication is failing.Fix: Correct the image name/tag, or create an
imagePullSecret with your registry credentials and reference it in the Pod spec.
Diagnosis:
kubectl get endpoints . If the Endpoints resource shows no addresses, the selector is not matching. Compare kubectl describe service Selector field with kubectl get pods --show-labels.Fix: Ensure the Service selector exactly matches the Pod labels (case-sensitive). Also verify Pods are in Running state and passing their readinessProbe.
Diagnosis:
kubectl config current-context shows the active context. kubectl config get-contexts lists all available contexts.Fix:
kubectl config use-context . Consider a tool like kubectx for faster context switching if you work across many clusters daily.