Skip to content

Supervisor with "NSX + CTGW/Edge/T0"

This section describes the procedures for Troubleshooting Network Services into the VKS Namespace utilizing an "NSX + CTGW/Edge/T0" architecture inside a vSphere environment.

VDS Architecture

Packet Walk - E/W pod to pod

A Full Application (Load Balancer + Pods) has been deployed (see Application Deployment > App Deployment (K8s) > via CLI).

View

Logical View

Logical

Physical View

Physical

Packet Walk Explanation

  • Step 1: Traffic leaves the Source Pod
    Source-Pod-IP (192.168.147.3) => Destination-Pod-IP (192.168.148.3)

    The traffic exits the source pod and hits the Worker Node's local routing engine (managed by kube-proxy and the CNI agent, such as Antrea).

  • Step 2: Cross-Node Encapsulation

    WorkerNode1-IP (172.30.0.5) => WorkerNode2-IP (172.30.0.6)
  [Source-Pod-IP (192.168.147.3) => Destination-Pod-IP (192.168.148.3)]
    Because the destination Pod resides on a different node, the source Worker Node encapsulates the original packet inside a node-to-node tunnel packet.

    Encapsulation for Cross-ESX Traffic

    If the Worker Nodes reside on a different ESX host, the cross-ESX traffic undergoes a second layer of encapsulation using the ESX TEP IPs.
    ESX-TEP_IP (10.1.3.x) => ESX2-TEP_IP (10.1.3.x)
      [WorkerNode1-IP (172.30.0.5) => WorkerNode2-IP (172.30.0.6)]
        [[Source-Pod-IP (192.168.147.3) => Destination-Pod-IP (192.168.148.3)]]

  • Step 3: Destination Node Decapsulation and Delivery (encapsulation2)
    Source-Pod-IP (192.168.147.3) => Destination-Pod-IP (192.168.148.3)

    The destination Worker Node receives the node-to-node packet and strips away the K8s encapsulation header.
    The local routing rules then deliver the unencapsulated packet directly into the destination Pod's network interface.