Cluster Network

Overview

When we create a Kubernetes cluster, in order for the cluster to work properly, we need to plan network segments for three types of resource objects, namely Node, Pod, Service, each of which requires a unique network identification. As a production-level container orchestration and scheduling system, Kubernetes requires that each network solution must meet the following three requirements:

1. The network between Pods is interconnected and does not need to go through NAT conversion.

2. The network between the Pod and the Node is interconnected, and no NAT conversion is required.

3. The IP seen by the container inside the Pod should be the same as the IP seen by the external application.

The network plugin implemented based on this principle means that the Pod must have an independent IP, which is completely consistent with the network model in the era of virtual machines, providing a good foundation for business to migrate to Kubernetes, including collaborative work.

UK8S Network Model

Kubernetes itself only provides network specifications and open interfaces. Kubernetes users can install open-source network plugins or develop CNI plugins on their own. For UK8S, to develop CNI plugins on its own, it needs to solve the following network problems.

1. Communication problem between Pod and Pod.

2. Communication problem between Pod and UHost, UDB and other cloud resources.

3. Communication between Pod and Service. The Kubernetes community provides two solutions, IPtables and IPVS. UK8S uses the IPtables solution. If you are interested in the specific principles of this part, you can check the official documentation, and it will not be detailed here.

4. Communication between the cluster external and the Service. Kubernetes provides the LoadBalancer type of Service. UK8S has supported it. For details, please refer to Service

Considering the above points, different from the overlay solutions often used by third-party plugins, we use the underlay solution combining the characteristics of the public cloud.

Pod and Node belong to the same subnet, IP are allocated by SDN network, and the Cluster IP of Service is only used within the cluster. Users only need to allocate a network segment that does not overlap with the VPC subnet. The schematic diagram of the network segment is as follows:

Through testing, the network communication performance between pods under this network scheme is not much different from that between virtual machines.

Cluster Communication

I. Internal cluster communication

1. Inter-network communication between Pods in the cluster;

2. Inter-network communication between Pod and Node in the cluster;

3. Inter-network communication between Pod and Service in the cluster;

II. Communication with cloud resources

1. Inter-network communication between Pod in the cluster and resources such as UHost, UDB, UMem (same VPC, same below);

2. Inter-network communication between Pod in the cluster and PHost;

3. Inter-network communication between Pod in the cluster and hybrid cloud;