Understanding Kubernetes Ingress Resources and Controllers

Ingress resources and controllers ensures that your Kubernetes cluster can be accessed by the outside world. In this guide, we’ll share everything you need to know.

Overview

  1. Ingress Controllers
  2. How to Set Up an NGINX Ingress Controller
  3. Additional Ingress Controllers
  4. Conclusion

Kubernetes is an open-source orchestration system aimed at automating deployment, scaling, and managing operations of application containers across clusters of hosts. Ingress resources and controllers in Kubernetes allow you to manage HTTP access to your cluster.

When deploying applications to Kubernetes, an important consideration is how your application will be accessed by external users. The standard solution to this problem is an Ingress. In this article, you’ll learn to use, secure, and manage Ingress resources and controllers in Kubernetes.

What is an Ingress?

Ingress provides externally available URLs, performs load balancing, terminates SSL/TLS, and offers name-based virtual hosting.

Here’s an example of an Ingress configuration file:

  • Host is specified as localhost, so the rule applies to the host.
    If a host is not specified, then all inbound HTTP traffic goes through the IP address.
  • Path can consist of multiple rules; in the example above, the path rule points to a Service within the Backend definition.
  • Backend is a combination of Service and port, as seen above.

An Ingress controller is needed to satisfy the Ingress you created, as it handles all routing logic.

Ingress Controllers

A controller uses Ingress Rules to handle traffic to and from outside the cluster.

There are many Ingress controllers (and I’ll cover some of them later in this post). Any tool capable of reverse proxying traffic should work, so you can even build your own if you’re so inclined.

As seen in the diagram above, this article focuses on NGINX Ingress controllers as NGINX-based controllers seem to be the most common. NGINX is a general-purpose implementation compatible with most Kubernetes deployments, but I’ll add more details about alternative Ingress controllers at the end of this article.

How to Set Up an NGINX Ingress Controller

Setting up an NGINX Ingress Controller

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.27.0/deploy/static/mandatory.yaml

This deploys a pod for your Ingress controller, and you can run the following to see this pod:

kubectl get pods -A | grep ingress

This shows that your Ingress controller is running, and you can proceed to use it for a sample application.

Deploying a Sample Application

kubectl run myapp --image=nginx

This creates a pod called myapp with nginx as the container image. Next, you need to connect your demo application to your Ingress controller so that traffic is properly routed to the pod.

Accessing the Application

To create a NodePort Service for your application, run the following command:

kubectl expose pod myapp --port=80 — name myapp-service — type=NodePort

Then you can view the Service’s details by running the following:

kubectl get svc | grep myapp-service

This summary tells you that your new demo application is routing port 80 (NGINX’s default port) to your host machine’s port 32017. To confirm that the application is accessible, visit or use curl to view http://localhost:32017.

At this point, you have an application running and an Ingress controller running, but the two aren’t connected. This allows you to access the application locally, but in a production environment, you don’t want users accessing endpoints using the cluster’s IP address. To provide secure access to external users, you’ll need to set up a custom domain and connect your Ingress controller to your Service.

Adding a Custom Domain

To avoid purchasing and configuring a real domain for this demonstration, you can add your desired domain (my-app.com in this case) to your local /etc/hosts file. To do this from the terminal, run the following command using your ClusterIP and domain of choice:

echo ‘[ClusterIP] my-app.com’ | sudo tee -a /etc/hosts

If you don’t remember your ClusterIP from above, you can get it by running the following:

kubectl describe svc/myapp-service | grep IP: | awk ‘{print $2;}’

Be sure to replace [ClusterIP] with your Cluster IP from the service.

Next, update your Ingress file (ingress.yaml) with a host (my-app.com) and annotation as shown here:

This configuration proxies all requests from my-app.com to the service, which is serving the NGINX application.

Next, apply the configuration using the following command:

kubectl apply -f ingress.yaml

To verify that the Ingress was created and now points to your custom domain, run the following:

kubectl get ingress

Visit the domain in your browser or using curl to verify it works:

Now you have an Ingress controller routing traffic from the domain to your application, but there is more you can do to prepare your application for production use. You can add an SSL certificate, whitelist access to specific external IPs, and try different Ingress controllers besides NGINX.

Additional Ingress Controllers

  • Kong Ingress is built on NGINX but adds extra modules like gRPC support, authentication, and plugins that broaden its capabilities.
  • Traefik is easy to integrate with any Kubernetes environment, and it allows you to dynamically swap out or upgrade services without complete reconfiguration.
  • HAProxy, which stands for High Availability Proxy, is another open-source Ingress controller, but unlike others on this list, it’s exclusively focused on load balancing.
  • Contour is based on Envoy and developed jointly with its authors. Contour has created a special Custom Resource Definition called an IngressRoute which can help you support multi-team clusters and delegation of routes to external Namespaces.

Conclusion

Software / DevOps Engineer | Google Developer Expert for Cloud | https://timtech4u.dev