Before we talk about Ingress, we need four simple words: cluster, pod, service, and ingress. Let us meet them one by one.

So what exactly is Ingress?

Ingress is a Kubernetes object that describes how outside HTTP and HTTPS traffic should reach services inside the cluster. HTTP is the language browsers use to talk to websites. HTTPS is the same language, wrapped in encryption so nobody can read it on the way.

The word “ingress” simply means “the way in”. Its opposite, “egress”, means “the way out”. Ingress is therefore the official way in for web visitors.

An important detail: an Ingress object is only a written set of rules. It does not move a single byte of traffic by itself. Another piece, called the Ingress controller, reads those rules and does the real work. We will study both pieces in detail, because mixing them up is the number one beginner mistake.

A short history

Google released Kubernetes as open source in 2014. In the early days, exposing an application to the internet was awkward, and every team invented its own tricks. The Ingress idea arrived as an early (beta) feature in late 2015, and it became a stable, officially supported feature in Kubernetes version 1.19 in 2020.

Today there is a newer and more powerful family of objects called the Gateway API. We will meet it later. Even so, Ingress is still used in a huge number of production clusters, and understanding it makes Gateway API much easier to learn.

Kubernetes already has ways to open a door to the outside world. To see why Ingress was invented, we first need to see why those doors are not enough for web applications.

The three older doors

Kubernetes offers three main kinds of service. Each one answers the question “who is allowed to talk to my pods?” in a different way.

ClusterIP is the default. It gives the service an address that works only inside the cluster. It is perfect for private conversations between your own programs, but a visitor on the internet can never reach it.

NodePort opens the same high-numbered port on every computer in the cluster. By default the port is somewhere between 30000 and 32767. A visitor could type the computer’s address followed by that odd number. It works for quick experiments, but nobody wants a shop at an address ending in :31874.

LoadBalancer asks your cloud provider (AWS, Google Cloud, Azure) to create a real load balancer just for that one service. A load balancer is a machine or managed service that spreads incoming traffic across many servers. It gives you a clean public address, but there is a catch: one service means one load balancer.

The pain of many front doors

Imagine our shop has ten services that must be reachable from the internet. With plain LoadBalancer services you would create ten cloud load balancers. That means ten public addresses to manage, ten separate bills, and ten places where you must install and renew your HTTPS certificate.

There is also a smarter problem. A plain load balancer at the network level does not understand web addresses. It cannot say “requests for shop.example.com go here and requests for api.example.com go there”. It just forwards bytes. Web applications need a helper that can read the request and make decisions based on what it says.

flowchart TB
  subgraph WITHOUT["Without Ingress: one load balancer per service"]
    direction LR
    U1["Internet visitor"] --> LB1["Cloud Load Balancer 1"] --> S1["Shop Service"]
    U1 --> LB2["Cloud Load Balancer 2"] --> S2["Payments Service"]
    U1 --> LB3["Cloud Load Balancer 3"] --> S3["Search Service"]
  end
  subgraph WITH["With Ingress: one shared front door"]
    direction LR
    U2["Internet visitor"] --> LB4["One Cloud Load Balancer"] --> IC["Ingress Controller"]
    IC --> S4["Shop Service"]
    IC --> S5["Payments Service"]
    IC --> S6["Search Service"]
  end
    

Ingress has only a handful of building blocks. Learn these eight and everything else in this guide will feel familiar.

Understanding path types

When you write a path rule, you must also say how strictly to compare it. Kubernetes offers three path types.

When several rules could match one request, the most specific one wins. A long exact path beats a short prefix path. This is like a postal sorter who prefers a full street address over just a city name.

Let us zoom out and see every piece that sits between a visitor’s browser and your application, in the order a request meets them.

flowchart LR
  User["Browser or Mobile App"] --> DNS["DNS Record"]
  DNS --> LB["Cloud Load Balancer"]
  LB --> IC["Ingress Controller Pods"]
  ING["Ingress Resource with Rules"] --> API["Kubernetes API Server"]
  API -. "controller watches for changes" .-> IC
  IC -->|"shop.example.com"| SVC1["Shop Service"]
  IC -->|"api.example.com"| SVC2["API Service"]
  SVC1 --> P1["Shop Pods"]
  SVC2 --> P2["API Pods"]
    

