In the joint efforts of the community members, Kube-OVN 1.11 has been officially released.
In this version, we have further enhanced the functionality, performance, stability, and usability of Kube-OVN. These enhancements include the intercommunication between Overlay and Underlay, Underlay nesting in k8s on k8s environments, support for LoadBalancer type Services, SR-IOV Network Operator support, internal load balancing in custom VPCs, and DNS in custom VPCs. Additionally, we have restructured the testing system, added extensive testing, and addressed stability and performance issues. A total of 32 community members have contributed to this release, and we would like to express our gratitude for their contributions and support.
Let's take a closer look at the new capabilities of Kube-OVN v1.11!
Overlay and Underlay Subnet Intercommunication
When both Overlay and Underlay subnets coexist in a cluster, by default, Pods in the Overlay subnet can access Pods in the Underlay subnet via NAT through the gateway. From the perspective of Pods in the Underlay subnet, the addresses in the Overlay subnet appear as external addresses that need to be forwarded through the underlying physical devices. However, the underlying physical devices are unaware of the addresses in the Overlay subnet and cannot perform the forwarding. As a result, Pods in the Underlay subnet cannot directly access Pods in the Overlay subnet using Pod IPs.
To enable intercommunication between Underlay and Overlay, the u2oInterconnection setting of the subnet needs to be set to true. In this case, Kube-OVN will use an additional Underlay IP to connect the Underlay subnet with the ovn-cluster logical router and set corresponding routing rules to achieve intercommunication. Unlike the logical gateway, this solution only connects the Underlay and Overlay subnets within Kube-OVN, and other traffic destined for the external network will still be forwarded through the physical gateway.
SR-IOV Network Operator
Previously, configuring Mellanox offload required manual operations. With the SR-IOV Network Operator, the process of configuring network cards for Mellanox can be automated, greatly simplifying the complexity of using Mellanox for Kube-OVN acceleration.
Internal Load Balancing in Custom VPCs
While Kubernetes itself provides the ability for internal load balancing through Services, it is limited by the Kubernetes implementation. The IP addresses of Services are globally allocated and cannot be duplicated. For users in VPC scenarios, they may need to define custom address ranges for internal load balancing, and the load balancing addresses in different VPCs may overlap. The built-in Service feature of Kubernetes cannot fully meet these requirements.
To address this scenario, Kube-OVN provides the SwitchLBRule resource, allowing users to define custom address ranges for internal load balancing.
Here is an example of a SwitchLBRule:
Custom VPC DNS
Due to the isolation between custom VPC and default VPC networks, it is not possible for custom VPCs to access coredns deployed in the default VPC. If users want to use the cluster-internal domain name resolution capability provided by Kubernetes within their custom VPC, they can utilize the newly introduced vpc-dns Custom Resource Definition (CRD) to achieve this.
The CRD ultimately deploys a coredns Pod with two network interfaces: one in the user's custom VPC and the other in the default VPC, enabling network communication. Additionally, the custom VPC internal load balancing is provided through the custom VPC.
Load Balancer Type Service
In previous versions, Kube-OVN supported Load Balancers in custom VPCs through vpc-nat-gateway. In this version, we have extended the functionality of vpc-nat-gateway to the default VPC and combined it with Load Balancer type Services. Users can now use similar mechanisms as in custom VPCs to implement Load Balancer type Services in the default VPC.
Other Features
● Controller startup time optimization
● Network interruption time optimization during upgrade
● Memory usage optimization for OVS and controller
● Controller election mechanism optimization
● ARP conflict detection in Underlay subnets
● Multicast optimization in Underlay subnets