Juniper CN2 introduces segmentation and isolation into Kubernetes using Virtual Networks and Virtual Network Routers.
A Virtual Network is a logical connectivity zone created and managed within the CNI and delivered using software-defined networking. It allows for the creation of multiple isolated virtual networks on top of a shared physical network infrastructure.
A virtual network has a default Routing Instance, which has a default Route-Target (RT). A routing-instance refers to a virtual routing table representing a routing domain within the system. The route-target is a BGP extended community that acts as a label for the prefixes in the routing table and allows these prefixes to be imported or exported to other Routing Instances.
Workloads within the same virtual network share the same Routing Instances and route-targets and are naturally connected. However, when workloads are created in different VNs, route-target import and export actions are required to allow workloads to communicate with one another. When many VNs need to interconnect, such as in a mesh of routing instances, this can introduce an increased setup time and management burden of the resources within the system. Virtual Network Routers come to rescue this situation.
A Virtual Network Router or VNR is a construct introduced in CN2 to simplify establishing and managing connections between Virtual Networks. Like Virtual Network, a VNR has a default Routing Instance and Route-Target.
In contrast to the typical route-target approach of interconnecting all routing instances to each other, a VNR establishes a connection between two or more VNs by importing and exporting the VNR’s RT to the connected Virtual Networks.
To include VNs in a VNR, Kubernetes label selectors are used to identify virtual networks to interconnect.
When a VNR is created with a label selector “vn: test” the VNR’s RT will be shared with the routing instances within the namespace that also have the label “vn: test” establishing the connection between them.
Additional virtual networks can be easily added to the list of connected VNs by adding the label in the new VN. Similarly, a VN can be removed from the connected VN list by removing or changing the label.
An illustration of mesh connection of vn-1, vn-2, vn-3 by VNR-1
VNRs are configured to select VNs in the same namespace as the VNR, which allows for modular connection and quick reconciliation. VNs from different namespaces can be connected by creating one VNR per namespace and importing them into one another.
Also, based on VNR’s RT being imported or exported at the connected VNs, VNR can support two types of forwarding topologies.
- Mesh VNR - Connects all selected VNs in a full mesh
- Spoke VNR – VNs connected to Spoke VNR cannot connect to each other but to VNs of the Hub VNR
- Hub VNR – VNs connected to Hub VNR cannot connect to each other but to VNs of the Spoke VNR
VNRs are a fundamental building block of CN2 and are used in many other features such as Isolated-Namespaces. In recent releases, CN2 has extended the functionality of the VNR by introducing EVPN routing support with Type-5 prefixes.
Recommended Further Reading:
------------------------------
Nagendra Prasath Maynattamai
------------------------------