What makes the ngrok Kubernetes Ingress Controller different?
The Ingress API has long provided Kubernetes users the ability to get external HTTP(s) traffic into their cluster. With a variety of Ingress Controller implementations, there are plenty of options to solve nearly any use case. In this blog post, we are going to look at some of the key differentiators of the ngrok Ingress Controller and why it might be right for you.
One of my favorite features, and a key differentiator, of the ngrok Ingress Controller is that it works seamlessly behind Network Address Translation (NAT). With most other Ingress Controllers, you must have a public IP address attached to a load balancer or edge router to get ingress into your cluster. With the ngrok Ingress Controller, an outbound connection is made from the controller to ngrok’s global network, allowing traffic into the cluster. Because that traffic is routed through the ngrok platform, you can ingress traffic into any Kubernetes cluster, whether it’s in a public cloud, private data center, or even running on your laptop
A common setup for fully automating the creation of Ingresses involves running an ingress controller, cert-manager (with an ACME Issuer such as Let’s Encrypt, for example), and ExternalDNS. Let’s dive into this flow to get a good idea of how these three pieces work together to fully automate HTTPS ingress traffic:
