“This is the 23rd day of my participation in the First Challenge 2022. For details: First Challenge 2022”

【 K8S series 】 K8S learning 27-3, K8S own principle 3

There are four components shared to the master node: ETCD, ApiServer, Scheduler, and Controller Manager

Next we share a wave of components on the Woker node. XDM remember what was on the worker node?

  • kubelet
  • kube-proxy
  • The container corresponding to the actual service

Kubectl has been more or less mentioned, but what exactly does Kubectl do?

Kubelet

Kubelet is one of the key nodes running on a node. It is responsible for all the components running on that node. In general, Kubelet does three things:

  • Request ApiServer, register the current node, and create a Node resource
  • Continuously monitor ApiServer for pods that need to be scheduled to its own node and start the POD container
  • The Kubelet component also runs the container’s survival probe

Is kubelet running pod by itself?

It is actually Kubelet that tells the configured container to pull specific images at run time. Kubelet then monitors the running container and communicates with ApiServer about the container’s status, events, and resource consumption

A graph can be drawn to show a wave:

From the above figure, we can see that kubelet can run, manage, and monitor resource listings on the master node or in the local directory of the worker node for creating pods

The above container B is the LIST of POD resources obtained by ApiServer, and then the pod container created, and the monitoring container B

Container A will have the pod manifest in the worker node’s own manifest directory. Kubelet can still directly use this manifest to create pods and manage and monitor container A

Kube-proxy is another key component in the node

First let’s take a look at what kube-Proxy is all about. Remember that we shared our previous post about certificates and access to POD metadata

K8s is a proxy that ensures that the client can connect to the pod metadata through the K8S API

So why is he the agent?

Let’s recall that he is called an agent because he is a middleman who can facilitate the normal transaction between people at both ends

Such as:

Little A expects to cooperate with little C, but due to some restrictions, little A can’t build A line with little C, but little B can directly cooperate with little C, little A can also talk to little B, so little A can ask little B to help cooperate with little C, and complete what little A needs to do

In this case, little B is A proxy. If little A is regarded as the client and little C as the server, then little B is still A forward proxy. For little C, little A is invisible and hidden, and you can check the previous article if you are interested in this piece: Simple understanding of forward and reverse proxies

So what role does kube-proxy represent here?

One of the initial proxies is the kube-proxy proxy, which is configured with iptables, intercepts server connections, redirects them to the proxy server, and proxies them into pods

As we move backward, we evolve to the iptables proxy mode, and we evolve to the iptables configuration rules that direct packets to any POD, not to the proxy server

You can think of it this way, the contrast between the first and the second proxy

The first way iptables passes the data to the proxy server, but the second way it passes the data directly to the POD, so the performance is better and there is no middleman to make the difference

Today is here, learning, if there is a deviation, please correct

Welcome to like, follow and favorites

Friends, your support and encouragement, I insist on sharing, improve the quality of the power

All right, that’s it for this time

Technology is open, our mentality, should be more open. Embrace change, live in the sun, and strive to move forward.

I am Nezha, welcome to like, see you next time ~