Courses Kubernetes fundamentalsConnecting your app

Ingress: one front door

HTTP routing for the web.

Beginner10 min · lesson 19 of 24

In plain terms

An Ingress is the building’s receptionist for web visitors: one street address, and they send each guest to the right office based on who they asked for.

When you have several web apps to expose to the internet, you do not want a separate public load balancer for each — you want one front door that routes visitors to the right app by their web address. That is Ingress: HTTP routing and TLS for the web, sitting in front of your internal Services.

One front door for the web

An Ingress is a set of routing rules for HTTP/HTTPS traffic: "requests for shop.example.com go to the shop Service, requests for the /api path go to the api Service", plus the TLS certificates for HTTPS. It lets one public entry point serve many internal Services, routing by hostname and path — so instead of exposing each app with its own LoadBalancer, you keep the apps as internal ClusterIP Services and put a single Ingress in front. This consolidates external access (one entry point, not many), centralizes HTTPS (the certificates live in one place), and gives you web-style routing that a plain Service cannot do. It is exactly the "one front door" you want for a set of websites or APIs.

Ingress routes to internal Services

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: site }
spec:
  tls: [{ hosts: [shop.example.com], secretName: shop-tls }]   # HTTPS
  rules:
    - host: shop.example.com
      http:
        paths:
          - { path: /api, pathType: Prefix, backend: { service: { name: api, port: { number: 80 } } } }
          - { path: /,    pathType: Prefix, backend: { service: { name: shop, port: { number: 80 } } } }
# One public entry point → routed to internal ClusterIP Services by host/path.

The one catch for beginners

There is a single gotcha that trips up almost everyone the first time: an Ingress is only a set of rules — it does nothing by itself. For the rules to actually route traffic, the cluster must have an Ingress controller running (nginx, Traefik, and others are common choices), which is the piece that reads your Ingress rules and does the real work of accepting connections and forwarding them. On managed clouds you often install one, or the platform provides it. So if you create an Ingress and nothing happens — no address, no routing — the usual reason is that there is no Ingress controller installed to act on it. Once a controller is present, the Ingress gives you clean, consolidated web access: one place for your domains, paths, and TLS, fronting as many internal Services as you like. For fundamentals, the mental model is complete: internal apps are ClusterIP Services found by name; to put web apps on the internet, define Ingress rules and make sure an Ingress controller is running to enforce them. (There is a newer, more capable successor called the Gateway API you may hear about, but Ingress remains the common, approachable starting point.)

Ingress: one entry point for web apps

Ingress routes web traffic by host/path to internal Services through one front door, with TLS — but it needs an Ingress controller running to actually work.

An Ingress does nothing without an Ingress controller

Creating an Ingress only writes routing rules — something must enforce them. If no Ingress controller (nginx, Traefik, etc.) is installed, your rules are inert: no address, no routing, and the app seems unreachable. When an Ingress "does nothing", the usual cause is a missing controller — install one (or use your platform’s) so the rules take effect.

Finding things by nameVolumes: keeping files around