Skip to content

Supervisor with "NSX + DTGW/VNA"

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

VDS Architecture

Packet Walk - N/S External to VIP

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

  • Step1: External Client accesses the VIP
    Client-IP => VIP:80 (10.1.7.138)

    The traffic enters the ESX hosting the VNA Node that hosts the Active VPC-SR (Service Router).

  • Step2: VIP load balances traffic to the K8s Worker Nodes (kube-proxy)
    VPC-SR-Internal-IP => K8s WorkerNode[1-3]:31147 (172.30.0.[x])

    The load balancer (VPC-SR) forwards the traffic to the dynamically assigned NodePort on the K8s Worker Nodes.

    Encapsulation for Cross-ESX Traffic

    If the Worker Nodes reside on a different ESX than the Active VPC-SR, the cross-ESX traffic is encapsulated using the ESX TEP IPs.
    ESX-TEP_IP (10.1.3.x) => ESX-TEP_IP (10.1.3.x)
      [VPC-SR-Internal-IP => K8s WorkerNode[1-3]:31147 (172.30.0.[x])]

    Find the dynamically assigned Worker Node TCP port (31147)

    You can find the dynamically assigned Worker Node TCP port (31147) by running the command kubectl get service apache-vip-service -n ns1 and looking under the PORT(S) column (see Application Deployment > App Deployment (K8s) > via CLI)

  • Step 3: The K8s Worker Node intercepts the traffic
    Once the traffic arrives at the Worker Node's network interface on the NodePort (31147), it is intercepted by the node's local routing rules (which are continuously programmed by the local kube-proxy pod).

  • Step 4 (not represented): The Worker Node load balances traffic to the Pods
    Based on those kube-proxy rules, the Worker Node load balances the traffic to the different pods across the K8s cluster.
    See Packet Walk - E/W pod to pod for cross-pod communication.