Kubernetes concepts

Basic things we can ask Kubernetes to do

It's Black Friday (or Christmas), traffic spikes, grow our cluster and add containers

Basic autoscaling
Blue/green deployment, canary deployment
Long running services, but also batch (one-off) jobs
Overcommit our cluster and evict low-priority jobs
Run services with stateful data (databases etc.)
Fine-grained access control defining what can be done by whom on which resources
Integrating third party services (service catalog)
Automating complex tasks (operators)

The first schema is a Kubernetes cluster with storage backed by multi-path iSCSI

(Courtesy of Yongbok Kim)
The second one is a simplified representation of a Kubernetes cluster

(Courtesy of Imesh Gunaratne)

The nodes executing our containers run a collection of services:
- a container Engine (typically Docker)
- kubelet (the "node agent")
- kube-proxy (a necessary but not sufficient network component)
Nodes were formerly called "minions"

(You might see that word in older articles or documentation)

The Kubernetes logic (its "brains") is a collection of services:
- the API server (our point of entry to everything!)
- core services like the scheduler and controller manager
- etcd (a highly available key/value store; the "database" of Kubernetes)
Together, these services form the control plane of our cluster
The control plane is also called the "master"

It is common to reserve a dedicated node for the control plane

(Except for single-node development clusters, like when using minikube)
This node is then called a "master"

(Yes, this is ambiguous: is the "master" a node, or the whole control plane?)
Normal applications are restricted from running on this node

(By using a mechanism called "taints")
When high availability is required, each service of the control plane must be resilient
The control plane is then replicated on multiple nodes

(This is sometimes called a "multi-master" setup)

The services of the control plane can run in or out of containers
For instance: since etcd is a critical service, some people deploy it directly on a dedicated cluster (without containers)

(This is illustrated on the first "super complicated" schema)
In some hosted Kubernetes offerings (e.g. GKE), the control plane is invisible

(We only "see" a Kubernetes API endpoint)
In that case, there is no "master node"

For this reason, it is more accurate to say "control plane" rather than "master".

By default, Kubernetes uses the Docker Engine to run containers
We could also use rkt ("Rocket") from CoreOS
Or leverage other pluggable runtimes through the Container Runtime Interface

(like CRI-O, or containerd)