If you open this article, you will be familiar with Docker. Docker is a kind of virtual container technology, it is relatively simple to get started, just need to pick up a Docker Engine on the host, and then can play happily, such as: pull image, container, mount data, mapping port and so on. Compared to The beginning of Kubernetes (K8S), it is much easier.

So what is the K8S and why is it so hard to get started? K8S is a distributed cluster management system based on container technology, which is an important result of Google’s decades of experience in large-scale application of container technology. So in order to support large-scale cluster management, it hosts a lot of components, and the complexity of distribution itself is very high. And because K8S is produced by Google, it relies on many mirrors of Google itself, so it is more difficult to build an environment for students in China.

Now, with the question, step by step, what is in the K8S?

First, since it is a distributed system, there must be multiple nodes (physical hosts or virtual machines), which together form a distributed cluster, and there will be a Master Node in these nodes, which centrally manages the nodes.

As shown in the figure:

Q1: How do the master node and the worker node communicate?

First, when the Master node is started, it runs a kube-Apiserver process. It provides an API interface for cluster management, serves as the central hub for data interaction and communication between functional modules in the cluster, and provides a complete cluster security mechanism (more on this later).

On the Node Node, kubelet component in K8S is used to run a Kubelet process on each Node, which is responsible for reporting the running status of its own Node to the Master, such as Node registration, termination, and periodic health report, etc. And receive commands from the Master to create the corresponding Pod.

In K8S, Pod is the most basic unit of operation. It is slightly different from docker containers, because pods may contain one or more containers (which can be Docker containers), and these internal containers share network resources, that is, they can access each other via localhost.

Each Pod starts a pause container (a mirror of Google) that uses the default network mode and uses the network Settings of other containers to complete network sharing.

As shown in the figure:

Q2: How does Master schedule Pod to a specified Node?

This work is done by KuBE-Scheduler, which automatically calculates an optimal target Node for each Pod by executing a series of complex algorithms. A common one is round robin scheduling (RR). Of course, it is also possible that we need to schedule Pod to a specified Node. We can achieve the specified effect by matching the Node’s Label with the Pod’s nodeSelector property.

As shown in the figure:

The concepts of labels and selectors will be discussed further below

Question 3: Where is the information of each node and Pod maintained in a unified manner, and who maintains it?

From the perspective of Pod scheduling above, we need to have a storage center to store the resource usage, health status of each node, and basic information of each Pod, so that Pod scheduling can be carried out normally.

In K8S, etCD component is used as a high availability and strong consistency storage warehouse. This component can be built in K8S or built externally for K8S to use.

All configuration information on the cluster is stored in etCD. In order to consider the relative independence of each component and the overall maintainability, kube-Apiserver calls the addition, deletion, modification and search of these stored data uniformly. Apiserver also provides REST support. Not only do they provide services to individual internal components, but they also expose services to users outside the cluster.

External users can manage the cluster through the REST interface or the Kubectl command line tool, which internally communicates with Apiserver.

As shown in the figure:

Q4: How do external users access pods running in the cluster?

While the K8S is managed by external users, we are more concerned with how internally running pods are accessed externally. Those who have used Docker should know that if bridge mode is used, when the container is created, a virtual IP will be assigned, which is inaccessible to the outside world. We need to do a layer of port mapping to map and bind the port inside the container to the port of the host, so that the outside world can access the designated port of the host. You can access the internal container port.

So, is K8S external access implemented in the same way? The answer is no, K8S is a little more complicated. Because the Docker mentioned above is in single-machine mode, and a container exposes a service externally. In a distributed cluster, a service is often provided by multiple applications to share the burden of access, and these applications may be distributed on multiple nodes, which in turn involves cross-host communication.

Here, K8S introduces the concept of Service. It packs several identical pods into a complete Service to provide external services. As for obtaining these identical pods, the labels attribute is set when each Pod is started. In the Service, we select the Pod with the same Name tag attribute through the Selector, as the whole Service, and store the Service information into the ETCD through Apiserver. This work is done by the Service Controller. At the same time, each node will start a Kube-proxy process, which is responsible for the proxy from the service address to the Pod address and load balancing.

As shown in the figure:

Question 5: How does Pod dynamically expand and scale?

Knowing that a service consists of PODS, expanding the service also means expanding the Pod. Generally speaking, it is to make multiple copies of Pod when needed, and reduce the Pod to a specified number when not needed. K8S is managed by a Replication Controller, which sets a desired number of copies for each Pod. When the actual number of copies does not match the desired number, the number is dynamically adjusted to meet the desired number. The expected value can be manually updated by us or automatically expanded by the agent.

As shown in the figure:

Q6: How do the components work together?

Finally, the kube-Controller-Manager process is useful. We learned that ectD acts as a storage center for clustered data, and Apiserver acts as a management data center and a bridge for other processes to communicate with the data center. Service Controller and Replication Controller are managed by Kube-controller-Manager. Kube-controller-manager acts as a daemon. Each Controller is a control loop that monitors the shared state of the cluster through Apiserver and tries to change the actual state if it doesn’t match expectations. About the Controller, Manager also includes Node Controller, ResourceQuota Controller, and Namespace Controller.

As shown in the figure:

conclusion

Without any in-depth implementation details, this paper introduces the basic concepts involved in K8S conceptually from an overall perspective, including:

  • Node

  • Pod

  • Label

  • Selector

  • Replication Controller

  • Service Controller

  • ResourceQuota Controller

  • Namespace Controller

  • Node Controller

And running processes related to:

  • kube-apiserver

  • kube-controller-manager

  • kube-scheduler

  • kubelet

  • kube-proxy

  • pause

This is also a summary of the overall architecture of K8S after I learned it, because when I first started to learn it, I was really confused by so much content when READING the official documents, so I made a simple sorting here. The article has not understood the place in place, welcome to correct!