Difficulty: beginner
Estimated Time: 10-15 minutes

Traditionally, you would create a LoadBalancer service for each public system you want to expose. This can get rather expensive, very quickly. Ingress gives you a way to route requests to services based on the request host or path, centralizing a number of services into a single entrypoint (or in this case, load balancer).

Ingress Resources

Ingress is split up into two main pieces. The first is an Ingress resource, which defines how you want requests routed to the backing services.

For example, a definition that defines an Ingress to handle requests for www.mysite.com and forums.mysite.com and routes them to the Kubernetes services named website and forums respectively would look like:

apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: my-ingress
  spec:
    rules:
    - host: www.mysite.com
      http:
        paths:
        - backend:
            serviceName: website
            servicePort: 80
    - host: forums.mysite.com
      http:
        paths:
        - path:
          backend:
            serviceName: forums
            servicePort: 80
  

ingress-overview

Congratulations. You've finished this chapter. Feel free to move onto the next scenario.

Don’t stop now! The next scenario will only take about 10 minutes to complete.

Manage Ingress

Ingress Controllers

Here is where things seem to get confusing, though. Ingress on its own doesn't really do anything. You need something to listen to the Kubernetes API for Ingress resources and then handle requests that match them. This is where the second piece to the puzzle comes in — the Ingress Controller.

Ingress Controllers can technically be any system capable of reverse proxying, but the most common is Nginx. A full example Nginx Ingress Controller (and LoadBalancer service) is as follows. Please note that if you are not on a provider that supports LoadBalancer services (ie. bare-metal), you can create a NodePort Service instead and point to your nodes with an alternative solution that fills that role — a reverse proxy capable of routing requests to the exposed NodePort for the Ingress Controller on each of your nodes.

Creating the Controller

First, inspect the file:

cat ing-controller.yaml; echo

Now create it:

kubectl create -f ing-controller.yaml

This is essentially an Nginx image that monitors Ingress resources for requested routes to serve. One callout you may have noticed is that it specifies a --default-backend-service as a startup argument, passing in nginx-default-backend. This is wanting a service that can simply handle returning a 404 response for requests that the Ingress Controller is unable to match to an Ingress rule. Let’s create that as well with the specified name:

kubectl create -f ing-backend.yaml

I said Ingress is made up of two main components and we introduced three new things. This is because the default backend isn’t really a piece of Ingress itself, but rather is something that the Nginx Ingress Controller requires. Other Ingress Controllers won’t necessarily have this component.

Wiring it Up

Assuming you’ve created the Ingress Controller above with the dependent default backend, your Ingress resources should be handled by the LoadBalancer created with the Ingress Controller service. Of course, you would need services named website and forums to route to in the above example.

As a quick test, you can deploy the following instead.

kubectl create -f demo-ing.yaml

To test things out, you need to get your Ingress Controller entrypoint.

For LoadBalancer services that will be:

kubectl get service ingress-nginx -o wide

For NodePort services, you can find the exposed port with:

kubectl describe service ingress-nginx