CN2

 View Only
last person joined: one month ago 

Ask questions and share experiences with Juniper’s Cloud-Native Contrail Networking (CN2).
Back to discussions
Expand all | Collapse all

CN2 Custom Default Pod Networks

  • 1.  CN2 Custom Default Pod Networks

    Posted 04-27-2023 10:10

    Kubernetes networking is "flat", meaning that the default pod network is a single subnet that is used by all the pods in the cluster. Pods within the cluster can freely communicate with each other making the cluster internal pod networking insecure by default. Kubernetes advocates for usage of Network Policies to isolate pods but managing these policies very quickly becomes complicated at scale. To tackle this, CN2 brings the ability to create network level segmentation for your applications.

                Figure 1: k8s pod communication is insecure by default.


    Virtual Networks are a backbone of Juniper's Cloud Native Contrail Networking (CN2) SDN. A Virtual Network is a logical connectivity zone created and managed within the CNI and is associated with a subnet. Multiple virtual networks can be created and are isolated from one another by default even if their subnets overlap.

    When CN2 is used as the CNI in your Kubernetes cluster, you have the ability of creating pods that are isolated from one other at a per-pod or per-namespace basis. An annotation specifying a virtual network can be placed on a pod or a namespace. When a pod with the annotation on itself or its namespace is created, its primary network interface will have an IP address allocated from the virtual network and not the default pod network. This ensures that pods are now isolated at the network level. No pesky network policies required!

            Figure 2: k8s pod networking with network segmentation.


    All the usual features expected of cluster networking continue to work even with a custom pod network. You can create services that select these pods, and as expected, the service would respond only when the request originates from the same network, preserving isolation. These pods have access to critical services like kubernetes and kube-dns, so in-cluster k8s API calls and DNS requests continue to work.

    There are instances where pods in different pod networks might have to interact with one another. CN2 supports VirtualNetworkRouters, which are constructs that can be used to interconnect VNs and thus the pods within those VNs.

                  Figure 3: connecting isolated pods via VNRs.


    To learn more about these features and CN2, please refer to the following links:



    ------------------------------
    Pranav Cherukupalli
    ------------------------------