Overview
Kubernetes (K8s) is an open-source container orchestrator. You declare the desired state (run 5 replicas of this image, expose them on port 80, give each 512 MB of memory) in YAML manifests, and Kubernetes continuously works to make reality match: scheduling pods onto nodes, restarting failures, rolling out new versions, scaling, and routing traffic.
The control plane (API server, etcd, scheduler, controller manager) stores and reconciles state; worker nodes run pods through the kubelet and container runtime. Core objects include Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, and Horizontal Pod Autoscalers. Managed offerings (EKS, GKE, AKS) run the control plane for you.
You file a flight plan (desired state). The tower (control plane) assigns runways and gates (nodes), reroutes planes when something breaks, and keeps everything moving according to plan, without pilots coordinating with each other directly.
When to use it
- Running many containerized services with shared infrastructure.
- Self-healing, rolling deployments, and autoscaling.
- Portable deployments across clouds and on-prem.
- Platform teams offering a standard runtime to developers.
Where it shows up in interviews
Recognize it when: dozens of services, many teams.
- Design a microservices e-commerce platform
- Design an internal developer platform
Recognize it when: services must recover and scale automatically.
- Design a highly available API
- Handle traffic spikes on a web app
Where it is used in real software
Kubernetes was open-sourced by Google in 2014, based on its internal Borg system.
Run large Kubernetes fleets for most of their services.
Helm, Argo CD, Prometheus, Istio, and hundreds of projects build on Kubernetes.
Key terms
- Pod
- Smallest deployable unit: one or more containers sharing network and storage.
- Deployment
- Manages ReplicaSets for stateless apps with rolling updates.
- Service
- Stable virtual IP and DNS name load balancing to pods.
- Ingress / Gateway
- HTTP routing from outside into Services.
- Controller / reconciliation loop
- Watches desired vs actual state and acts to converge.
How it works, step by step
- 1kubectl apply a Deployment
The API server stores the desired state in etcd.
- 2Controllers create pods
The Deployment controller creates a ReplicaSet, which creates pods.
- 3Scheduler places pods
On nodes with enough CPU and memory, respecting constraints.
- 4Kubelet runs containers
Pulls images, starts containers, runs probes.
- 5Services route traffic
To ready pods; controllers keep replacing failures.
STEP 1You apply a Deployment with replicas: 3. The API server validates and stores it in etcd.
Core Kubernetes objects
What each object is for
| Object | Purpose | Example |
|---|---|---|
| Deployment | Stateless replicas + rolling updates | api with 5 replicas |
| StatefulSet | Stable identity and storage | Kafka, databases |
| Service | Stable endpoint to pods | api.default.svc.cluster.local |
| Ingress / Gateway | External HTTP routing | api.example.com to api Service |
| ConfigMap / Secret | Configuration / sensitive values | Feature flags / DB password |
| HPA | Autoscale replicas | Scale 3-30 on CPU |
NOWObject: Deployment | Purpose: Stateless replicas + rolling updates | Example: api with 5 replicas
Most applications need a Deployment, a Service, an Ingress, config, and an autoscaler.
Implementation
apiVersion: apps/v1kind: Deploymentmetadata: { name: api }spec: replicas: 3 selector: { matchLabels: { app: api } } strategy: { rollingUpdate: { maxUnavailable: 0, maxSurge: 1 } } template: metadata: { labels: { app: api } } spec: containers: - name: api image: containers.artifactory.tools.bestbuy.com/team/api:abc1234 ports: [{ containerPort: 3000 }] resources: requests: { cpu: 250m, memory: 256Mi } limits: { memory: 512Mi } readinessProbe: { httpGet: { path: /ready, port: 3000 }, periodSeconds: 5 } livenessProbe: { httpGet: { path: /health, port: 3000 }, initialDelaySeconds: 10 } envFrom: [{ secretRef: { name: api-secrets } }]---apiVersion: v1kind: Servicemetadata: { name: api }spec: selector: { app: api } ports: [{ port: 80, targetPort: 3000 }]Complexity and performance
Upstream tested limits.
After node failure detection.
Trade-offs
Kubernetes solves scheduling, healing, and scaling but has a steep learning curve and operational overhead.
EKS/GKE reduce control plane work; ECS, Cloud Run, or App Runner may be simpler for small teams.
Variants and related techniques
Package and customize manifests.
Git is the source of truth; controllers sync clusters.
Custom controllers that manage complex apps like databases.
Common mistakes
- No resource requests and limits.
Fix: Scheduling becomes unpredictable and noisy neighbors cause OOM kills.
- Liveness probes that check dependencies.
Fix: A DB outage restarts every pod; keep liveness simple, use readiness for dependencies.
- Secrets in plain ConfigMaps.
Fix: Use Secrets with encryption, or external secret managers.
Interview questions
What happens when you run kubectl apply for a Deployment?
The API server validates and stores it in etcd; the Deployment controller creates a ReplicaSet; the ReplicaSet creates pods; the scheduler assigns them to nodes; kubelets start containers; and Services route traffic to ready pods.
Readiness vs liveness probes?
Readiness decides whether a pod should receive traffic; failing removes it from Service endpoints. Liveness decides whether the container should be restarted; failing kills and restarts it.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Deploy an API with a Service and Ingress | Easy | Core objects. |
| Design a multi-team Kubernetes platform | Hard | Namespaces, RBAC, quotas, GitOps. |