Setting Up an Ingress Controller: A Practical Kubernetes Guide

Previously in this course, we explored the theory behind Introduction to Ingress: Kubernetes Routing Explained, where we discussed why Ingress is superior to NodePort or LoadBalancer for complex routing needs. Now that you understand what an Ingress is, we are going to install the most common implementation: the Nginx Ingress Controller.

Think of the Ingress Controller as a specialized traffic cop. While a Service helps your pods talk to each other inside the cluster, the Ingress Controller sits at the edge, inspecting incoming HTTP/HTTPS requests and deciding which service should handle them.

Why You Need an Ingress Controller

Without an Ingress Controller, your cluster has no "brain" to process routing rules. You might have ten different microservices, but you only want one public IP address. The Ingress Controller reads your Ingress resources (which we will define in the next lesson) and translates them into configuration for an Nginx reverse proxy.

It acts as the entrypoint for all your cluster's web traffic. Before you can define path-based routing or SSL termination, the controller must be running.

Installing the Nginx Ingress Controller

The most reliable way to install the standard Nginx Ingress Controller is via the official Helm repository. If you haven't used Helm yet, don't worry—for now, we will use the manifest-based installation provided by the community to ensure you understand the components being created.

1. Create the Namespace: It is best practice to isolate your ingress infrastructure.

   Bash
   kubectl create namespace ingress-nginx
   

2. Apply the Controller Manifest: We will use the community-maintained deployment manifest.

   Bash
   kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/cloud/deploy.yaml
   

Verifying the Installation

After applying the manifest, Kubernetes will start pulling images and creating resources. You need to verify that everything is healthy before moving forward.

First, check that the pods are running in the ingress-nginx namespace:

Bash
kubectl get pods -n ingress-nginx

You should see a controller pod (prefixed with ingress-nginx-controller-) in the Running state. If it says ContainerCreating or ImagePullBackOff, wait a few seconds and run the command again.

Next, check the service to see if it has been assigned an external address:

Bash
kubectl get svc -n ingress-nginx

If you are using a cloud-managed cluster (like EKS, GKE, or AKS), the EXTERNAL-IP field will eventually populate with a public load balancer address. If you are on a local cluster (like Minikube or Kind), it might stay as <pending> or show localhost, which is expected behavior for local development.

Hands-on Exercise

To confirm your Ingress Controller is ready to receive traffic:

1. Use kubectl get pods -n ingress-nginx to confirm the controller is Ready.
2. Inspect the logs of the controller to see it starting up:

   Bash
   kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx
   

3. If you see lines like controller.go:176] "Configuration changes detected", your controller is live and waiting for instructions.

Common Pitfalls

• Namespace Mismatch: Beginners often apply the manifest but forget to check the ingress-nginx namespace, looking in default instead. Always include the -n ingress-nginx flag.
• Controller Conflicts: Trying to run two different Ingress controllers (e.g., Traefik and Nginx) on the same cluster without configuring "ingress classes" will cause routing chaos. Stick to one for this course.
• Resource Constraints: In small, local clusters, the Nginx controller can sometimes be heavy. Ensure your node has enough CPU/Memory if the pod stays in Pending state.

FAQ

Does the Ingress Controller replace the Service? No. The Ingress Controller routes traffic to a Service (usually a ClusterIP service), which then directs traffic to the individual Pods. It is an additional layer of abstraction.

Can I use an Ingress Controller for non-HTTP traffic? Generally, Ingress is designed for L7 (HTTP/HTTPS) traffic. For TCP or UDP traffic, you would typically use a LoadBalancer service or a more advanced Gateway API configuration, as discussed in Kubernetes Ingress: NGINX vs Gateway API for Traffic Routing.

Is Nginx the only option? Not at all. While Nginx is the industry standard for beginners, options like HAProxy, Traefik, or Istio are common in production environments depending on your requirements for observability and security.

Recap

We have successfully transitioned from manual pod networking to a managed traffic entrypoint. By installing the Nginx Ingress Controller, you have laid the foundation for professional traffic management, enabling you to host multiple applications behind a single entrypoint.

Up next: Defining Ingress Rules — we will write the YAML manifests to tell your controller exactly how to route traffic to your specific web applications.