Kubernetes (K8s): meaning and definition
Kubernetes (K8s) in plain language
Instead of starting every replacement container by hand, a team describes what it wants running. Kubernetes then schedules and manages it, within the capacity and settings available.
A Pod is the smallest unit Kubernetes runs, holding one or more closely linked containers. Running Pods is only part of an app: storage, networking, identity, monitoring and whether the app itself works correctly still need careful design.
How it works
Desired state versus observed state
A simplified reconciliation loop
- Declare
Request three replicas of a workload.
- Observe
The controller finds fewer than the desired number.
- Reconcile
Create replacements; scheduling needs suitable capacity.
The controller observes again. Replacement does not by itself restore lost application data.
Define the workload
Specify the image, resources, configuration and appropriate health checks.
Provide the platform services
Configure the networking, storage and permissions the workload needs.
Inspect health and changes
Check events, status and what users see during an update or a failure. A process that is running is not always a service that is ready.
Illustrative example · Fictional data
A fictional API loses one replica
- Input
- An API Deployment requests three replicas. One Pod terminates unexpectedly.
- Process
- The controllers attempt to restore the desired replicas. A suitable node must be available and the replacement must pass readiness checks before receiving traffic through the configured Service.
- Expected output
- The workload returns to the intended available capacity if dependencies and resources permit.
- How to check it
- Repeat with insufficient capacity or a bad image. The replacement may stay pending or fail; declaring three replicas is not a guarantee that three healthy replicas exist.
Where it helps
- Operating multiple containerised workloads with declared configuration.
- Coordinating rolling application updates.
- Managing replacement and placement across a cluster.
Docker, Kubernetes and managed Kubernetes
- Container tooling
- Builds and runs application packages.
- Kubernetes
- Orchestrates workloads across cluster resources.
- Managed service
- Moves specified cluster operations to a provider; workload configuration and responsibilities remain.
Common pitfalls
- Restarting an unhealthy application does not repair its underlying bug.
- Replicas sharing one failure boundary may still fail together.
- Cluster complexity can outweigh its value for a small application.
Put the idea to work
Try it yourself
For a three-replica API, list what happens if an instance fails, the image is invalid or all nodes lack capacity. Separate controller action from the user-visible result.
Common questions
Does Kubernetes guarantee zero downtime?
No. Whether an app stays up depends on how it is built, its capacity, health checks, the services it relies on and how updates roll out. Rolling updates, readiness checks and several copies of the app reduce disruption, but database changes, slow start-ups or failing services can still cause outages. Test updates under realistic load.
Does Kubernetes build container images?
Image builds normally happen in a separate build process. Kubernetes runs workloads using the resulting images. Teams typically build images in a CI pipeline, push them to a container registry and then reference the image tag in Kubernetes deployment manifests.
Should every container application use Kubernetes?
No. Compare its operational cost with simpler hosting options and the actual orchestration needs. A single server, Docker Compose or a managed container service may be enough for a small application. Kubernetes pays off when you run many services that need scaling and self-healing.
Your next step
Continue learning
Connected concepts
Sources and further reading
Examples on this page are teaching exercises using fictional information. They are not client case studies or measured outcomes.