Skip to content
Optimal Lab

DevOps · interactive

Services and Ingress

Pods come and go with new IPs. A Service gives a stable name and load-balances to whichever pods match its label selector and are ready. An Ingress maps hostnames and paths from outside to Services.

Ingress rules

  • shop.example.com/api → api
  • shop.example.com/ → web

Services

  • api · selector app=api
    endpoints: 3
  • web · selector app=web
    endpoints: 2

Pods

  • api-7f9-a app=api
  • api-7f9-b app=api
  • api-7f9-c app=api
  • web-5c2-a app=web
  • web-5c2-b app=web

Requests

  • shop.example.com/api/orders200 api-7f9-a
  • shop.example.com/api/cart200 api-7f9-b
  • shop.example.com/200 web-5c2-a
  • shop.example.com/api/orders200 api-7f9-c
  • admin.example.com/404

Each path maps to a Service; the Service round-robins across its ready pods. The unknown host gets a 404 from the Ingress.

Cluster state

Step 1 of 4

  1. 1

    Pods are disposable

    They get new names and IPs whenever they restart or scale. Nothing should talk to a pod IP directly.

    Deployments create and replace them.

  2. 2

    A Service selects pods by label

    It gets a stable virtual IP and DNS name (api.default.svc). Its endpoints are the ready pods whose labels match.

    kubectl get endpoints api

  3. 3

    Ingress routes HTTP by host and path

    One load balancer, many services. An Ingress controller (nginx, Traefik, a cloud LB) implements the rules and terminates TLS.

    Gateway API is the newer, richer version.

  4. 4

    Work inward

    404 means no Ingress rule; 503 usually means no endpoints, so check the selector and readiness; then logs.

    Labels are the glue; typos are silent.

In production

Tools and technologies

Every Kubernetes app is reached through Services and an Ingress or Gateway.

Not tied to one language — use these names when you search docs or design a system.