Kubernetes Ingress to zasób API, który opisuje reguły kierowania ruchu HTTP i HTTPS z internetu do usług działających wewnątrz klastra. Prawidłowo skonfigurowany kubernetes ingress zastępuje dziesiątki osobnych load balancerów jednym punktem wejścia, co potrafi obniżyć rachunek u dostawcy chmury z kilkuset do kilkudziesięciu złotych miesięcznie. Zamiast wystawiać każdą aplikację przez Service typu LoadBalancer, definiujesz reguły oparte na nazwie hosta i ścieżce URL, a kontroler tłumaczy je na konfigurację serwera proxy. Ten mechanizm obsługuje terminację TLS, przekierowania, limity zapytań, uwierzytelnianie oraz przepisywanie ścieżek. Dla zespołów utrzymujących kilkanaście mikroserwisów, sklepów i stron firmowych oznacza to jeden spójny model publikacji, jedną politykę certyfikatów i jeden zestaw metryk. W tym przewodniku przechodzimy przez architekturę, wybór kontrolera, certyfikaty, routing aplikacji oraz realne koszty utrzymania. Pokazujemy również, jak uniknąć błędów kończących się odpowiedzią 502 tuż po wdrożeniu produkcyjnym.
Jak działa Ingress i czym różni się od zwykłego Service
Ingress sam w sobie nie przetwarza żadnego pakietu, bo jest wyłącznie deklaratywnym opisem reguł. Dopiero kontroler uruchomiony jako pod w klastrze obserwuje obiekty API i przekłada je na konfigurację proxy: bloki server w NGINX, routery w Traefik lub listenery w Envoy. Cykl obserwacji i przeładowania konfiguracji trwa zwykle poniżej dwóch sekund.
Reguły opierają się na dwóch wymiarach: nazwie hosta oraz ścieżce żądania. Pole pathType decyduje, czy dopasowanie jest dokładne, czy prefiksowe, i to właśnie tam powstaje większość pomyłek konfiguracyjnych. Dodatkowo można zdefiniować backend domyślny, który przechwytuje zapytania niepasujące do żadnej reguły i zwraca kontrolowaną, zaprojektowaną stronę błędu zamiast surowego komunikatu proxy.
Obiekty Ingress żyją w przestrzeniach nazw, ale kontroler działa globalnie dla całego klastra. Pole ingressClassName rozstrzyga, który kontroler obsłuży dany zasób, co pozwala utrzymywać równolegle osobną bramę publiczną i osobną wewnętrzną. Rozdzielenie ruchu klienckiego od administracyjnego kosztuje w tym modelu znacznie mniej niż budowa dwóch niezależnych klastrów.
Ingress kontra Service typu LoadBalancer
Service typu LoadBalancer u każdego dostawcy oznacza osobny publiczny adres IP oraz osobną pozycję na fakturze, zwykle 60-120 zł miesięcznie. Dwadzieścia mikroserwisów to dwadzieścia takich pozycji, podczas gdy jedna brama obsłuży je wszystkie i doda przy okazji reguły warstwy siódmej, których czysty balanser sieciowy nigdy nie zaoferuje.
Agencje, dla których projektowanie stron internetowych jest codziennością, korzystają z tego modelu przy hostowaniu dziesiątek witryn klienckich. Każda domena to jedna reguła w manifeście, a nie osobna infrastruktura, więc uruchomienie kolejnego projektu sprowadza się do commita w repozytorium i automatycznej synchronizacji stanu klastra.
Wybór kontrolera: NGINX, Traefik, HAProxy i Envoy
Wybór kontrolera to najbardziej długofalowa decyzja w całej architekturze bramy. Projekt ingress-nginx pozostaje najpopularniejszy, ma największą bazę gotowych adnotacji i odpowiedzi na typowe problemy, a jego konfiguracja opiera się na sprawdzonym silniku NGINX. Cenę popularności stanowi rozbudowana lista adnotacji, którą trzeba realnie znać.
Traefik kusi automatycznym wykrywaniem usług, czytelnym panelem i własnymi zasobami CRD typu IngressRoute, które wyrażają skomplikowany routing bez ciągu adnotacji. HAProxy Ingress wygrywa przy bardzo dużym natężeniu ruchu i stabilnych opóźnieniach, natomiast rozwiązania oparte na Envoy, jak Contour, dają najlepsze wsparcie dla gRPC oraz HTTP/3.
Na klastrach zbudowanych z maszyn ovh vps, gdzie każdy gigabajt pamięci ma konkretną cenę, lekki kontroler zwalnia zasoby na dodatkowy pod aplikacji. Dobrze dobrany kubernetes ingress zużywa poniżej pięciu procent pamięci węzła, a różnica między najlżejszym a najcięższym wariantem wynosi w praktyce około 150 MB na replikę.
| Kontroler | Mocna strona | Typowe zużycie RAM | Kiedy wybrać |
|---|---|---|---|
| ingress-nginx | Największa baza przykładów i adnotacji | 120-250 MB | Klastry ogólnego przeznaczenia |
| Traefik | Automatyczne wykrywanie usług i panel | 80-150 MB | Małe i średnie zespoły |
| HAProxy Ingress | Niskie opóźnienia przy dużym ruchu | 100-200 MB | Serwisy powyżej 10 tys. zapytań na sekundę |
| Contour (Envoy) | Pełne wsparcie gRPC i HTTP/3 | 150-300 MB | Platformy API i mikroserwisy |
Certyfikaty TLS i bezpieczeństwo bramy wejściowej
Terminacja TLS na bramie oznacza, że certyfikaty przechowujesz w jednym miejscu, a aplikacje wewnątrz klastra komunikują się prostym protokołem HTTP. Każda reguła wskazuje sekret typu kubernetes.io/tls zawierający klucz prywatny i łańcuch certyfikatów. Jeden sekret może obsłużyć wiele hostów, jeśli certyfikat obejmuje kilka nazw alternatywnych.
Minimalna wersja protokołu powinna wynosić TLS 1.2, a zestaw szyfrów należy ograniczyć do algorytmów z gwarancją utajniania. Nagłówki HSTS, Content-Security-Policy oraz X-Content-Type-Options konfiguruje się globalnie w ConfigMap kontrolera, dzięki czemu wszystkie aplikacje dziedziczą tę samą politykę bez modyfikowania kodu poszczególnych serwisów.
Brama jest też naturalnym miejscem na ograniczenie dostępu do paneli administracyjnych. Ekran wordpress logowanie oraz ścieżki typu wp-admin warto zamknąć adnotacją ograniczającą źródłowe adresy IP do sieci biurowej i VPN. Limit zapytań na poziomie dziesięciu prób na minutę skutecznie eliminuje automatyczne ataki słownikowe na hasła redaktorów.
Automatyzacja certyfikatów przez cert-manager
Ręczne odnawianie certyfikatów kończy się awarią w najmniej odpowiednim momencie. Cert-manager instaluje się jednym poleceniem Helm, definiuje wystawcę ACME i od tej chwili sam wystawia oraz odnawia certyfikaty na trzydzieści dni przed wygaśnięciem, reagując na adnotację umieszczoną bezpośrednio w manifeście reguły routingu.
Przy dużej liczbie domen rozsądniejszy bywa certyfikat wildcard weryfikowany metodą DNS-01, ponieważ omija limity liczby żądań u wystawcy. Koszt takiego rozwiązania to zero złotych przy Let us Encrypt, a alternatywa komercyjna zaczyna się od około 300 zł rocznie za pojedynczą domenę z subdomenami.
Routing sklepów, stron firmowych i API w jednym klastrze
Typowy klaster produkcyjny obsługuje równolegle sklep, blog, panel klienta oraz kilka usług API. Brama rozdziela je po nazwie hosta, a wewnątrz jednej domeny po prefiksie ścieżki, kierując zapytania z prefiksu api do innej usługi niż ruch przeglądarkowy. Taki podział pozwala skalować sklep niezależnie od reszty aplikacji.
Sklepy generujące feed produktowy do usługi google merchant wymagają szczególnej stabilności odpowiedzi. Plik XML potrafi ważyć kilkadziesiąt megabajtów, dlatego limit czasu odpowiedzi na tej ścieżce trzeba podnieść do 120 sekund, a kompresję gzip włączyć wybiórczo, aby nie obciążać bramy przy każdym żądaniu katalogu.
Skuteczne pozycjonowanie strony zaczyna się od przewidywalnych odpowiedzi serwera, a właśnie brama decyduje o kodach statusu widzianych przez roboty. Łańcuchy przekierowań, mieszanie wersji z prefiksem www i bez niego oraz losowe błędy 502 psują pozycjonowanie strony w google szybciej niż niedopracowane treści. Jedna reguła kanoniczna rozwiązuje ten problem trwale.
Koszty, wydajność i monitoring ruchu wejściowego
Największą oszczędnością, jaką daje kubernetes ingress, jest redukcja liczby płatnych adresów publicznych. Dwie repliki kontrolera z limitem 500 milicore i 512 MB pamięci obsłużą kilka tysięcy zapytań na sekundę. Autoskalowanie oparte na metryce zajętości procesora z progiem sześćdziesięciu procent zabezpiecza bramę przed nagłymi skokami ruchu kampanijnego.
Monitoring opiera się na eksporcie metryk do Prometheusa i obserwacji trzech wskaźników: czasu odpowiedzi w percentylu 95, udziału odpowiedzi z zakresu 5xx oraz liczby aktywnych połączeń. Przy planowaniu budżetu operacyjnego zespołu obok kosztu węzłów pojawiają się pozycje takie jak google workspace cena za użytkownika, dlatego oszczędność na balanserach realnie finansuje narzędzia pracy.
Dyżury produkcyjne bywają długie, a diagnostyka bramy to godziny spędzone w terminalu i nad wykresami. Stanowisko inżyniera platformy zwraca się szybciej, niż wskazywałby cennik, ponieważ skraca czas reakcji na incydent. Typowy zestaw, który sprawdza się przy pracy z klastrami, wygląda następująco:
- klawiatura mechaniczna z przełącznikami taktylnymi, wytrzymująca kilkanaście godzin pracy w konsoli
- kompaktowa klawiatura mechaniczna 60 procent do dyżurów poza biurem i pracy zdalnej
- klawiatura gamingowa mechaniczna z makrami przypisanymi do najczęstszych poleceń kubectl
- monitor do komputera o przekątnej 27 cali i rozdzielczości 1440p, mieszczący logi obok dashboardu
- tablet graficzny wacom do szkicowania diagramów przepływu ruchu podczas analizy powdrożeniowej
Jak skonfigurować kubernetes ingress dla wielu domen w jednym klastrze?
Utwórz jeden obiekt na aplikację zamiast jednego gigantycznego manifestu obejmującego wszystko. Każdy plik zawiera sekcję rules z nazwą hosta, listą ścieżek i wskazaniem usługi docelowej wraz z portem, a także sekcję tls z nazwą sekretu przechowującego certyfikat. Rozdzielenie manifestów ułatwia przegląd zmian i ogranicza zasięg awarii do jednej domeny. Dodaj pole ingressClassName, aby jednoznacznie wskazać kontroler, oraz adnotacje odpowiadające za przekierowanie ruchu na HTTPS. Przed wdrożeniem sprawdź konfigurację poleceniem kubectl describe, a po wdrożeniu przetestuj każdą domenę narzędziem curl z opcją weryfikacji łańcucha certyfikatów.
Czy Ingress zastępuje klasyczny load balancer i reverse proxy?
Zastępuje warstwę reverse proxy, ale nie eliminuje balansera sieciowego całkowicie. Kontroler nadal musi być wystawiony na świat, najczęściej przez pojedynczy Service typu LoadBalancer albo przez NodePort z osobnym proxy przed klastrem. Różnica polega na tym, że taki balanser jest jeden dla całej infrastruktury, a nie jeden na aplikację, co redukuje koszt i liczbę elementów do utrzymania. Funkcje kojarzone z klasycznym proxy, czyli terminacja TLS, kompresja, limity zapytań, filtrowanie adresów i przepisywanie nagłówków, przenoszą się do deklaratywnych manifestów wersjonowanych razem z kodem aplikacji.
Co zrobić, gdy brama zwraca błąd 502 lub 404 po wdrożeniu?
Zacznij od sprawdzenia, czy usługa docelowa faktycznie ma gotowe punkty końcowe, poleceniem kubectl get endpoints dla danej nazwy. Pusta lista oznacza, że selektor etykiet w definicji usługi nie pasuje do podów, co jest przyczyną większości błędów 502. Drugim podejrzanym jest niezgodność numeru portu między manifestem reguły a definicją usługi. Błąd 404 zwracany przez samą bramę wskazuje zwykle na literówkę w nazwie hosta, brakujący rekord DNS albo niewłaściwą wartość pola pathType. Logi kontrolera pokazują dokładnie dopasowaną regułę i wybrany backend, dlatego to od nich warto rozpocząć każdą diagnozę.
