It took me 10 hours to write this K8S architecture analysis

apiVersion: V1
kind: ReplicationController
metadata:
 name: mysqlThe name of RC is globally unique
spec:
 replicas:1 # Expected number of Pod copies
selector :
app: mysql
 template: #Pod template. Use this template to create a Pod
metadata:
 labels:
app:mysql#Pod copy tag
spec:
 containers:# container definition section
     -name:mysql
Image:mysqlThe DockerImage of the container
      Ports:
      -containerPort:3306The container application listens to the port number
      Env:Inject the container's environment variables- name: MYSQL_ROOT_PASSWORD Value: "123456"Copy the code

When kubectl creates a Pod with the Create command, it calls the corresponding RESTAPI method through the API layer in APIServer.

After that, it will enter the permission control layer and obtain the identity of the caller through Authentication and Authorization.

A permission authentication plug-in can be configured in AdmissionControl to check for request constraints. For example, you need to download an image before starting a container, or check for resources that have a namespace.

Remember that in mysql-rc.yaml the configuration needs to generate 1 Pod. At the Registry layer, a Pod is fetched from the CoreRegistry resource as the Kubernetes resource object to be created.

Then store Node, Pod, and Container information in etCD. Etcd can be a cluster. The etCD stores information about nodes, pods, and containers in the cluster. Therefore, it needs to be backed up if necessary or its reliability should be guaranteed.

Controller Manager, Scheduler and Kubelet

Kubectl sends commands to APIServer to create pods and containers on Node based on the configuration file.

In APIServer, through THE API call, permission control, call resources and storage resources process. You haven’t actually started deploying the application yet.

The Controller Manager, Scheduler, and Kubelet are needed to help complete the deployment process.

Before I introduce how they work together, I want to introduce the listening interface in Kubernetes. As you know from the above, all deployment information is written to etCD.

In fact, when etCD stores deployment information, it sends the Create event to APIServer, and APIServer watches the event sent by etCD. Other components also listen for events emitted by the APIServer.

Kubernetes uses this list-watch mechanism to keep data synchronized, as shown above:

• There are three list-watches: kube-controller-Manager (running on Master), kube-Scheduler (running on Master), and kublete (running on Node). They Watch for events emitted by the APIServer when the process is started.
• Kubectl creates a Pod copy on APIServer via the command line.
• The deployment request is logged to the ETCD, where it is stored.
• When etCD receives the Create Pod message, it sends a Create event to APIServer.
• Because Kubecontrollermanager is always listening for events in APIServer. APIServer receives the Create event and sends it to Kubecontrollermanager.
• Upon receiving the Create event, the Kubecontrollermanager calls the Replication Controller to ensure the number of replicas to be created on the Node. In the example above, the MySQL application has one copy and the Tomcat application has two copies. Once the number of replicas is less than the number defined in RC, the Replication Controller automatically creates replicas. Anyway, it’s the Controller that guarantees the number of copies. PS: Capacity expansion and reduction.
• After the Controller Manager creates a Pod copy, APIServer records the Pod details in etCD. For example, the number of copies in a Pod, what the contents of a Container are.
• The same ETCD sends the Pod creation information to APIServer via an event.
• Since Scheduler watches APIServer and plays a “link” role in the system, “link” means that it is responsible for receiving created Pod events and arranging nodes for them. “Boot down” means that after the placement is complete, the Kubelet service process on Node takes over the “second half” of the Pod lifecycle. In other words, Scheduler binds pods to nodes in the cluster according to scheduling algorithms and policies, and writes the binding information to etCD.
• The Scheduler will update the information of Pod after scheduling, and the information is more abundant at this time. In addition to knowing the number of copies of Pod, copy content. We also know which Node to deploy to.
• Again, update the Pod information above to etCD and save it.
• Etcd sends a successful update event to APIServer.
• Note that kubelet is a process running on Node that also listens for Pod updates sent by APIServer via list-watch. In fact, the creation of the Pod is complete at step 9. Why is Kubelete listening all the time? The reason for this is simple, suppose kubectl issued a command at this time, and needed to expand the original 1 RC copy of MySQL to 2. Then the process triggers again. Kubelet, the Node administrator, also adjusts Node resources based on the latest Pod deployment. Or if the number of RC files in the MySQL application does not change, but the image file is updated, kubelet will automatically get the latest image file and load it.