Piece by piece

DNS is the internet’s phone book. It turns a friendly name like shop.example.com into a numeric address. For Ingress, that name points at the public address of your entry point, so DNS is the very first thing every visitor touches.

The cloud load balancer is the outermost door. It has a public address, accepts the connection from the visitor, and forwards it to one of the computers running the Ingress controller. In AWS this is usually a Network Load Balancer or an Application Load Balancer.

The Ingress controller pods are the reception desk. Usually you run at least two or three copies, spread over different machines, so that losing one machine does not close the front door. Each copy contains a proxy, which is a program that receives a request, decides where it should go, and passes it on.

The Kubernetes API server is the cluster’s central notice board. Every object, including your Ingress rules, is stored there. The controller keeps an eye on this notice board and reacts the moment something changes.

Services and pods are the destination. The controller either hands the request to the service, or looks up the healthy pods behind it and talks to them directly. We will see why this difference matters in the next chapter.

Where the controller lives

There are two common designs. In the first, the controller runs inside the cluster as normal pods, and a single LoadBalancer service exposes those pods to the internet. Community NGINX, Traefik and HAProxy controllers usually work this way.

In the second, the controller is only a thin translator. It reads your Ingress rules and configures a load balancer that lives outside the cluster, run by the cloud provider. The AWS Load Balancer Controller works this way: it creates an Application Load Balancer and keeps its rules in sync with your Ingress objects. In this design the actual traffic does not pass through pods you manage at all.

Here is what really happens inside the controller from the moment you save a rule to the moment a visitor is served.

The watch-and-reconcile loop

Kubernetes is built around a simple habit called the control loop. A controller compares “what the world should look like” (the desired state) with “what it looks like right now” (the actual state), and then takes small actions to close the gap. It repeats this forever.

An Ingress controller applies this habit to web routing. It subscribes to change notifications from the API server for four kinds of objects: Ingresses, Services, endpoint lists, and certificate secrets. Whenever any of them changes, it wakes up and works out what its proxy should now look like.

flowchart TD
  A["Admin saves new Ingress rules"] --> B["API Server stores the object"]
  B --> C["Controller is notified of the change"]
  C --> D["Controller builds a new proxy configuration"]
  D --> E{"Is the configuration valid?"}
  E -->|"Yes"| F["Proxy is updated without dropping connections"]
  E -->|"No"| G["Old configuration is kept and an error event is recorded"]
  F --> H["New traffic follows the new rules"]
    

Why controllers often skip the Service

A Service normally works like a small random selector: it receives a request and picks a pod. But the Service is only a pointer. The real list of healthy pod addresses lives in an object called an endpoint list (modern clusters call it EndpointSlices).

Many controllers read that list directly and send traffic straight to the pod addresses. This skips one extra hop, allows smarter balancing such as “least busy pod”, and lets the controller keep a user’s session on the same pod when that is needed. The Service is still important, because it is the name you write in your rules and the thing that keeps the pod list up to date.

Reloads without pain

In the early days, every change forced a proxy restart, and a busy cluster with constantly changing pods caused a storm of restarts. Modern controllers avoid this. When only the list of pod addresses changes, which happens all the time, many controllers update it in memory without any reload. A full reload is kept for real rule changes, such as a new host name or a new certificate.

Now let us follow one single visitor from the first click to the finished page, and then follow one Ingress object from birth to deletion.

The journey of one request

sequenceDiagram
  participant U as Visitor Browser
  participant D as DNS
  participant L as Cloud Load Balancer
  participant I as Ingress Controller
  participant S as Service
  participant P as Pod
  U->>D: Where is shop.example.com?
  D-->>U: Address of the load balancer
  U->>L: Secure request arrives
  L->>I: Traffic forwarded to a controller pod
  I->>I: Unlock TLS then match host and path
  I->>S: Send to the chosen backend
  S->>P: A healthy pod is selected
  P-->>U: Response returns along the same path
    

The whole trip usually takes a few dozen milliseconds. The controller’s share of that time is tiny, often a millisecond or less on a healthy setup. If pages feel slow, the cause is nearly always the application or the network distance, not the Ingress.

