Containers and Kubernetes

Four pieces make up the container world, and the CNCF's landscape guide files them in separate layers. An image is the packaged application at rest, a set of files describing what should run. A registry stores images and hands them out on request; every major provider runs one, and projects such as Harbor let you host your own. A runtime, for instance containerd or CRI-O, starts a container from an image, walls it off from its neighbours and caps the CPU and memory it may use. An orchestrator decides which machine in a cluster runs which containers, and how many.

Containers solved a very old complaint, that software behaves differently on each machine it meets. They did not solve running many services at once, which is where Kubernetes enters. Its core idea is reconciliation: you declare a desired state, say three copies of a web service with a given image, and a set of controllers keeps comparing that declaration with reality, starting or removing containers until the two agree. A crashed container is replaced not because someone wrote a restart script, but because the cluster noticed the count was wrong.

The layers a cluster adds

• Scheduling: choosing a node for each workload based on requested resources and placement rules.
• Service discovery and networking: giving a changing set of containers a stable name and address.
• Storage: attaching volumes to workloads that need their data to outlive a restart.
• Configuration and secrets: supplying settings without baking them into the image.
• Access control: deciding which people and programs may change what in the cluster.

Managed, hosted or self-built

Nobody is obliged to install Kubernetes from its source. Each large platform sells a managed control plane (EKS, AKS, GKE and OKE), certified distributions bundle it with installers and support, and simpler container services run images without exposing a cluster at all. The landscape guide is candid on this point: assembling a platform yourself takes a dedicated team to keep it patched and upgraded, and small teams are usually better served by something prepackaged. We would go further. If you cannot name the scheduling or scaling problem Kubernetes solves for you, a single container on a managed runtime is the better starting point, and the cluster can come later without rewriting the application.

The skill employers test is operational, and the Certified Kubernetes Administrator exam reflects that: it puts you at a shell prompt on live clusters with tasks to complete and the official documentation beside you, so recognising an answer from a list is no help. Security of images and clusters is a large field of its own; the landscape guide warns that default access settings are too permissive for production, and hardening them belongs with the cloud security topic of our cybersecurity field. Developers who only package and ship will find serverless a useful comparison, since it removes the cluster from view entirely.