Skip to contentkubesim

Concepts

Illustrated walk-throughs of how Kubernetes is put together. Step through each one, then try it for real in the lesson it belongs to.

1/6
Two halves

A cluster has a control plane that makes decisions and worker Nodes that run your containers. The Cluster View shows the control plane as the shaded Node on the left, with the Kubernetes wheel.

Try it in “Your first Pod”
1/6
1. You send the manifest

kubectl reads your YAML and sends it to the API server. That's all kubectl does: it never starts containers itself.

Try it in “Declarative YAML”
1/6
Pods move; names don't

Pods are replaced all the time and get new IPs. Clients need one stable name to call. That's a Service.

Try it in “Services & networking”
1/5
The kubelet asks

The kubelet on the Pod's Node runs each probe on a timer (periodSeconds). A probe is an HTTP GET (2xx or 3xx passes), a TCP connection, a gRPC health check, or a command run inside the container (exit code 0 passes).

1/5
One entrance for many apps

A LoadBalancer Service per app means one public IP each. An Ingress puts a single HTTP entrance in front of many Services, and picks one by the request's hostname and path.

1/5
Open by default

Without policies, every Pod can reach every other Pod, in any namespace. A compromised debug Pod could talk straight to the database.

1/5
Ask, don't build

A Pod doesn't name a disk. It names a PersistentVolumeClaim, a request for storage: how much, and how it will be mounted.

1/5
Measure

Each kubelet knows how much CPU and memory its containers use. metrics-server collects it every 15 seconds. kubectl top reads the same numbers.

1/5
Every request is checked

The API server knows who is asking (a user, a group, or a ServiceAccount) and what they want: a verb, a resource, a namespace. RBAC answers allowed or Forbidden.