A Practical Overview of Kubernetes
If you’ve built a web app that runs fine on one server but falls apart under real traffic, you already understand the problem Kubernetes solves. Managing containers at scale — across multiple machines, with zero-downtime deployments and automatic recovery — is genuinely hard. Kubernetes (K8s) is the tool the industry settled on to handle it.
This article gives you a clear Kubernetes overview: what it is, how its architecture works, and how its core pieces fit together to run modern web applications.
Key Takeaways
- Kubernetes is the de facto container orchestration platform, automating scheduling, scaling, self-healing, and traffic routing across a cluster of machines.
- A cluster has two layers: a Control Plane (API Server, Scheduler, Controller Manager, etcd) that makes decisions, and Worker Nodes (Kubelet, container runtime, kube-proxy) that run your workloads.
- Pods are the smallest deployable unit, but you typically manage them through Deployments and ReplicaSets, which handle replication and rolling updates.
- Services provide stable network endpoints for ephemeral Pods, while Ingress or the newer Gateway API handle external HTTP/HTTPS routing.
- ConfigMaps and Secrets keep configuration and sensitive data out of container images, making your deployments portable and secure.
What Is Kubernetes and Why Does It Exist?
Kubernetes is an open-source container orchestration platform originally developed by Google and donated to the Cloud Native Computing Foundation (CNCF) in 2015. It is widely adopted and considered the standard platform for container orchestration.
The short version: Docker packages your app into containers. Kubernetes runs and manages those containers across a cluster of machines, handling scheduling, scaling, self-healing, and traffic routing automatically.
Kubernetes Architecture Basics: How a Cluster Is Organized
A Kubernetes cluster has two distinct layers.
The Control Plane (The Brain)
The Control Plane makes decisions for the entire cluster. Its key components are:
- API Server — the single entry point for all commands. Every
kubectlcall goes here. - Scheduler — decides which worker node should run a given Pod, based on available resources.
- Controller Manager — continuously reconciles the actual cluster state with your desired state.
- etcd — a distributed key-value store that holds all cluster configuration and state. It’s the source of truth.
Worker Nodes (Where Your App Actually Runs)
Worker nodes run your containerized workloads. Each node includes:
- Kubelet — the node agent that ensures containers are running as specified.
- Container Runtime — pulls images and runs containers (typically containerd in modern clusters).
- Kube-proxy — manages network rules so Pods can communicate with each other and with Services.
Core Kubernetes Concepts for Web Apps
Pods
A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share a network and storage context. You rarely create Pods directly, since workload controllers manage them for you.
Deployments and ReplicaSets
A Deployment is how you describe what you want running: which container image, how many replicas, and how updates should roll out. It manages a ReplicaSet underneath, which ensures the right number of Pod copies stay running at all times. If a Pod crashes, the ReplicaSet replaces it automatically.
For a frontend app, a Deployment lets you say “run 3 replicas of my React app,” and Kubernetes handles the rest, including rolling updates with zero downtime.
Services
Pods are ephemeral, and their IP addresses change. A Service gives your Pods a stable network endpoint. The main types are:
| Type | Use Case |
|---|---|
ClusterIP | Internal communication between services (default type) |
NodePort | Exposes a service on a static port for testing |
LoadBalancer | Cloud-managed external access (most common for production) |
Ingress and Gateway API
For HTTP/HTTPS routing — sending /api traffic to one service and / to another — you use Ingress or the newer Gateway API. Gateway API is the current direction of the ecosystem, offering more flexibility and role-based configuration. If you’re starting fresh, it’s worth evaluating Gateway API over traditional Ingress controllers.
Discover how at OpenReplay.com.
ConfigMaps and Secrets
Keep configuration out of your container images. ConfigMaps store non-sensitive settings (API URLs, feature flags). Secrets store sensitive data (tokens, passwords). Both can be injected into Pods as environment variables or mounted as files.
How It All Fits Together
When you deploy a full-stack app on Kubernetes, the flow looks like this:
- You write a Deployment YAML describing your app container and replica count.
- The Scheduler places Pods on worker nodes with available capacity.
- A Service gives those Pods a stable internal address.
- An Ingress or Gateway routes external HTTP traffic to that Service.
- If a Pod dies, the ReplicaSet replaces it. If traffic spikes, you scale the Deployment.
Conclusion
Kubernetes architecture basics come down to this: the Control Plane decides, worker nodes execute, and abstractions like Pods, Deployments, and Services give you a consistent way to describe and manage your application. For web apps specifically, understanding Deployments, Services, and routing gets you most of the way there. The rest — storage, namespaces, resource limits — layers on top once you have the fundamentals down.
FAQs
Probably not. Kubernetes adds real operational overhead, including cluster maintenance, YAML configuration, and a steeper learning curve. For small projects or early-stage apps, a managed platform like Vercel, Render, or a single VPS with Docker Compose is usually faster and cheaper. Reach for Kubernetes when you need multi-service orchestration, predictable scaling, or strict uptime guarantees across environments.
Docker is a toolchain for building, packaging, and running containers. It builds and runs individual containers on a single host. Kubernetes is an orchestrator that manages many containers across many machines, handling scheduling, scaling, networking, and recovery. They're complementary tools. Docker creates the containers, and Kubernetes runs them at scale across a cluster.
If you're starting a new project, Gateway API is the better long-term choice. It offers a more expressive model, clearer separation between infrastructure and application teams, and is where the ecosystem is heading. Ingress remains widely supported and is fine for existing setups, but new clusters should evaluate Gateway API first, provided your chosen controller supports it.
Use Secrets rather than ConfigMaps for sensitive values. Keep in mind that base64 encoding is not encryption, so enable encryption at rest in etcd and restrict access with RBAC. For production-grade secret management, integrate an external tool like HashiCorp Vault, AWS Secrets Manager, or the External Secrets Operator to inject credentials securely into your Pods.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
