This is a follow-up to Resolving Kubernetes Services from Host when using kind. In the previous post we modified the host’s DNS configuration (/etc/resolv.conf) and the host’s IP routes to communicate to the kind cluster from our host. There are scenarios where modifying the host environment isn’t ideal, such as running integration tests on a local development laptop.
One of the first mysteries I encountered with Docker and Kubernetes was seeing IP addresses created for containers and pods. And thinking how did these IP addresses enable binding a port number already used by another process? Turns out this is handled by Linux’s network namespaces and virtual interfaces.
In previous posts we covered creating smaller commits and splitting an existing commit. In practice there are cases where it is helpful to modify an existing commit. This can range from wanting to improve a commit message to adding additional code changes like fixes or tests.
kind is one of my favorite tools for local development and testing of Kubernetes. While there are plenty of advantages to kind such as every node is a Docker container making it easy to setup and tear down clusters, there are some bumps to get over.
kpt is one of the newest tools focused on packaging Kubernetes resources and leveraging GitOps to manage Kubernetes clusters. kpt tries to leverage the strengths of the existing Helm and kustomize communities, while enabling better management around upgrading Kubernetes resource documents retrieved from external sources using Git.