Ingress w usłudze Azure Kubernetes Service (AKS)

Ostrzeżenie

Platforma Kubernetes SIG Network i Komitet Reagowania na zabezpieczenia ogłosiły wycofanieprojektu Ingress NGINX, a konserwacja zakończyła się w marcu 2026 r. Obecnie nie jest wymagane żadne natychmiastowe działanie dla klastrów AKS korzystających z dodatku routingu aplikacji z serwerem NGINX. Firma Microsoft zapewni oficjalną obsługę krytycznych poprawek zabezpieczeń dla zasobów dodatku do routingu aplikacji NGINX Ingress do listopada 2026 r..

Usługa AKS dostosowuje się do nadrzędnej wersji Kubernetes, przechodząc do Gateway API jako długoterminowego standardu dla ingress i zarządzania ruchem L7. Zalecamy rozpoczęcie planowania ścieżki migracji na podstawie bieżącej konfiguracji:

  • Użytkownicy dodatku routingu aplikacji: Obciążenia produkcyjne pozostają w pełni obsługiwane do listopada 2026 r. Przeprowadź migrację do implementacji Gateway API dla routingu aplikacji, aby uzyskać doświadczenie w zarządzaniu ruchem przychodzącym oparte na Gateway API.
  • Użytkownicy systemu operacyjnego NGINX mają kilka opcji:
  • Użytkownicy Service Mesh: jeśli planujesz wdrożyć Service Mesh, rozważ dodatek do Service Mesh oparty na Istio. Korzystaj już dziś z Istio Ingress i zaplanuj migrację do interfejsu API Istio Gateway, który jest już ogólnie dostępny.

"Zasób Ingress w AKS to element Platformy Kubernetes, który zarządza zewnętrznym dostępem HTTP do usług w klastrze." Ingrs AKS może zapewniać usługi, takie jak równoważenie obciążenia, zakończenie SSL i hosting wirtualny oparty na nazwach. Aby uzyskać więcej informacji na temat Kubernetes Ingress, zobacz dokumentację Kubernetes Ingress.

W przypadku większości obciążeń produkcyjnych zacznij od usługi AKS Automatic. AKS Automatic jest domyślnym, zalecanym rozwiązaniem produkcyjnym w usłudze AKS i zapewnia zarządzane ustawienia domyślne w zakresie sieci, skalowania, zabezpieczeń, monitorowania i aktualizacji. W przypadku ruchu przychodzącego oznacza to, że można rozpocząć od zarządzanej ścieżki ruchu przychodzącego i przejść tylko do bardziej wyspecjalizowanych opcji, gdy potrzebujesz dokładniejszej kontroli nad topologią, zachowaniem routingu lub integracją siatki usług.

Użyj usługi AKS Standard, jeśli potrzebujesz bardziej wyraźnej kontroli nad wyborem kontrolera ruchu przychodzącego, topologią wdrożenia lub zaawansowaną integracją sieci.

Tryby klastra usługi AKS i ruch przychodzący

Usługa AKS obsługuje dwa tryby klastra:

  • AKS Automatic: Zalecany punkt wyjścia dla większości obciążeń produkcyjnych. Zmniejsza narzut operacyjny i zapewnia zarządzane ustawienia domyślne dla ingressu i powiązanych komponentów sieciowych.
  • AKS Standard: najlepszy wybór, gdy potrzebujesz jawnej kontroli nad hostowaniem kontrolera ingress, udostępnianiem usług i zaawansowanymi wzorcami zarządzania ruchem.

Wskazówki dotyczące ruchu przychodzącego zawarte w tym artykule mają zastosowanie do obu trybów. Główna różnica polega na tym, kto odpowiada za więcej domyślnych ustawień platformy i jak dużym stopniem dostosowania musisz zarządzać bezpośrednio.

Kontrolery ruchu przychodzącego