According to the introduction of list-watch above, we can find that in addition to kubectl and APIServer introduced previously, Controller Manager, Scheduler and Kubelet are also introduced.

Here are their functions and principles:

Controller Manager

Kubernetes needs to manage different resources in the cluster, so different controllers are created for different resources.

Each Controller gets events (messages) in APIServer through the listening mechanism. They monitor resources in the cluster and adjust the status of resources through the list-watch interface provided by APIServer.

Think of it as a conscientious manager who manages and adjusts resources on the go. For example, when the Node where MySQL resides unexpectedly goes down, the Node Controller in Controller Manager will discover the fault in time and perform the repair process.

In systems where hundreds or thousands of microservices are deployed, this feature greatly assists operations personnel. It can be seen from this that Controller Manager is the Manager of Kubernetes resources and the core of operation and maintenance automation.

It is divided into eight controllers. Above we introduced the Replication Controller, but we will list the others without further description.

The Scheduler and kubelet

Scheduler binds pods to Nodes based on algorithms and policies, and stores information in etCD.

If Scheduler is like a dispatching room, there are three things it needs to focus on: Pods to be scheduled, nodes to be available, scheduling algorithms, and policies.

Simply put, the Pod is placed in the appropriate Node by scheduling algorithm/policy. At this point, Kubelet on Node listens to the Pod binding event generated by the Scheduler via APIServer, loads the image file using the Pod description, and starts the container.

The Scheduler determines which Node to place the Pod on, and then informs kubelet that decision. Kubelet loads the Pod on Node.

In plain English, Scheduler is the boss and Kubelet is the worker, and they both exchange information via APIServer.

The Service and kubelet

After going through the above steps, the Pod and container are finally deployed on Node.

As deployed in Kubernetes, how do pods access other pods? The answer is through Kubernetes’ Service mechanism.

A Service in Kubernetes defines an access address (IP+Port) for a Service. An application in a Pod accesses one or a group of Pod copies at this address.

The Service is connected to the backend Pod replica cluster through a Label Selector. This way you know that all the pods accessed by the Service belong to the same group because they all have the same Label.

Mysql-svc. yaml = mysql-svc.yaml = mysql-svc.yaml = mysql-svc.yaml = mysql-svc

apiVersion : v1
kind: Service Create a resource object of type Service
metadata:
 name: mysql#Service globally unique name
spec:
prots:
-port: 3306#Service specifies the Service port number
 selector:The Pod tag corresponding to Service is used to classify pods
   app: mysqlCopy the code

Run kubectl as usual and create Service:

Then run the getsvc command to check the Service information:

Here cluster-IP 169.169.253.143 is automatically assigned by Kubernetes. When a Pod needs to access another Pod, it needs to use the Service’s cluster-IP and Port.

In other words, cluster-IP and Port are internal addresses of the Kubernetes Cluster, which are provided for the access between pods in the Cluster. External systems cannot access Kubernetes applications through the cluster-IP.

The Service mentioned above is just a concept, but the real implementation of Service is kube-proxy.

Only by understanding the principle and mechanism of Kube-Proxy can we truly understand the implementation logic behind Service.

Each Node in the Kubernetes cluster runs a Kube-Proxy Service process. We can think of this process as a load balancer for the Service. Its core function is to forward requests to the Service to multiple pods at the back end.

In addition, cluster-IP and NodePort of Service are implemented by Kube-proxy Service through IPtables NAT. Kube-proxy dynamically creates service-related iptables rules during runtime.

Since the iptables mechanism targets the local Kube-proxy port, the Kube-Proxy component is run on every Node.

Therefore, within the Kubernetes cluster, access requests to services can be made from any Node.

Just as MySQL services can be called by Tomcat inside Kubernetes, how can Tomcat be called outside Kubernetes?

Mr Configuration file, myweb-rc.yaml look at:

