Introduction

Running ingress on Amazon EKS is straightforward in a demo cluster and surprisingly fragile in a real multi-node environment. You are not only deploying a controller; you are connecting Kubernetes service discovery, AWS load balancer provisioning, node placement, and health checks into one path. A reliable setup comes from making each layer explicit instead of hoping the defaults line up.

Install the Controller With Intentional Defaults

The NGINX Ingress Controller is commonly installed with Helm. In a multi-node cluster, the first thing to decide is replica count. A single controller pod means node failure can take all ingress routing down even if your workloads are healthy.

1helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
2helm repo update
3
4helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
5  --namespace ingress-nginx \
6  --create-namespace \
7  --set controller.replicaCount=2 \
8  --set controller.service.type=LoadBalancer

That command asks Kubernetes to create the controller deployment and a LoadBalancer service in front of it. In EKS, that service is the bridge into AWS infrastructure.

Make AWS Networking Match the Kubernetes Plan

If the load balancer never appears, the problem is usually outside the ingress manifest. EKS needs correctly tagged subnets, security groups that allow traffic, and node reachability that matches the load balancer type you requested. It is worth validating those prerequisites before you debug the controller itself.

When you need specific AWS behavior, add service annotations deliberately instead of relying on implicit provider choices.

1controller:
2  service:
3    annotations:
4      service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
5      service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"

An internal service can use a private scheme instead. The important thing is that the annotation set reflects the actual network exposure you want, not a leftover example from another cluster.

Spread Controller Pods Across Nodes

Multiple replicas only help if the scheduler places them sensibly. In production, you usually want anti-affinity or topology spread constraints so a single node problem does not take out every ingress controller replica.

1controller:
2  replicaCount: 2
3  podAntiAffinity:
4    preferredDuringSchedulingIgnoredDuringExecution:
5      - weight: 100
6        podAffinityTerm:
7          topologyKey: kubernetes.io/hostname
8          labelSelector:
9            matchExpressions:
10              - key: app.kubernetes.io/component
11                operator: In
12                values:
13                  - controller

Pair that with a PodDisruptionBudget so voluntary disruptions, such as upgrades or node drains, do not evict all replicas at once. Resource requests also matter because overloaded ingress pods tend to fail in noisy, intermittent ways that are painful to trace.

Wire an Ingress Resource to a Real Service

Once the controller is stable, expose an application through a normal Kubernetes service and ingress object.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: demo-ingress
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: demo.example.com
9      http:
10        paths:
11          - path: /
12            pathType: Prefix
13            backend:
14              service:
15                name: demo-service
16                port:
17                  number: 80

This part is often where people discover that the ingress class name does not match the controller, or that the backend service points to the wrong port. Keep the path from DNS to service port easy to trace on paper. If you cannot explain the route clearly, troubleshooting will be much slower later.

Operate the Ingress Layer Like Shared Infrastructure

Ingress is a platform component, not a one-time install. Monitor controller pod readiness, request error rates, target health, certificate expiration, and latency. During incidents, debug in layers: first the LoadBalancer service, then controller logs, then the ingress resource, then the backend service and pods.

TLS and request policy also belong here. Rate limits, body size limits, header behavior, and timeouts should be version-controlled and reviewed. If those settings are tuned ad hoc in production, the cluster tends to collect inconsistent behavior across teams.

Common Pitfalls

The most frequent failure is assuming that a LoadBalancer service guarantees a reachable AWS load balancer. Missing subnet tags and security group rules break that assumption quickly. Single-replica controllers are another common mistake in multi-node clusters, as are missing anti-affinity rules, wrong ingress class names, and health checks that do not reflect real application readiness.

Summary

• Install ingress-nginx with an explicit replica count and service type.
• Verify AWS subnet tagging, security groups, and exposure mode before debugging Kubernetes objects.
• Spread controller replicas across nodes and protect them during disruption events.
• Keep ingress class, backend service, and DNS mapping consistent and easy to trace.
• Monitor ingress as shared production infrastructure, not as a one-time deployment.