# Kubernetes Architecture overview

Here we have the overview picture of the Kubernetes Architecture

Here are the main point to retain:

• a typical Kubernetes cluster has 1..3 master nodes and 1..n worker nodes.
• a master node (Control Plane) manages the worker nodes (where the services are deployed using pods) .
• we can administrate the Kubernetes cluster using a UI (User Interface), API or CLI commands (kubectl).
• all the administrative tasks are received initially by the API Server.
• when we want to modify the desired state of the K8s cluster, the API Server will update the etcd database with this new desired state.
• etcd is a distributed key-value storage accessible only by API Server.
• the Scheduler knows the nodes utilization and decides where K8s needs to create new pods.
• the Controller Manager keeps track of what is happening in the cluster. If K8s needs to (re)create a new pod, the Controller Manager will tell to API Server to spawn a new pod. API Server will talk with the Scheduler to know where to create a new pod and after that, API Server will communicate the action to the appropriate kubelet service.
• the kubelet is the primary "node agent" that runs on each node. It can register the node with the API Server, monitor the pods and the node consumption. The kubelet doesn't manage containers which were not created by Kubernetes.
• the kube-proxy service maintains the network rules for communication with the pods (from inside/outside the cluster) The kube-proxy could run in 3 modes iptables (when we have LESS than 1000 pods), ipvs (when we have MORE than 1000 pods), userspace (not recommended anymore). The kube-proxy service acts as a load-balancer as well.
• Nodes may be cloud-native virtual machines (VMs) or bare metal servers in data centers.
• Kubernetes works with some container runtimes (which runs the containers) like Docker, rkt or containerd.