Podczas zarządzania ruchem aplikacji, kontrolery Ingress zapewniają zaawansowane możliwości dzięki obsłudze w warstwie 7. Mogą kierować ruch HTTP do różnych aplikacji na podstawie adresu URL ruchu przychodzącego, co pozwala na bardziej inteligentne i elastyczne reguły dystrybucji ruchu. Na przykład kontroler ruchu przychodzącego może kierować ruch do różnych mikrousług w zależności od ścieżki adresu URL, zwiększając wydajność i organizację usług.

Z drugiej strony usługa typu LoadBalancer po utworzeniu konfiguruje bazowy zasób modułu równoważenia obciążenia platformy Azure. Ten moduł równoważenia obciążenia działa w warstwie 4, dystrybuując ruch do zasobników w usłudze na określonym porcie. Jednak usługi warstwy 4 nie znają rzeczywistych aplikacji i nie mogą implementować tych typów złożonych reguł routingu.

Zrozumienie różnic między tymi dwoma podejściami pomaga w wyborze odpowiedniego narzędzia dla potrzeb w zakresie zarządzania ruchem.

Jeśli używasz usługi AKS Automatic, najpierw zacznij od zarządzanej ścieżki ruchu przychodzącego i użyj bardziej wyspecjalizowanych opcji tylko wtedy, gdy obciążenie ich wymaga. W usłudze AKS Standard masz większą elastyczność, aby wybrać kontroler ruchu przychodzącego i topologię, która najlepiej pasuje do architektury.

Diagram przedstawiający przepływ ruchu przychodzącego w klastrze AKS

Porównanie opcji dostępu

Porównanie funkcji

W poniższej tabeli wymieniono różnice funkcji między różnymi opcjami kontrolera ruchu przychodzącego. W przypadku większości produkcyjnych obciążeń AKS zalecanym domyślnym rozwiązaniem jest podejście oparte na zarządzanym ruchu przychodzącym w usłudze AKS Automatic, chyba że potrzebujesz niestandardowego routingu, integracji z siatką usług lub ruchu przychodzącego hostowanego na platformie Azure.

Funkcja Dodatek routingu aplikacji Brama aplikacji dla kontenerów siatka usług Azure Service Mesh/Istio
Ruch przychodzący/kontroler bramy NGINX Ingress Controller Azure Brama Aplikacji dla Kontenerów Brama wejściowa Istio
API API Ingress Interfejs API ruchu przychodzącego i interfejs API bramy Ingress API Istio
Hosting W klastrze Hostowana na platformie Azure W klastrze
Skalowanie Skalowanie automatyczne Skalowanie automatyczne Skalowanie automatyczne
Równoważenie obciążenia Wewnętrzne/zewnętrzne Zewnętrzne Wewnętrzne/zewnętrzne
Kończenie żądań SSL W klastrze Tak: odciążanie serwera i end-to-end SSL W klastrze
mTLS Nie dotyczy Tak: fronton i zaplecze Tak
Statyczny adres IP Tak FQDN (bez statycznego adresu IP) Nie dotyczy
Usługa Azure Key Vault przechowywała certyfikaty SSL Tak Tak Nie dotyczy
Integracja usługi Azure DNS z zarządzaniem strefami DNS Tak Tak Nie dotyczy

Kiedy używać poszczególnych kontrolerów Ingress

W poniższej tabeli wymieniono różne scenariusze, w których można użyć każdego kontrolera ruchu przychodzącego:

