How to Test Ingress in a kind cluster

Kind is one of my favorite Kubernetes development tools. I’ve written a couple of articles on talking to internal services and pods from outside of the kind cluster: Resolving Kubernetes Services from Host when using kind Using Docker to Resolve Kubernetes Services in a kind Cluster This article tackles communication through an ingress controller running in a kind cluster.

iptables: How Kubernetes Services Direct Traffic to Pods

This is the third part of a series on Docker and Kubernetes networking. We’ll be tackling how Kubernetes’s kube-proxy component uses iptables to direct service traffic to pods randomly. We’ll focus on the ClusterIP type of Kubernetes services. The goal of this post is to implement the iptables rules needed for a service like:

setuid: Elevating Privileges

Some executables need elevated privileges, but we don’t always want to provide a user with root access. Fortunately, Linux and macOS support setuid. setuid instructs the OS to run an executable as the owner of the executable instead of the current user.

iptables: How Docker Publishes Ports

The next question to answer after writing How do Kubernetes and Docker create IP Addresses?! is “How does Docker handle publishing ports?” In the previous post, we created our own network namespaces, virtual interfaces, and assigned IP addresses to these virtual interfaces. Now we’ll learn how to make a request to 127.

Using Docker to Resolve Kubernetes Services in a kind Cluster

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.