Simplify Networking in Kubernetes using Consul and Wireguard

See how connecting an application to Vault using Consul DNS as the target endpoint is made easier with Wireguard to provide more visibility into the cluster when troubleshooting is required.

When writing Kubernetes applications, the network that those applications run on is not accessible from outside unless an ingress, service, or port forwarding is enabled. If a user was able to call cluster IP addresses and even Consul DNS names from their local network at all times, this can speed up troubleshooting networking issues without having to build and deploy a new version of the app. A user can have complete access to Consul DNS on a Kubernetes cluster and confirm whether the network is breaking or operating abnormally. Contacting an endpoint from your workstation allows for quicker resolution of network related issued in Kubernetes.

By running a Wireguard server in a Kubernetes cluster and exposing it publically, the DNS for network peers can be set to the cluster DNS which also has an entry for .consul DNS names. With this solution, every endpoint, ClusterIP, and Consul DNS address is accessible from outside the cluster. Whether you are half way accross the world, you can always have DNS resolution through Consul.

This raises an interesting thought around whether Wireguard could be adopted as a networking solution for orchestrating multi-site connectivity at scale.

I will demonstrate how connecting an application to Vault using Consul DNS as the target endpoint is made easier with Wireguard to provide more visibility into the cluster when troubleshooting is required.