Opcja wejściowa Kiedy używać
Zarządzany serwer NGINX — dodatek routingu aplikacji • Hostowane w klastrze, dostosowywalne i skalowalne kontrolery NGINX Ingress.
• Podstawowe możliwości równoważenia obciążenia i routingu.
• Konfiguracja wewnętrznego i zewnętrznego modułu równoważenia obciążenia.
• Konfiguracja statycznego adresu IP.
• Integracja z Azure Key Vault do zarządzania certyfikatami.
• Integracja z strefami Azure DNS na potrzeby zarządzania publicznym i prywatnym systemem DNS.
• Obsługuje interfejs API Ingress.
Bramka aplikacji dla kontenerów • Brama ruchu przychodzącego hostowana na platformie Azure.
• Elastyczne strategie wdrażania zarządzane przez kontroler lub przynieść własną usługę Application Gateway for Containers.
• Zaawansowane funkcje zarządzania ruchem, takie jak automatyczne ponawianie prób, odporność na awarie w strefach dostępności, wzajemne uwierzytelnianie (mTLS) wobec docelowego zaplecza, dzielenie ruchu / ważony algorytm round robin oraz automatyczne skalowanie.
• Integracja z Azure Key Vault do zarządzania certyfikatami.
• Integracja z strefami Azure DNS na potrzeby zarządzania publicznym i prywatnym systemem DNS.
• Obsługuje interfejsy API Ingress i Gateway.
Gateway Ingress Istio • Na podstawie Envoy, przy korzystaniu z Istio dla siatki usług.
• Zaawansowane funkcje zarządzania ruchem, takie jak ograniczanie szybkości i przerywanie obwodów.
• Obsługa mTLS.

Uwaga

Obecnie dodatek Istio nie obsługuje interfejsu Gateway API dla ruchu przychodzącego Istio.

Utwórz zasób Ingress

Dodatek Application Routing jest zalecanym sposobem konfigurowania kontrolera Ingress w usłudze AKS, a w przypadku większości obciążeń w usłudze AKS Automatic jest to zarządzana opcja wejścia, od której warto zacząć. Dodatek do routingu aplikacji to w pełni zarządzany kontroler ruchu wejściowego dla usługi AKS, który zapewnia następujące funkcje:

  • Łatwa konfiguracja zarządzanych kontrolerów Ingress NGINX opartych na kontrolerze Kubernetes NGINX Ingress.
  • Integracja z usługą Azure DNS na potrzeby zarządzania strefami publicznymi i prywatnymi.
  • Zakończenie połączenia SSL z certyfikatami przechowywanymi w Azure Key Vault.

W przypadku większości obciążeń produkcyjnych jest to właściwe domyślne ustawienie na początek. Jeśli potrzebujesz niestandardowej topologii ruchu przychodzącego, Azure hostowanego ruchu przychodzącego lub zachowania siatki usługi, możesz przejść do jednej z pozostałych opcji ruchu przychodzącego.

Aby uzyskać więcej informacji na temat dodatku routingu aplikacji, zobacz Managed NGINX ingress with the Application Routing add-on (Zarządzanie ruchem przychodzącym NGINX za pomocą dodatku routingu aplikacji).

Zachowywanie źródłowego adresu IP klienta

Skonfiguruj kontroler wejściowy, aby zachować źródłowy adres IP klienta w żądaniach do kontenerów w klastrze AKS. Gdy kontroler ruchu przychodzącego kieruje żądanie klienta do kontenera w klastrze usługi AKS, oryginalny źródłowy adres IP tego żądania jest niedostępny dla kontenera docelowego. Po włączeniu opcji zachowania źródłowego adresu IP klienta, adres IP klienta jest dostępny w nagłówku żądania pod X-Forwarded-For.

Jeśli używasz zachowania źródłowego adresu IP klienta na kontrolerze ingress, nie możesz użyć przekazywania ruchu TLS. Zachowywanie źródłowego adresu IP klienta i przekazywanie protokołu TLS może być używane z innymi usługami, takimi jak typ modułu LoadBalancer .

Pozostaje to ważny wybór projektu zarówno w usłudze AKS Automatic, jak i AKS Standard, ponieważ obsługa źródłowego adresu IP ma wpływ na możliwość obserwowania, inspekcję i zachowanie aplikacji niezależnie od trybu klastra.

Aby dowiedzieć się więcej na temat zachowywania źródłowego adresu IP klienta, zobacz Jak działa zachowywanie źródłowego adresu IP klienta dla usług LoadBalancer w usłudze AKS.