Kubernetes has become almost a synonym for modern infrastructure, to the point that many adopt it before understanding whether they need it. It is a powerful tool, created to manage many containers across many machines, but it brings a new mental model and significant operational complexity. Knowing its basic concepts helps both to use it well and to decide when to leave it aside.
The principle: desired state and reconciliation
The central idea of Kubernetes is declarative. You don't tell it "start three containers", but "I want three copies of this application to exist at all times". Kubernetes continuously compares the desired state with the actual state and acts to make them match: if a container crashes it restarts it, if a node goes down it moves the containers elsewhere, if some are missing it creates them.
This reconciliation loop is what distinguishes an orchestrator from a startup script. Within certain limits the cluster heals itself, as long as you describe correctly what you want.
The architecture in brief
A cluster is made of two parts:
- the control plane, which contains the API server (the entry point for every command), the etcd database where state is stored, the scheduler that decides which node runs each workload and the controllers that carry out reconciliation;
- the worker nodes, physical or virtual machines where the containers actually run, each with an agent called the kubelet.
In the managed services offered by cloud providers the control plane is looked after by the provider, and cluster users take care only of the nodes and applications.
The fundamental objects
Everything in Kubernetes is an object described in a YAML file and sent to the API server. The ones to learn first are few.
| Object | What it is for |
|---|---|
| Pod | The smallest runnable unit: one or more containers sharing network and volumes |
| Deployment | Keeps a given number of pod replicas and manages their updates |
| Service | Provides a stable address and balances traffic across replicas |
| Ingress | Routes HTTP requests from outside to Services, by domain or path |
| ConfigMap and Secret | Separate configuration and credentials from the image |
| Namespace | Divides the cluster into logical spaces, by team or environment |
Pods and Deployments
You rarely create a pod by hand. Pods are ephemeral: they can be destroyed and recreated at any moment, with a different IP address. Instead you create a Deployment, which describes the pod template and the number of replicas. When you update the image, the Deployment replaces the replicas gradually, so the service stays available during the release.
Services and Ingress
Since pods change address, other applications cannot contact them directly. A Service offers a stable internal DNS name and distributes requests among healthy pods. An Ingress, together with a controller such as the Nginx-based one, exposes services to the outside and usually also handles TLS certificates.
Two details that make the difference
Health probes
Kubernetes can check the state of each container with probes:
- the liveness probe checks that the process is not stuck; if it fails, the container is restarted;
- the readiness probe checks that it is ready to receive traffic; if it fails, the pod is temporarily removed from the Service.
Without a readiness probe, during an update traffic can reach an application that is still loading, producing errors that users see.
Resource requests and limits
Every container should declare how much CPU and memory it requests and what its limit is. Requests let the scheduler place pods on nodes with enough room; limits prevent a container from consuming all resources. A container that exceeds its memory limit is killed, so the values should be estimated by observing real consumption.
When Kubernetes pays off
Kubernetes makes sense when several conditions hold together:
- many different services to manage, often owned by different teams;
- a need for high availability across several machines;
- variable workloads requiring replicas to be added and removed automatically;
- an organization willing to invest in maintaining the cluster and in training.
When you can do without it
For a web application with a database, an internal business tool or a site with predictable traffic, Kubernetes is often overkill. Cluster version upgrades, networking, controllers, permissions, certificates and monitoring require dedicated time and skills. In my work, before proposing it, I always ask how many people will manage it and what happens at three in the morning when something breaks.
The simpler alternatives are concrete: Docker Compose on a single server, managed services that run containers without exposing the cluster, platforms that accept the code or the image directly. Many companies run perfectly well on these solutions, and move to Kubernetes only when their limits become a real problem rather than a hypothetical one.
In short
- Kubernetes works declaratively: you describe the desired state and the cluster maintains it.
- The concepts to learn first are Pod, Deployment, Service, Ingress, ConfigMap, Secret and namespace.
- Liveness and readiness probes, together with resource requests and limits, are essential for a stable cluster.
- It pays off with many services, different teams and high-availability needs.
- For small or predictable projects there are simpler alternatives that are cheaper to run.
