Ask Sendai

Back in 2015, a revolution was under way. We were moving from manual, handcrafted infrastructures, to container-based, industrial, and human-free platforms. In those dark ages of orchestration, edge traffic was remarkably difficult to manage. On one side, we had traditional reverse-proxies that were built for static infrastructures, on the other side, we were building dynamic clusters made to deploy and manage thousands of microservices. The idea of having a simple and automatic edge router, all in one binary, was appealing, but also idealistic.

In this article, I will share my experiences with 3 major types of Kubernetes ingress solutions. Let’s go through their pros and cons and find out which one suits your needs. How does it work behind thescene? First, Let’s deploy a hello-world service with 2 Pods running in demo namespace. Next, We apply the hello-world ingress resource file as below. Let’s take a look when an Ingress resource is deployed, how does the ingress controller translate it into Nginx configuration?

Did you know there is more than one NGINX Ingress controller for Kubernetes? You do now. We help you figure out which one makes sense for you, based on their differences around authorship, development philosophy, production readiness, security, and support. Source: nginx.com