Kubernetes
Kubernetes at a High Level
Kubernetes is best understood as a control system: you describe the desired state, and Kubernetes keeps working to make reality match it.
The core idea
You tell Kubernetes what should run: container images, replicas, ports, secrets, CPU or memory limits, and rollout rules. Kubernetes then watches the cluster and continuously repairs drift.
That desired-state model is the heart of Kubernetes. Instead of manually logging into machines and starting processes, you submit configuration to the API server. Controllers then reconcile the cluster toward that configuration.
The loop is what makes Kubernetes feel different from a simple container runner. You are not only starting containers; you are giving the platform enough information to keep them running, replace them when they fail, and roll them forward in a controlled way.
Quick Kubernetes component glossary
Pod
A Pod is the smallest deployable unit in Kubernetes. It usually runs one application container and gets its own network identity inside the cluster.
Deployment
A Deployment manages a set of identical pods. It handles rolling updates, rollbacks, and replica count so releases can happen safely.
Service
A Service gives pods a stable network name and virtual IP. This matters because pods are temporary and can be recreated with different addresses.
Ingress
Ingress routes external HTTP or HTTPS traffic to services inside the cluster. It is commonly paired with an ingress controller and load balancer.
ConfigMap
A ConfigMap stores non-secret configuration such as flags, URLs, or environment values. It keeps configuration separate from container images.
Secret
A Secret stores sensitive configuration such as tokens or passwords. It still needs careful access control and encryption practices in real production clusters.
Node
A Node is a worker machine where pods actually run. It can be a VM or physical server managed as part of the Kubernetes cluster.
Control Plane
The Control Plane is the brain of the cluster. It stores desired state, schedules workloads, and runs controllers that reconcile cluster behavior.
The main building blocks
- Pods are the smallest runnable unit and usually contain one application container.
- Deployments manage replicas and rolling releases.
- Services provide stable networking for pods that can come and go.
- Ingress routes external HTTP traffic into the cluster.
- ConfigMaps and Secrets separate configuration from container images.
A useful way to think about it: Deployment decides how the app should roll out, Pod runs the app, Service gives it a stable internal address, and Ingress exposes it to users or other systems outside the cluster.
Why teams use it
The value is not just running containers. The value is repeatable operations: self-healing workloads, controlled rollouts, easier scaling, and one consistent platform pattern across environments.
When a pod crashes, Kubernetes can replace it. When a node becomes unhealthy, workloads can move elsewhere. When traffic increases, replicas can scale. These are not magic features; they work because Kubernetes constantly observes current state and compares it with declared intent.
What to design carefully
- Resource requests and limits, because bad sizing can create noisy-neighbor issues or unnecessary cost.
- Readiness and liveness probes, because they decide whether traffic should reach a pod and whether it should be restarted.
- Namespaces and RBAC, because platform boundaries matter as teams and services grow.
- Observability, because logs, metrics, traces, and events are what make cluster behavior understandable.
The platform mindset
Kubernetes works best when teams treat it as a platform, not a dumping ground for YAML. Good defaults, reusable templates, deployment standards, and clear ownership make it easier for application teams to move quickly without learning every cluster detail on day one.
A practical platform usually includes golden paths: base Helm charts, common alerts, ingress standards, resource defaults, secret handling, and deployment templates. These reduce decision fatigue and make production behavior more predictable across services.
The takeaway
Do not start Kubernetes by memorising every object. Start with the lifecycle of an app: build, configure, deploy, expose, observe, and recover. The objects make more sense when mapped to that flow.