apiVersion: V1
kind: ReplicationController
metadata:
 name: mywebThe name of RC is globally unique
spec:
 replicas:2# expected number of Pod copies, here the number is 2, need to create two copies of Tomcat
selector :
app: myweb
 template: #Pod template. Use this template to create a Pod
metadata:
 labels:
app:myweb#Pod copy tag
spec:
 containers: # container definition section
     -name:mysql
Image:kubeguide/tomcat-app:v1The DockerImage of the container
      Ports:
      -containerPort:8080The container application listens to the port numberCopy the code

Create a copy of MyWeb in Kubectl using Create.

After the replica is created, create the corresponding service configuration file myweb-svc.yaml.

apiVersion : v1
kind: Service Create a resource object of type Service
metadata:
 name: myweb#Service globally unique name
spec:
prots:
-port: 8080#Service specifies the Service port number
nodePort: 30001This is the external network access Kubernetes internal application port.
 selector: The Pod tag corresponding to Service is used to classify pods
   app: mywebCopy the code

Also run the Create command in Kubectl to Create the Service resource.

As can be seen from the above configuration file, the Tomcat Service has an additional nodePort configuration value of 30001.

This means that the external network can access Tomcat through port 30001 plus NodeIP.

After running the command, you get a prompt that roughly translates to “if you want to expose the service to the Internet, you need to set up firewall rules for port 30001 to be accessible.”

Because Cluster-IP is a virtual IP, it is only used for communication between pods within Kubernetes.

Node is a physical Node, so a combination of Node-IP and nodePort is used to access internal applications from outside Kubernetes.

If two Tomcat applications are deployed according to the above configuration, which Pod should be selected when accessing the Internet? This is done through a load balancer other than Kubernetes.

This is facilitated by Kubernetes’ LoadBlancerService component. Apply for creating a load balancer on the cloud platform to expose services.

At present, the LoadBlancerService component supports relatively complete cloud platforms, such as foreign GCE, DigitalOcean, Domestic Ali Cloud, private cloud OpenStack and so on.

Kubernetes will automatically create a LoadBalancer instance and return its IP address for external clients to use by changing Service type=NodePort to type=LoadBalancer.

So far, MySQL (RC 1) and Tomcat (RC 2) have been deployed on Kubernetes. And in Kubernetes internal Pod is mutually accessible, extranet can also access to Kubernetes internal Pod.

In addition, Kubernetes runs cAdvisor on each Node and container as a resource monitor. It is a tool for analyzing resource utilization and performance and supports the Docker container.

Kubelet obtains data from its Node and container (Docker) through cAdvisor. CAdvisor automatically collects statistics on CPU, memory, file system, and network usage.

As the Node manager, Kubelet exposes the data collected by cAdvisor to other Kubernetes resources in the form of RESTAPI to let them know the resource usage in Node/Pod.

conclusion

Due to the rapid development of micro-services, Kubernetes is widely used as a micro-service governance platform. Due to its long development time, including many service functions we can not list one by one.

Therefore, starting with a simple example of creating a copy of an application, the concepts and fundamentals of each important component are introduced.

Kubernetes is used to manage the cluster of containers, with the Master as the Manager, including APIServer, Scheduler, and Controller Manager.

Node serves as a carrier for replica deployment and contains multiple pods, each of which contains multiple containers. The user uses Kubectl to issue deployment commands to APIServer in Master.

The command body is a configuration file ending with. Yaml, which contains the type, number, name, port, and template of the copy.

After APIServer receives the request, it performs the following operations: authenticates permissions (including special controls), extracts resources to be created, and saves copy information to ETCD.

APIServer and Controller Manager, Scheduler and Kubelete communicate with each other in list-watch mode (event sending and listening).

The Controller Manager obtains the number of copies of the resources to be created through etCD and sends them to Scheduler for policy analysis.

Finally, Kubelet is responsible for the final Pod creation and container loading. Once the container is deployed, it is accessed through the Service and resources are monitored through the cAdvisor.

The above content is some of my own feelings, share out welcome correction, incidentally beg a wave of attention