A Hands-on Kubernetes Network Troubleshooting Journey

While developing the Kata/remote-hypervisor (aka peer-pods) approach, I encountered an issue where the Kubernetes pod IP was unreachable from the worker node. In this blog, I describe the Kubernetes network troubleshooting journey, believing it’ll be helpful to my readers. <blockquote> Kata remote hypervisor (peer-pods) approach enables the creation of Kata VMs in any infrastructure environment by utilising the environment’s native infrastructure management APIs, such as AWS or Microsoft Azure APIs, when creating Kata VMs on AWS or Azure respectively. The <a href="https://github.com/confidential-containers/cloud-api-adaptor" rel="noopener ugc nofollow" target="_blank">cloud-api-adaptor</a> sub-project of the CNCF <a href="https://github.com/confidential-containers" rel="noopener ugc nofollow" target="_blank">confidential containers</a> project implements the Kata remote hypervisor. </blockquote> As shown in the diagram below, in the peer-pods approach, the pod (Kata) VM runs external to the Kubernetes (K8s) worker node, and the pod IP is reachable from the worker node using a VXLAN tunnel. Using a tunnel ensures that the pod networking continues to work as-is without any changes to the CNI networking. <a href="https://pradiptabanerjee.medium.com/a-hands-on-kubernetes-network-troubleshooting-journey-c2b051ce6761">Click Here</a>