Kubernetes 101

A short primer before anything edge-specific.

What it is

Kubernetes is an open-source container orchestrator. It joins several machines into one cluster and takes care of deploying, scaling and managing containerised applications through a standard API.

Why use it, and when not to use it

• Resilience. With several nodes, workloads move elsewhere when a machine fails.
• Scaling. An application runs as one or many containers behind the same API.
• Service discovery. Workloads find each other by name, not by hand-managed IP addresses.
• Consistency. The same manifests deploy on-premise, in the cloud, or across both.

And when not to:

• One app on one box. Docker Compose or systemd is simpler and enough.
• Nobody to run it. Kubernetes is a platform to operate, not a tool to install. The learning curve is real, and so is the day-two work.
• Hard real time. It schedules containers. It does not replace a PLC or a real-time OS.

Brief history

Kubernetes grew out of a decade of running containers inside Google, went open source in 2014, and was handed to a vendor-neutral foundation a year later. That last move is what turned it into an industry standard rather than a Google product.

One of the 3 most mature projects in the CNCF.

An extensible product...

The API is the contract. Every object has a path on it, operators add their own kinds, and runtime, network and storage are swappable behind standard interfaces. Like Linux, it comes in many distributions.

...based on a reconciliation principle

You tell Kubernetes what you want, not how to get there: "two copies of this container, reachable on this port". The cluster stores that desired state and keeps comparing it with what is actually running. When a pod crashes or a node disappears, the gap is noticed and closed without anyone being paged. The same loop applies your changes: edit the desired state, and the cluster converges to it.

Control plane and data plane

A cluster has two halves.

• The control plane holds the desired state. It is made of the API server, the scheduler, the controller managers, and a datastore (etcd, or SQLite in a default k3s install).
• The data plane is the worker nodes. They run the containers the control plane assigns to them.

Operators and tooling talk to the API server. End users never see it; they reach the applications running on the nodes.

Hands-on

Exercises in k8s-101-exercices: a folder each, with README, manifests and a check script. Work in your own namespace on the shared k3s cluster.

1. Hello. Two replicas. Delete a pod by hand, watch it come back.
2. Service. A NodePort in front, reached from outside and by name inside.
3. ConfigMap. Config out of the image. Which changes need a rollout?
4. Init containers. Wait for a dependency, seed a volume, then start.
5. Break it. Wrong image tag, failing probe. Describe, logs, events, fix.

Key tools

CLI:

• kubectl, the go-to for quick debug and inspection.
• k9s, lens, tool to visualise cluster state

Application packaging:

• kustomize native templates
• helm app templating, client side
• kro app templating, server side

GitOps

• flux, unix-style & lighweight controllers
• argocd, dev friendly app & UI

What GitOps is exactly?

Instead of pointing kubectl at the cluster, you push manifests to a Git repository and an agent inside the cluster pulls them and applies them through the API server. The repository becomes the source of truth: every change is a reviewed commit, the whole cluster can be rebuilt from it, and rolling back is a revert.