What Is Ingress in Kubernetes

Getting traffic into a cluster

Pods inside Kubernetes have ephemeral IPs and come and go. Services give them stable virtual addresses, but by default those are only reachable *inside* the cluster. The question every real deployment hits: how does an external user's HTTPS request actually reach my app?

Kubernetes gives you a few options, and Ingress is the one designed for HTTP(S) routing at scale.

The options, briefly

The pain Ingress solves: with LoadBalancer, every service you expose spins up its own cloud load balancer. Ten services, ten load balancers, ten bills, ten IPs. Ingress lets a *single* entry point route to many services by host and path.

Ingress = a rules object + a controller

This trips people up: an Ingress resource is just a set of routing rules — a YAML object. By itself it does nothing. You also need an Ingress controller — the actual proxy that reads those rules and routes traffic. Kubernetes ships the API but not a controller; you install one (NGINX Ingress, Kong, Traefik, HAProxy, or a cloud-native controller).

The flow:

1. 1You install an Ingress controller. It runs as pods and is itself exposed via a single LoadBalancer (one external IP for everything).
2. 2You create Ingress resources describing host/path → service mappings.
3. 3The controller watches those resources and reconfigures its proxy to match.
4. 4External traffic hits the controller's IP, which routes by the rules.

An Ingress resource

Route by hostname and path to different backend services, with TLS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts: [app.example.com]
      secretName: app-tls   # cert stored here
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80

Requests to app.example.com/api/* go to api-service; everything else goes to frontend-service. One IP, one cert, multiple backends.

What Ingress controllers commonly add

The bare Ingress spec covers host/path routing and TLS. Real controllers extend it (via annotations or CRDs) with:

• TLS termination and automatic certificates (with cert-manager + Let's Encrypt).
• Path rewrites and redirects.
• Rate limiting and basic auth.
• Load balancing strategies and session affinity.
• Canary / weighted routing for progressive rollouts.

At that point a sufficiently-configured Ingress controller starts looking like an API gateway — because the line between them is a spectrum, not a wall.

TLS and certificates

The usual pattern is cert-manager automating Let's Encrypt: you annotate the Ingress, cert-manager solves the ACME challenge, obtains a certificate, stores it in a Secret, and the controller terminates TLS with it — renewing automatically. This is how "automatic SSL" works on most Kubernetes platforms.

Ingress vs the newer Gateway API

Ingress has known limitations: it's HTTP-centric, and advanced features live in non-portable controller-specific annotations. The Kubernetes community's answer is the Gateway API — a newer, more expressive, role-oriented standard.

Gateway API splits responsibilities: a platform team owns the Gateway (the infrastructure), and app teams own HTTPRoutes (their routing). It's where Kubernetes networking is heading, but Ingress remains everywhere and works well.

How a platform handles this for you

Most developers don't want to write Ingress YAML, install cert-manager, and debug annotations. On PandaStack, that layer is managed: apps on multi-region GKE sit behind Kong ingress, with Cloudflare for DNS at the edge. You attach a custom domain and get automatic SSL, routing, DDoS protection, and a firewall — without authoring an Ingress resource yourself. Under the hood it's exactly the model above (controller + routing rules + automated certs), abstracted into a dashboard action.

Troubleshooting tips

• 404 from the controller? Check ingressClassName matches your installed controller, and the path/host rules.
• TLS not working? Verify the Secret named in tls.secretName exists and contains a valid cert; check cert-manager events.
• Service unreachable? Confirm the backend Service name/port are correct and its pods are Ready.
• Multiple controllers? Make sure each Ingress targets the right class, or rules will be ignored or doubled.

References

• [Kubernetes Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/)
• [Kubernetes Ingress controllers list](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)
• [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/)
• [cert-manager documentation](https://cert-manager.io/docs/)
• [Kong Ingress Controller docs](https://docs.konghq.com/kubernetes-ingress-controller/)

---

Don't want to hand-write Ingress and wrangle certificates? PandaStack fronts your apps with Kong ingress and gives you custom domains with automatic SSL out of the box. Deploy free at [dashboard.pandastack.io](https://dashboard.pandastack.io).