Ecosystem, containers and orchestration
Ecosystem, containers and orchestration
Container in one paragraph
A container is a process on the host kernel, isolated by namespaces and limited by cgroups. It starts from an image: read-only layers plus one thin writable layer that disappears with the container. No guest OS, so start-up takes milliseconds.
graph TB
subgraph VMs
H1[Hardware] --> HV[Hypervisor]
HV --> G1[Guest OS + App]
HV --> G2[Guest OS + App]
end
subgraph Containers
H2[Hardware] --> OS[Host OS kernel]
OS --> CR[Container runtime]
CR --> C1[App]
CR --> C2[App]
end
Why orchestration
One host and docker run do not answer the questions production asks:
| Question | Kubernetes answer |
|---|---|
| Where should it run? | scheduler |
| What if the node dies? | controllers recreate it elsewhere |
| How do I run 10 copies? | ReplicaSet / Deployment |
| How do clients find it? | Service + DNS |
| How do I update without downtime? | rolling update |
| Where do config and secrets go? | ConfigMap, Secret |
The ecosystem
Kubernetes started at Google (2014, built on Borg), and has been a CNCF project since 2015. It is a platform for building platforms - most of what you use day to day comes from the ecosystem around it.
graph TB
K[Kubernetes API] --- R[Runtime: containerd, CRI-O]
K --- N[Network: Calico, Cilium]
K --- S[Storage: CSI drivers]
K --- P[Packaging: Helm, Kustomize]
K --- O[Observability: Prometheus, Grafana]
K --- G[Delivery: Argo CD, Flux]
K --- SEC[Security: Kyverno, Trivy]
Distributions: upstream kubeadm (this course), managed AKS / EKS / GKE,
OpenShift, Rancher RKE2, k3s. The API is the same everywhere - what differs is
who runs the control plane.
What your application must respect
| 12-factor rule | Why Kubernetes cares |
|---|---|
| Config from the environment | same image in dev and prod |
| Stateless processes | Pods are replaced, not repaired |
| Fast start, clean SIGTERM | rolling updates and rescheduling |
| Logs to stdout | kubectl logs reads nothing else |