Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to deploy visual maps in Kubernetes". In daily operation, I believe many people have doubts about how to deploy visual maps in Kubernetes. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "how to deploy visual maps in Kubernetes". Next, please follow the editor to study!

You can better understand Kubernetes by looking at the 10 steps in creating a pod or deployment.

When you use containers on Kubernetes, you often combine applications in a pod pod. When you publish a container or a pod to a production environment, it is called a deployment deployment. If you use Kubernetes every day or even every week, you may have done this hundreds of times, but have you ever wondered what happens when you create a pod or deployment?

I find it helpful to understand the chain of events at a high level. Of course, you don't have to understand it. Even if you don't know why, it's still working. I'm not going to list every little thing that happens, but my goal is to cover all the important things.

Here is a visual map of how the different components of Kubernetes interact.

Pod chain

You may have noticed that in the above picture, I did not include etcd. The API server is the only component that can talk directly to etcd, and only it can modify etcd. Therefore, you can assume that etcd exists behind the (hidden) API server in this picture.

In addition, I only talked about the two main controllers here (deployment controller Deployment controller and replication set controller ReplicaSet controller). Other controllers work in a similar way.

The following steps describe what happens when you execute the kubectl create command.

Step 1

When you use the kubectl create command, a HTTP POST request is sent to the API server, which contains the deployment list. The API server stores it in the etcd data store and returns a response to kubectl.

Steps 2 and 3

The API server has an observation mechanism, and all customers who observe it are notified. The client observes the change by opening a HTTP connection to the API server, and the API server sends out notifications streaming. One of the clients is the deployment controller.

The deployment controller detects a deployment Deployment object that creates a replication set ReplicaSet with the current specification of the deployment. The resource is sent back to the API server and stored in the etcd data store.

Steps 4 and 5

Similar to the previous step, all observers are notified of changes in the API server. This time, the replication set controller receives the change.

The controller understands the number of copies required and the pod selector defined in the object specification, creates a pod resource, and sends this information back to the API server for storage in the etcd data store.

Steps 6 and 7

The Kubernetes now has all the information needed to run the pods, but on which node should the pods run? The scheduler Scheduler looks at pods that have not yet been assigned to nodes and begins to filter and sort all nodes to select the best node to run the pod.

Once the node is selected, this information is added to the pod specification. And it is sent back to the API server and stored in the etcd data store.

Steps 8, 9 and 10

All the steps so far have taken place in the control plane control plane itself. The worker node worker node hasn't done any work yet. However, the creation of pods is not handled by the control plane.

Instead, the kubelet service running on all nodes looks at the pod specifications in the API server to determine if it needs to create any pods.

The kubelet service running on the node selected by the scheduler gets the pod specification and instructs the container on the worker node to create the container at runtime. At this point, a container image is downloaded (if it doesn't already exist), and the container actually starts running.

Understand the deployment of Kubernetes

An understanding of this general process can help you understand many events in Kubernetes. Consider the daemon set DaemonSet or state set StatefulSet in Kubernetes. Except for using different controllers, the process of creating pods is the same.

Homework: what would the chain of events that led to the creation of the pod look like if the deployment was modified to have three copies of the application? You can refer to the chart or the steps listed, but you must have the knowledge you need to figure out. Knowledge is power, and you now have an important part of understanding Kubernetes.

At this point, the study on "how to deploy visual maps in Kubernetes" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.