Kubernetes follows a client-server architecture. A Kubernetes cluster consists of at least one master and multiple worker nodes (or minions).
It is also possible to have a multi-master setup for high availability, but by default there is a single master node which acts as a controlling node and point of contact. Other masters nodes works as followers to the main master node.
The master node consists of following components
- etcd storage
- api server
The worker node consists of following components
etcd cluster – It is an open source, highly available, distributed key value storage which is used to store the Kubernetes cluster data (such as number of pods, their state, namespace, etc), API objects and service discovery details.
It is accessible only by Kubernetes API server for security reasons. etcd enables notifications to the cluster about configuration changes with the help of watchers.
Notifications are API requests on each etcd cluster node to trigger the update of information in the node’s storage.
api server – It is the central management entity that receives all REST requests for modifications to pods, services, replication sets/controllers and others. It serves as front end to the cluster.
This is the only component that communicates with the etcd cluster, making sure data is stored in etcd and is in agreement with the service details of the deployed pods.
Kubeconfig is a package along with the server side tools that can be used for communication. It exposes Kubernetes API.
controller-manager – It is responsible for most of the collectors that regulates the state of cluster and performs a task (for example, replication controller controls number of replicas in a pod, endpoints controller populates endpoint objects like services and pods, and others).
When a change in a service configuration occurs, the controller spots the change and starts working towards the new desired state.
kube-scheduler – It is responsible for distributing (or schedule) the workload on the various worker nodes based on resource utilization.
Worker Node Components
Docker – The first requirement of worker nodes is Docker. Docker is responsible for pulling down and running container from Docker images.
kubelet – It regularly taking in new or modified specifications from etcd through the api server and ensuring that pods and their containers are healthy and running in the desired state.
It also reports to the master on the health of the host where it is running.
kube-proxy – It is a proxy service that runs on each worker node helps in making services available to the external host. It performs request forwarding to the correct pods/containers across the various isolated networks in a cluster.
It manages pods on node, volumes, secrets, creating new containers’ health checkup, etc.
Command line interface
kubectl is a command line interface that interacts with api server and send commands to the master node. Each command is converted into an API call.