The lifecycle of an Ingress object

An Ingress object also has a life story. Knowing it helps you understand what you see when you inspect it.

Keeping connections fast

Opening a brand-new connection is slow, because the two sides must greet each other and, for HTTPS, agree on secret keys. To avoid repeating this work, the controller keeps connections open and reuses them for many requests. This is called keep-alive. It is like keeping a phone line open during a long chat instead of hanging up and redialling after every sentence.

Modern controllers also speak HTTP/2, a newer version of the web language that lets many requests share one connection at the same time. The controller can talk HTTP/2 to the visitor and a simpler version to your pods, so your applications get the speed benefit without any change.

Finally, remember that the controller is patient only up to a point. It has timeouts: how long to wait for a connection to a pod, how long to wait for the pod’s answer, and how long an idle line may stay open. If an application sometimes needs sixty seconds to generate a report, but the timeout is thirty, visitors will see an error even though the application worked. Always match timeouts to the real behaviour of each route.

Most real-world Ingress setups are built from a small set of routing patterns. Learn to recognise them and you can read almost any configuration.

Rewrites and redirects

Sometimes the address the visitor uses is not the address your application expects. Your cart program might live at the root of its own service, but the visitor types /cart. A rewrite quietly changes /cart/items into /items before the request reaches the application. A redirect is different: it tells the browser to go to another address, and the browser makes a new request.

These features are not part of the basic Ingress definition. Each controller offers them through its own settings, usually called annotations, which are small notes attached to the Ingress. That is powerful, but it also means your configuration may not move easily between controllers.

The Ingress controller is the first program to touch every request from the internet. That makes it the best place to add security, and also the most attractive place for attackers to aim.

TLS termination: unlocking the padlock in one place

TLS is the encryption used by HTTPS. A certificate is a digital passport that proves a website is really who it claims to be. It is issued by a trusted organisation called a certificate authority.

With TLS termination, the controller holds the certificate and does all the encryption work at the front door. Your applications behind it can stay simple and never handle certificates. The certificate is stored in the cluster as a special secret, and the TLS section of your Ingress names it.

There are three ways to handle encryption on the last stretch inside the cluster. Terminate and forward plain is the simplest and fastest. Terminate and re-encrypt unlocks the traffic at the door for inspection and then locks it again before sending it to the pod, which suits strict security rules. Passthrough never opens the traffic at all and lets the application handle its own encryption, but then the controller cannot read paths or add headers.

Certificates that renew themselves

Certificates expire. An expired certificate makes browsers show a scary warning page, and visitors leave. The classic story is a company whose website went down on a Sunday because someone forgot to renew a certificate.

The community solved this with a tool called cert-manager, which runs in the cluster, requests certificates from an authority such as Let’s Encrypt (a free, automated authority whose certificates traditionally last 90 days), and renews them long before they expire. On AWS, another popular choice is to keep certificates in AWS Certificate Manager and let the load balancer use them directly.

Protecting the controller itself

Because the controller can read every request and holds your certificate secrets, it is a high-value target. In March 2025 security researchers disclosed a group of serious flaws, nicknamed IngressNightmare, in the popular community NGINX controller. They showed that a weakness in the controller’s safety-check component could let an attacker take over the controller and reach secrets across the cluster. The lesson is not “avoid Ingress”. The lesson is to treat the controller like the critical building it is.

The Ingress rules are the same everywhere, but the worker you hire changes the speed, the features and the operating cost.

The AWS way

On Amazon EKS, many teams choose the AWS Load Balancer Controller. For each Ingress it creates an Application Load Balancer, which is a managed layer-7 load balancer, and keeps its listeners and rules in step with your Ingress. Amazon looks after scaling and patching of that load balancer, which removes a chunk of work from your team.

It can send traffic directly to pod addresses (“IP mode”) when the cluster uses the Amazon VPC network plugin, which removes an extra hop. It can also let several Ingress objects share one load balancer through a grouping setting, which prevents the “one load balancer per service” bill explosion we discussed in Chapter 2.

The trade-off is portability. Many of its features are configured through AWS-specific notes on the Ingress, so moving the same rules to another cloud needs some rework.

How to decide

No tool is perfect. A good engineer knows both what Ingress gives and what it costs.

