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

A brief talk on kubernetes Communication

In our daily work, we can only encounter the following three situations: the interconnection within the K8s cluster, the internal access to the services outside the K8s cluster, and the access to the external services of the K8s cluster. Let's explain how they are implemented, and we will explain them in a step-by-step manner.

Communication within kubernetes cluster

When there are only two POD in K8s, the communication is the easiest.

The figure above shows that our Pod B client links to request Pod A server. At this time, we just need to tell Pod B the address of Pod A. At this time, Pod A can no longer handle the request. We need to extend a Pod A

Do we just want to put a Nginx or something in front of the Pod A server to do the load? only in this way can Pod B request the service according to the previous address, so we add a service service to Pod An at this time.

The svc resource selects the Pod with the corresponding tag through the matchLables field. At this time, Pod B directly accesses SVC A when it requests the service. We tell Pod B SVC A what the corresponding IP address is, and SVC A will be automatically loaded on the backend POD A. It should be noted that if A service still cannot withstand the pressure at this time, we only need to start a few more Pod A, after launching the new Pod. Svc will still add it to the load automatically according to matchLables.

There can't be only two services in our K8s cluster. There must be many services, but we can't configure each of them manually, so we introduced the concept of CoreDNS at this time. We use CoreDNS to maintain the relationship between svc and clusterIP.

In fact, the communication within the K8s cluster is generally clear at this time, but there is a very special svc:headless svc in this svc. When other clients request him, he will not load the request to the following pod, but return all the IP of the following POD to the client, and it is up to the client to decide which POD to link.

K8s cluster requests services outside the cluster

If it is a single service, we can choose to connect directly to the external service internally, but if the external service is a cluster, then if we continue to do so, we need to do a load in front of the external cluster.

But if there are many clusters, we have to create a lot of four-tier loads of nginx, which is too troublesome. We can put the load into the K8s cluster, and we use the svc+endpoints of K8s to achieve load balancing of external clusters.

At this time, svc and endpoint are bound by name, so we can communicate inside and outside the cluster.

K8s cluster external and K8s cluster internal communication

In practice, in addition to the internal communication of K8s cluster, I think this kind of communication is used more frequently, because the cluster we run on K8s is for customers to visit. Next we will implement it in three ways.

Nodeport

Nodeport is the port we bind on node, so this pord port will be opened on node. We can request one of the node ports arbitrarily, even if the pod does not fall on this node. When the request is sent to nodeport, it will automatically forward it to the corresponding Podip for access.

Hostport

The pod must fall on that node before that node will open the corresponding port.

Ingress

Ingress is the most common way for us to use exposed K8s cluster internal services for external access. Ingress is a general term for a class of resources. We generally apply ingress-nginx now. For ingress, please refer to https://www.zhangshoufu.com/articles/2019/07/19/1563529715618.html. I won't go into details here.

Video explanation: https://www.bilibili.com/video/av71139472

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.