A functioning cluster needed six components:
- API server
- Scheduler
- Controller manager
- kubelet
- kube-proxy
- etcd
Each one could run as a normal Linux process, or inside a container.
Control plane
The master ran the API server, the scheduler, and the controller manager. It could be set up as multi-master. The scheduler and the controller manager elect a leader. The API servers can sit behind a load balancer.
The API server exposes a REST interface to Kubernetes resources and is configurable. The scheduler places containers on nodes using policies, metrics, and resource requests, and it can be tuned with command-line flags. The controller manager reconciles the cluster’s actual state with the desired state from the API. It is a control loop, and it is configurable too.
Workers
Every worker ran kubelet, kube-proxy, and the Docker engine. kubelet talked to Docker and kept the containers that should be running actually running. kube-proxy handled network connectivity to those containers.
The post also pointed at rkt as an alternative to the Docker engine: rkt getting started guide.
The diagram was from a Kubernetes training slide by @wattsteve.
Written in December 2017. Newer writing here is on VMware Cloud Foundation, Avi, and NSX.
