Ingress Basics: One Public Entry Point for Your Kubernetes Apps

NodePort and LoadBalancer services hand out raw ports or IPs per app, which gets messy fast when you run several applications. Ingress solves this by giving you a single public entry point that routes requests to different services based on the hostname and URL path. On k3s, the Traefik ingress controller is installed by default, so the Ingress API works out of the box.

Think of Ingress as a reverse proxy with rules: it accepts traffic on ports 80 and 443, reads each request, and forwards it to the right Kubernetes Service based on the host and path.

The Ingress resource

An Ingress object declares routing rules declaratively. You do not configure the proxy directly; you describe what should happen and the controller makes it real.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

This routes app.example.com/api to the api Service and everything else on that host to the web Service.

Path and host routing

Ingress matches on both host and path. Exact matching (pathType: Exact) matches only an identical path. Prefix matching (pathType: Prefix) matches by path prefix segments, which is the most common choice for splitting a domain across services.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-host
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 80
    - host: admin.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: admin
                port:
                  number: 80

Verifying your Ingress

Applying an Ingress is trivial; pointing DNS and confirming it worked is where the details live.

kubectl apply -f ingress.yaml
kubectl get ingress
kubectl describe ingress web-ingress
curl -H "Host: app.example.com" http://NODE_IP/api/health

How traffic flows with Ingress

TLS and the basics

With a real domain you would point a CNAME or A record at your node, then add a TLS block to the Ingress so Traefik terminates HTTPS with an automatic Let's Encrypt certificate. On a host without a public DNS name, skip TLS and test over HTTP first.

Takeaway

Ingress gives many apps one stable entry point, routing by host and path to different Services — no per-app ports. It is the clean way to expose several workloads on a single node. To try it, deploy two Services on a small Netbay VPS running k3s, write an Ingress, and watch Traefik take over routing for you — netbayhosts.in.