Cluster Network

Overview

When creating a Kubernetes cluster, to ensure its normal operation, we need to plan network segments for three types of resource objects: Node, Pod, and Service, all requiring unique network identifiers. As a production-grade container orchestration and scheduling system, Kubernetes mandates that network solutions 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.

Network plugins implementing this criterion mean Pods must have independent IPs, identical to the network model in the virtual machine era. This provides a solid foundation for migrating services from virtual machines to Kubernetes and enabling collaborative operations.

UK8S Network Model

Kubernetes itself only provides network specifications and open interfaces, allowing users to install open-source network plugins or develop custom CNI plugins. For UK8S, developing a custom CNI plugin requires solving the following network challenges:

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:
Tests show that under this network scheme, network communication performance between Pods is comparable to 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;