The trade-offs behind the lists

Shared versus separate. Sharing one controller across all teams saves money, but one team’s heavy traffic or bad configuration can affect others. Many larger companies run separate controllers for public traffic and internal traffic, or one per team, and accept the extra cost in return for isolation.

Simple versus powerful. The standard Ingress fields are easy to learn but limited. To get more, you reach for annotations, and each annotation is a private agreement between you and one controller. Too many of them make the setup hard to read and hard to move.

In-cluster versus managed. An in-cluster proxy gives you fine control and works everywhere, but you must patch and scale it. A managed cloud load balancer removes that burden but ties you to one provider.

Where Gateway API fits

The Kubernetes community created the Gateway API to fix the limits above. It reached its first stable release in 2023. Instead of one object doing everything, it splits the work: a GatewayClass describes the type of gateway, a Gateway describes the actual entry point and who may attach to it, and route objects such as HTTPRoute describe the routing rules. This lets a platform team own the door while application teams own their own routes, and it supports more traffic types and standard ways to do things that Ingress needs annotations for.

The Ingress object is not going away suddenly. It is a stable, frozen feature, meaning it receives fixes but few new capabilities. Sensible advice for a new large platform is to learn both, use Ingress where it is already in place, and consider Gateway API for new designs.

Scaling the front door

The controller must grow with your traffic. The usual method is horizontal scaling: add more identical controller pods and let the load balancer spread visitors across them. Each pod can handle a certain number of requests and open connections per second, which depends on its processor, its memory and how much work it does per request. Encrypting traffic and running a firewall both cost extra processor time, so a controller doing more work needs more pods.

Autoscaling adds and removes pods automatically based on a measurement such as processor use or requests per second. It reacts in minutes, though, and a sudden rush can arrive in seconds. For known big events, such as a festival sale or a live sports match, experienced teams scale up in advance and ask their cloud provider to prepare the load balancer for the surge, instead of trusting autoscaling to catch up.

Also watch the pieces around the controller. A managed load balancer has its own limits, the network has its own limits, and the applications behind the door have theirs. A very fast front door is useless if all its traffic squeezes into one slow database. Capacity planning means checking every link in the chain, not only the first one.

Because every request passes through the Ingress controller, it is the best place to learn how healthy your whole system is. Watching it is like checking the pulse at the wrist: one spot tells you a lot about the entire body.

The four golden signals at the front door

Site reliability engineers at Google popularised four simple signals: latency, traffic, errors and saturation. Ingress gives you all four almost for free.

Logs and traces

An access log is a diary with one line per request: who asked, for what, how long it took and what answer was returned. Store these logs in a central place such as Amazon CloudWatch Logs, Grafana Loki or Elasticsearch, so you can search them even after a pod disappears. Structured logs, where each line has labelled fields, are far easier to search than free text.

Add a unique request identifier at the front door and pass it to every service behind it. When a customer says “my payment failed at 10:42”, you can follow that one identifier through all the small programs. Combine it with distributed tracing tools, which draw a timeline of one request across services, and the mystery of “where did the time go?” becomes a picture.

Failure scenarios worth rehearsing

Good teams practise failure before it happens. Three scenarios are worth a rehearsal. First, a controller pod dies: the load balancer should notice within seconds and stop sending it traffic, and users should see nothing. Second, a bad rule is pushed: the controller should reject it and keep the old rules, and your alerts should tell you. Third, a whole availability zone disappears: the remaining zones must have enough spare controller and application pods to carry the extra load.

Write down what should happen in each case, test it in a staging cluster, and time how long recovery takes. A runbook, which is a short step-by-step guide for an emergency, saves precious minutes when someone is tired at night. The first few lines should always say how to check DNS, the load balancer, the controller pods and the rule status, in that order.

A pattern is a proven way of solving a common problem. An anti-pattern is a habit that looks sensible at first and causes pain later.

Patterns that work

Anti-patterns to avoid

These habits come from many teams running Ingress in production. Follow them and you will avoid most of the midnight phone calls.

Common mistakes and their cures

Organisations from small start-ups to global enterprises use Ingress. The stories below are simplified illustrations of common situations, not descriptions of any one company’s private setup.