Enabling Ingress Controllers

Why ingress controllers are required?#

We need a mechanism that will accept requests on pre-defined ports (e.g., 80 and 443) and forward them to Kubernetes Services. It should be able to distinguish requests based on paths and domains as well as to be able to perform SSL offloading.

Kubernetes itself does not have a ready-to-go solution for this. Unlike other types of Controllers that are typically part of the kube-controller-manager binary, Ingress Controller needs to be installed separately. Instead of a Controller, kube-controller-manager offers Ingress resource that other third-party solutions can utilize to provide requests forwarding and SSL features. In other words, Kubernetes only provides an API, and we need to set up a Controller that will use it.

Fortunately, the community already built a myriad of Ingress Controllers. We won’t evaluate all of the available options since that would require a lot of space, and it would mostly depend on your needs and your hosting vendor.

Enabling ingress on k3d#

Enable Ingress on k3d using the following command.

The output is as follows.

ℹ️ In the rest of the lessons of this chapter the code playgrounds are preconfigured with the Ingress controller. However, it is suggested to please verify if the Ingress controller is running before using the service.

Playing Around with the Controller#

Now that the Ingress addon is enabled, we’ll check whether it is running inside our cluster.

Ignore the -n argument. We did not yet explore Namespaces. For now, please note that the output of the command should show that nginx-ingress-controller-... Pod is running.

If the output is empty, you might need to wait for a few moments until the containers are pulled, and re-execute the kubectl get all --namespace ingress-nginx command again.

ℹ️ The ingress image is based on NGINX Ingress Controller. It is one of the only two currently supported and maintained by the Kubernetes community. The other one is GLBC that comes with Google Compute Engine (GCE) Kubernetes hosted solution.

By default, the Ingress Controller is configured with only two endpoints.

If we’d like to check Controller’s health, we can send a request to /healthz.

The output is as follows.

It responded with the status code 200 OK, thus indicating that it is healthy and ready to serve requests. There’s not much more to it so we’ll move to the second endpoint.

The Ingress Controller has a default catch-all endpoint that is used when a request does not match any of the other criteria. Since we did not yet create any Ingress Resource, this endpoint should provide the same response to all requests except /healthz.

The output is as follows.

We got the response indicating that the requested resource could not be found.

Try it yourself#

A list of all the commands used in the lesson is given below.