Kubernetes architecture at a high level is relatively straightforward. It is composed of a master node and a set of worker nodes. The nodes can be either physical servers or virtual machines (VMs). Users of the Kubernetes environment interact with the master node using either a commandline interface (kubectl), an application programming interface (API), or a graphical user interface (GUI). The master node is responsible for scheduling work across the worker nodes.
In Kubernetes, the unit of work that is scheduled is called a Pod, and a Pod can hold one or more container. The primary components that exist on the master node are the kube-apiserver, kube-scheduler, etcd, and the kube-controller-manager:
The kube-apiserver makes available the Kubernetes API that is used to operate the Kubernetes environment.
The kube-scheduler component is responsible for selecting the nodes on which Pods should be created.
Kubernetes provides several high-level abstractions for supporting replicas of Pods, managing nodes, and so on. Beside that, each of these implements with a controller component. The kube-controller-manager is responsible for managing and running controller components.
The etcd component is a distributed key–value store and is the primary communication substrate used by master and worker nodes. This component stores and replicates the critical information state of your Kubernetes environment. Kubernetes outstanding performance and scalability characteristics are dependent on etcd being a highly efficient communication mechanism.
The worker nodes are responsible for running the Pods that are scheduled on them. The primary Kubernetes components that exist on worker nodes are the kubelet, kube-proxy, and the container runtime:
The kubelet is responsible for making sure that the containers in each Pod are born and stay up and running. The kubelet will restart containers upon recognizing that they have terminated unexpectedly.
One of Kubernetes key strengths is the networking support it provides for containers. The kube-proxy component provides networking support in the form of connection forwarding, load balancing, and the mapping of a single IP address to a Pod.
The container runtime component is responsible for actually running the containers that exist in each Pod. Kubernetes supports several container runtime environment options including Docker, rkt, and containers.
As shown in figure above, users interact with the Kubernetes master node using either a GUI or by commandline interface (kubectl CLI). Both of these use the Kubernetes exposed API to interact with the Kubernetes master node. The Kubernetes master node schedules Pods to run on different worker nodes. Each pod contains one or more containers, and each pod has its own IP address. In any real-world applications, Kubernetes deploys multiple replica copies of the same Pod to improve scalability and ensure high availability. The allocated Pods A1 and A2 are Pod replicas that differ only in the IP address. In a similar fashion, Pods B1 and B2 are also replica copies of the same Pod. The containers allocated in the same Pod have permission to communicate with one another using standard inter-process communication (IPC) mechanisms.
Fore more info : Visit Official Site