Kubernetes Networking and Load Balancing with Nutanix
Kubernetes networking on Nutanix is two layers: AHV's virtual network and the Kubernetes stack NKP installs on top. The exam checks that you can trace a packet from pod to Service IP and know who assigns each address.
AHV layer
- VLAN-backed subnets on the virtual switch; AHV IPAM can allocate addresses for VMs and NKP nodes.
- Flow Virtual Networking adds overlay VPCs when you need isolation without new VLANs.
- Flow Network Security enforces microsegmentation at the vNIC; it is not Kubernetes NetworkPolicy.
Kubernetes layer
- Calico provides pod networking and NetworkPolicy; the pod CIDR must not overlap AHV subnets or VPN ranges.
- ClusterIP is virtual; kube-proxy programs the data path on each node.
- Service type LoadBalancer needs an implementation. On AHV there is no built-in cloud load balancer, so NKP deploys MetalLB. L2 mode announces an address pool with ARP from a speaker node - the pool must sit in the node subnet. BGP mode peers with the upstream router and scales better for large pools.
- Ingress controllers (NGINX, Contour) are exposed through that same LoadBalancer Service.
Worked example
A Service of type LoadBalancer stays <pending> and users cannot reach the app. Check in order: is MetalLB running and is a pool configured; does the pool have free addresses; in L2 mode, is the pool inside the node subnet so ARP resolves; is a NetworkPolicy or Flow Security policy dropping traffic. The pending state itself points at address assignment, not the application.
Traps
Expecting AHV to hand out LoadBalancer IPs natively; using an L2 pool outside the node subnet; forgetting BGP peering; treating Flow Network Security as NetworkPolicy; overlapping pod CIDRs with networks reached over an NC2 VPN.