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

How to understand the Kubernetes network model and network solution, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Kubernetes acts as an orchestration engine that manages containers and Pod distributed on different nodes. Pod, Service, and external components need a reliable way to find and communicate with each other, and the Kubernetes network is responsible for providing this guarantee.

Kubernetes network model

Kubernetes adopts a network model based on flat address space. Each Pod in the cluster has its own IP address, and the Pod can communicate directly without configuring NAT. In addition, containers in the same Pod share the IP of Pod and can communicate over localhost.

This network model is very friendly to application developers and administrators, and applications can be easily migrated from traditional networks to Kubernetes. Each Pod can be seen as an independent system, while containers in Pod can be seen as different processes in the same system.

The following discusses how the various entities in the cluster communicate under this network model. Knowledge points have been involved before, here can be used as a review and summary.

Communication between containers in Pod

When Pod is dispatched to a node, all containers in Pod run on that node, and these containers share the same local file system, IPC, and network namespace.

There is no port conflict between different Pod because each Pod has its own IP address. When a container uses localhost, it means that the address space of the Pod to which the container belongs is used.

For example, Pod A has two containers, container-A1 and container-A2,container-A1, listening on port 1234. When container-A2 connects to localhost:1234, it is actually accessing container-A1. This does not conflict with Pod B on the same node, even though the container container-B1 in Pod B is listening on port 1234.

Communication between Pod

The IP of Pod is cluster visible, that is, any other Pod and nodes in the cluster can communicate with Pod directly through IP, which does not require any network address translation, tunneling or proxy technology. Pod uses the same IP internally and externally, which also means that standard naming services and discovery mechanisms, such as DNS, can be used directly.

Communication between Pod and Service

Pod can communicate directly through the IP address, but only if the Pod knows the other party's IP. In Kubernetes clusters, Pod may be destroyed and created frequently, which means that the IP of Pod is not fixed. To solve this problem, Service provides an abstraction layer to access Pod. No matter how the back-end Pod changes, Service provides services as a stable front-end. At the same time, Service also provides high availability and load balancing, and Service is responsible for forwarding requests to the correct Pod.

External access

Whether it is Pod's IP or Service's Cluster IP, they are only visible in the Kubernetes cluster, and these IP are private to the world outside the cluster.

Kubernetes provides two ways for outsiders to communicate with Pod:

NodePort

Service provides services through the static port of the Cluster node. Externally, you can access Service through:

LoadBalancer

Service uses load balancer provided by cloud provider to provide services, and cloud provider is responsible for directing load balancer traffic to Service. Currently, cloud provider supports GCP, AWS, Azur and so on.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.