Make sure you understand Kubernetes Services from Part 1:

TL;DR

Kubernetes Ingress is not a Kubernetes Service. Very simplified its just a Nginx Pod which redirects requests to other internal (ClusterIP) services. This Pod itself is made reachable through a Kubernetes Service, most commonly a LoadBalancer.

Should you even read this?

First I hope I can give you a clear and simple overview of what is behind this mysterious Kubernetes Ingress which then makes it easier for you to understand what you’re actually implementing or even if you should.

Later I show some example configuration based on the example we use throughout this article.

Why to use Ingress?

You use it to make internal services reachable from outside your cluster. It saves you precious static IPs, as you won’t need to declare multiple LoadBalancer services. Also it allows for much more configuration and easier setup as we’ll see.

What will we do here?

First we do a really short excursion into how http servers, especially Nginx, work and what they can do.

Then we’ll show how an Ingress could be setup manually, so without using the fancy Kubernetes Ingress resource at all.

Next we’ll see that Kubernetes Ingress is nothing more than a pre-configured Nginx server.

Sounds confusing? Just follow me through here.

Short dive into the world of a simple HTTP server

Here we step back into times before containers, Kubernetes and the modern world of Cloud. Stay with me, it’ll be short.

What can a (Nginx) HTTP server do?

It can receive a request over the HTTP protocol for a specific filepath, check that filepath on the attached filesystem and return it if that file exists: