This is Chapter 1 of the Kubernetes Fundamentals series.

Nodes and clusters

  • A node (sometimes called a minion) is a worker machine in Kubernetes - a collection of Pods runs on it.
  • Multiple nodes together form a cluster.
  • One node in that cluster is the master node - it watches over the worker nodes, orchestrates containers across them, and is where Kubernetes itself is installed.

The five components

Installing Kubernetes means installing five components. A mnemonic worth keeping: Api-server, Etcd, Kubelet, Controller, Scheduler:

ComponentWhat it doesRuns on
kube-apiserverThe frontend to the cluster - users, CLIs, and management tools all talk to it to interact with KubernetesMaster node
etcdDistributed, reliable key-value store holding all data used to manage the clusterMaster node
kubeletAgent on each node that makes sure containers are running as expectedWorker node
Container runtimeThe underlying software that actually runs containers, e.g. DockerWorker node
ControllerThe brain behind orchestration - watches for containers going down and spawns replacementsMaster node
SchedulerDistributes work (containers) across the available nodesMaster node

How the pieces connect

   kubectl / users
         |
         v
  +------------------------------------+
  |             MASTER NODE              |
  |  kube-apiserver   - the entry point  |
  |  etcd             - cluster state    |
  |  controller       - watches & heals  |
  |  scheduler        - places Pods      |
  +------------------------------------+
         |
         v   scheduler assigns a Pod to a node
  +------------------------------------+
  |             WORKER NODE              |
  |  kubelet           - runs the Pod    |
  |  container runtime - e.g. Docker     |
  |  Pod(s)                               |
  +------------------------------------+

Every arrow above only flows one way - the worker node never talks back to the master except through kube-apiserver, and nothing outside the master node ever reaches etcd, the controller, or the scheduler directly.

Pods

A Pod is a single instance of an application, and the smallest object in Kubernetes - a container is always encapsulated inside one, never run directly. Running more than one container in a Pod is a rare, advanced pattern; stick to a single container per Pod unless there’s a specific reason not to (a sidecar, for example).

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  namespace: dev
  labels:
    app: myapp
    type: frontend
    env: production
spec:
  containers:
    - name: nginx-container
      image: nginx
      ports:
        - containerPort: 8080
      resources:
        requests:
          memory: "4Gi"
          cpu: 2

Chapter 2 covers creating and managing this object with kubectl.

Notes

  1. The master node is excluded from scheduling by default - a taint is applied to it automatically at cluster creation, covered in Chapter 5.
  2. Chapter 2 picks up from here with kubectl itself and the imperative/declarative split for managing the Pod object shown above.
  3. Next: Chapter 2 - kubectl and Pods.