Kubernetes: Pods, Services, Deployments & Scaling

Kubernetes

Why Engineers Care About This

Kubernetes orchestrates containers at scale. It handles deployment, scaling, load balancing, and self-healing automatically. But Kubernetes is complex—pods, services, deployments, configmaps, secrets, and more. Understanding Kubernetes helps you build scalable, reliable systems. Without Kubernetes, you manage containers manually (deployment, scaling, health checks). With Kubernetes, these are automated.

When you need to scale applications, or handle rolling updates, or manage container health automatically, you're hitting problems that Kubernetes solves. These problems compound. Without orchestration, scaling requires manual intervention, updates cause downtime, and failures require manual recovery. Kubernetes automates these operations, enabling scalable, reliable systems.

In interviews, when someone asks "How would you deploy this at scale?", they're really asking: "Do you understand Kubernetes? Do you know how to design deployments, services, and scaling? Do you understand Kubernetes architecture?" Most engineers don't. They use Kubernetes without understanding components, or avoid Kubernetes because it's "too complex."

Core Intuitions You Must Build

• Pods are the smallest deployable unit, not containers. Pods contain one or more containers that share network and storage. Pods are ephemeral—they can be created, destroyed, and recreated. Don't think of containers as the unit—think of pods. Also, pods are scheduled on nodes (servers) by the scheduler. Understanding pods is fundamental to Kubernetes.

• Services provide stable networking for pods. Pods are ephemeral—they get new IPs when recreated. Services provide stable IPs and DNS names for pods, enabling other pods to find them. Services load balance traffic across pod replicas. Use services to expose pods to other pods or external traffic. Don't connect to pod IPs directly—they change when pods are recreated.

• Deployments manage pod replicas and rolling updates. Deployments create and manage pod replicas, handle rolling updates (update pods gradually), and enable rollbacks (revert to previous version). Use deployments for stateless applications. Don't manage pods directly—use deployments. Also, deployments ensure desired replica count (self-healing—recreate pods if they fail).

• Resource requests and limits prevent resource exhaustion. Pods can request resources (CPU, memory) and set limits. Requests are used for scheduling (scheduler places pods on nodes with available resources). Limits prevent pods from consuming all resources (pods exceeding limits are throttled or killed). Set requests and limits for all pods—without them, pods can consume all node resources.

• ConfigMaps and Secrets externalize configuration. Applications need configuration (API keys, database URLs, feature flags). Don't hardcode configuration in images—use ConfigMaps (non-sensitive config) and Secrets (sensitive config). Mount ConfigMaps and Secrets as files or environment variables. This enables configuration changes without rebuilding images.

• Kubernetes networking enables pod-to-pod communication. Kubernetes provides networking for pods—pods can communicate with each other using services (DNS names, load balancing). Also, ingress controllers expose services externally (HTTP/HTTPS routing). Understanding Kubernetes networking (services, ingress, DNS) helps you design applications that communicate correctly.

Subtopics (Taught Through Real Scenarios)

Pods and Containers

What people usually get wrong:

Engineers often think "pods are just containers." But pods are the smallest deployable unit—they contain one or more containers that share network and storage. Pods are ephemeral (can be recreated), scheduled on nodes, and managed by controllers (Deployments, StatefulSets). Understanding pods is fundamental—don't think of containers as the unit, think of pods.

How this breaks systems in the real world:

A team managed containers directly, thinking "containers are the unit." When containers failed, they weren't automatically recreated. Scaling required manual container creation. The fix? Use Kubernetes pods and deployments—pods are managed by deployments, which ensure desired replica count and handle failures automatically. Now scaling and recovery are automated. But the real lesson is: pods are the unit in Kubernetes, not containers. Use deployments to manage pods.

What interviewers are really listening for:

They want to hear you talk about pods, containers, and their relationship. Junior engineers say "pods are just containers." Senior engineers say "pods are the smallest deployable unit, containing one or more containers that share network and storage—pods are ephemeral and managed by controllers like Deployments." They're testing whether you understand that Kubernetes operates on pods, not containers.

Services and Networking

What people usually get wrong:

Engineers often connect to pod IPs directly. But pods are ephemeral—they get new IPs when recreated. Services provide stable IPs and DNS names for pods, enabling other pods to find them. Services also load balance traffic across pod replicas. Use services to expose pods—don't connect to pod IPs directly.

How this breaks systems in the real world:

A service connected to pod IPs directly. When pods were recreated (deployment update, node failure), IPs changed, breaking connections. The service had to be updated with new IPs manually. The fix? Use Kubernetes services—services provide stable IPs and DNS names, load balance across replicas, and handle pod IP changes automatically. Now connections are stable. But the real lesson is: services provide stable networking for pods. Don't connect to pod IPs directly.

What interviewers are really listening for:

They want to hear you talk about services, pod networking, and service discovery. Junior engineers say "just connect to pod IPs." Senior engineers say "use services to expose pods—services provide stable IPs and DNS names, load balance across replicas, and handle pod IP changes automatically." They're testing whether you understand that Kubernetes networking requires services, not direct pod connections.

Deployments and Rolling Updates

What people usually get wrong:

Engineers often update pods directly or recreate them manually. But deployments manage pod replicas, handle rolling updates (update pods gradually), and enable rollbacks. Use deployments for stateless applications—don't manage pods directly. Also, deployments ensure desired replica count (self-healing).

How this breaks systems in the real world:

A team updated pods manually by deleting and recreating them. Updates caused downtime (all pods deleted at once) and required manual intervention. The fix? Use Kubernetes deployments—deployments handle rolling updates (update pods gradually, one at a time), ensure zero downtime, and enable rollbacks. Now updates are automated and reliable. But the real lesson is: deployments manage pod lifecycle. Use deployments for stateless applications.

What interviewers are really listening for:

They want to hear you talk about deployments, rolling updates, and self-healing. Junior engineers say "just update pods manually." Senior engineers say "use deployments to manage pods—deployments handle rolling updates (gradual updates, zero downtime), ensure desired replica count (self-healing), and enable rollbacks." They're testing whether you understand that deployments automate pod management.

---

• Pods are the smallest deployable unit—contain one or more containers, share network and storage
• Services provide stable networking for pods—stable IPs, DNS names, load balancing
• Deployments manage pod replicas and rolling updates—use for stateless applications
• Resource requests and limits prevent resource exhaustion—set for all pods
• ConfigMaps and Secrets externalize configuration—don't hardcode config in images
• Kubernetes networking enables pod-to-pod communication—services, ingress, DNS
• Good Kubernetes design enables scalable, reliable, self-healing systems

---

• Docker & Containerization - Container fundamentals
• CI/CD Pipelines - Deploying to Kubernetes
• Infrastructure as Code - Managing Kubernetes infrastructure