Ingress

Mechanizm Kubernetes zarządzający dostępem z zewnątrz do usług w klastrze, najczęściej przez HTTP/HTTPS. Pozwala kierować ruch i równoważyć obciążenie.

Ingress to obiekt w Kubernetes, który opisuje reguły dostępu z zewnątrz do usług działających wewnątrz klastra — zwykle dla ruchu HTTP i HTTPS. Mówiąc po ludzku: to brama i drogowskaz w jednym. Zamiast wystawiać każdą usługę osobno na świat, definiujesz jeden zestaw reguł typu „ruch na sklep.example.com/api idzie do serwisu api, a wszystko inne do frontend„. Sam obiekt Ingress to tylko deklaracja — nic nie robi, dopóki w klastrze nie działa Ingress Controller, który te reguły faktycznie realizuje.

Jak to działa i do czego służy

Ingress operuje na warstwie 7 (HTTP), więc potrafi rzeczy, których nie zrobi zwykły Service typu LoadBalancer: routing po nazwie hosta (name-based virtual hosting), routing po ścieżce URL, terminację TLS (rozszyfrowanie HTTPS w jednym miejscu) i podstawowe równoważenie obciążenia między podami. Dzięki temu jeden publiczny adres IP obsługuje dziesiątki usług, zamiast płacić za osobny load balancer dla każdej.

Kluczowe rozróżnienie: Ingress to przepis, a Ingress Controller to kucharz. Controller to pod działający w klastrze (np. oparty o NGINX, Traefik czy HAProxy), który obserwuje obiekty Ingress przez API Kubernetes i przekłada je na realną konfigurację swojego proxy. Bez zainstalowanego controllera twój Ingress będzie sobie wisiał w klastrze i kompletnie nic się nie wydarzy — to klasyczna pułapka pierwszego dnia.

Przykład z praktyki

Najpopularniejszy wybór to ingress-nginx. Instalujesz controller (np. Helmem), a potem opisujesz reguły. Minimalny manifest kierujący ruch z domeny na serwis:

  • kubectl apply -f ingress.yaml — wgrywa regułę do klastra
  • w manifeście: spec.rules[0].host: app.example.com oraz backend.service.name: app-svc i port.number: 80
  • kubectl get ingress — sprawdzasz, czy controller przypisał adres w kolumnie ADDRESS

Do automatycznego TLS dorzucasz zwykle cert-manager, który wystawia i odnawia certyfikaty Let’s Encrypt na podstawie adnotacji w Ingressie. Konfiguracja zachowań controllera (przekierowania, limity, rewrite ścieżek) idzie przez adnotacje, np. nginx.ingress.kubernetes.io/rewrite-target.

Częste błędy i na co uważać

Po pierwsze: brak controllera (opisany wyżej). Po drugie: pominięcie ingressClassName w klastrze z kilkoma controllerami — wtedy żaden albo zły controller obsłuży regułę. Po trzecie: ludzie mylą Ingress z load balancerem L4 — Ingress to L7, do TCP/UDP innych niż HTTP się nie nadaje (od tego są inne mechanizmy). Warto też wiedzieć, że klasyczny Ingress API zaczyna ustępować miejsca nowszemu, bardziej elastycznemu Gateway API — ale Ingress wciąż jest wszędzie i nie zniknie z dnia na dzień.

Pojęcia powiązane: Ingress Controller, Service, LoadBalancer, NodePort, cert-manager, TLS termination, Gateway API, reverse proxy.