Kubernetes Ingress — Simplified · Scaleout Ninja
If you want to expose any service running inside Kubernetes there are a couple of ways of doing it, a very handy one is to have an Ingress. In this post we are going to explain ingresses, ingress controllers, ingress definitions and the interaction between them.
We are assuming there’s a basic understanding of Kubernetes and familiarity with things like pods and services. To explain this quick we will compare it with the more traditional ways of exposing websites to the internet using Apache, NGINX or any API Gateway.
Let’s start.
Ingress
Think of an ingress as the typical reverse proxy we have in standard web deployments pointing to our App running behind the firewall, aka NGINX, HAProxy, Apache, Kong, etc. In this proxy is where we configure things like /account/.* goes to the account service, or /address/.* goes to the address service, and so on.
Ingress Controller
Imagine if in one of those standard deployments we’ve had a component with an API that we can call with some configuration, it validates the config and updates the reverse proxy for us, so we don’t have to log into the server and update config files by hand, in Kubernetes-land this is the ingress controller.
