Zarządzany kontroler NGINX Ingress z rozszerzeniem do routingu aplikacji

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. Dzisiaj nie jest wymagana żadna natychmiastowa akcja dla klastrów AKS używających 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 interfejsu API routingu aplikacji dla środowiska zarządzania ruchem przychodzącym opartym na interfejsie API bramy.
  • 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.

Jednym ze sposobów kierowania ruchu protokołu HTTP (Hypertext Transfer Protocol) i HTTPS (Hypertext Transfer Protocol Secure) do aplikacji działających w klastrze usługi Azure Kubernetes Service (AKS) jest użycie obiektu Ingress Kubernetes. Po włączeniu dodatku routingu aplikacji z serwerem NGINX tworzy, konfiguruje i zarządza kontrolerem ruchu przychodzącego w klastrze usługi AKS.

W tym artykule przedstawiono sposób włączania zarządzanego kontrolera ruchu przychodzącego NGINX i konfigurowania obiektu ruchu przychodzącego w celu kierowania ruchu do aplikacji w klastrze usługi AKS.

Dodatek routingu aplikacji z funkcjami NGINX

Dodatek routingu aplikacji z serwerem NGINX zapewnia następujące elementy:

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

Aby zobaczyć inne konfiguracje, zobacz:

Ważne

Od 30 września 2027 r. Azure Kubernetes Service (AKS) nie będzie już obsługiwać dodatku Open Service Mesh (OSM). Nadrzędny projekt Open Service Mesh został wycofany.

Jeśli klaster korzysta z dodatku OSM, przeprowadź migrację do dodatku Istio przed datą zakończenia pomocy technicznej. To powiadomienie o wycofaniu dotyczy tylko zarządzanego dodatku OSM i nie dotyczy instalacji siatki usług typu open source ani samoobsługowych. Aby uzyskać instrukcje migracji, zobacz Wskazówki dotyczące migracji z dodatku OSM do dodatku Istio. Aby być na bieżąco z ogłoszeniami i aktualizacjami usługi AKS, postępuj zgodnie z informacjami o wersji usługi AKS.

Wymagania wstępne

  • Subskrypcja platformy Azure. Jeśli nie masz subskrypcji Azure, możesz utworzyć bezpłatne konto Azure.
  • Interfejs wiersza polecenia platformy Azure w wersji 2.54.0 lub nowszej został zainstalowany i skonfigurowany. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

Ograniczenia

  • Dodatek routingu aplikacji obsługuje maksymalnie pięć stref usługi Azure DNS.

  • Dodatek routingu aplikacji można włączyć tylko w klastrach usługi AKS z tożsamością zarządzaną.

  • Wszystkie globalne strefy DNS platformy Azure zintegrowane z dodatkiem muszą znajdować się w tej samej grupie zasobów.

  • Wszystkie prywatne strefy DNS platformy Azure zintegrowane z dodatkiem muszą znajdować się w tej samej grupie zasobów.

  • Edytowanie pliku ingress-nginx ConfigMap w app-routing-system przestrzeni nazw nie jest obsługiwane.

  • Jeśli wartość adnotacji fragmentu kodu jest zgodna z dowolną z następujących zablokowanych wartości, ruch przychodzący nie jest skonfigurowany:

    Zablokowana wartość Efekt
    load_module Ruch przychodzący nie jest skonfigurowany.
    lua_package Ruch przychodzący nie jest skonfigurowany.
    _by_lua Ruch przychodzący nie jest skonfigurowany.
    location Ruch przychodzący nie jest skonfigurowany.
    root Ruch przychodzący nie jest skonfigurowany.
    proxy_pass Ruch przychodzący nie jest skonfigurowany.
    serviceaccount Ruch przychodzący nie jest skonfigurowany.
    { Ruch przychodzący nie jest skonfigurowany.
    } Ruch przychodzący nie jest skonfigurowany.
    ' Ruch przychodzący nie jest skonfigurowany.

  • Dodatek nie obsługuje oficjalnie wstrzykiwania nienależących do Microsoft zarządzanych przyczepek (na przykład niestandardowych danych telemetrycznych, rejestrowania lub agentów zabezpieczeń) do zasobników serwera proxy ingress-nginx, którymi zarządza. Jeśli zdecydujesz się na wstrzyknięcie własnego przyczepki do zarządzanego zasobnika serwera proxy, Microsoft zapewnia tylko najlepszą obsługę wszelkich napotkanych problemów.

Włączanie dodatku routingu aplikacji przy użyciu Azure CLI

Włącz na nowym klastrze

Aby włączyć routing aplikacji w nowym klastrze, użyj az aks create polecenia z określeniem flagi --enable-app-routing.

az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --location <location> \
    --enable-app-routing \
    --generate-ssh-keys

Włączanie w istniejącym klastrze

Aby włączyć routing aplikacji w istniejącym klastrze, użyj polecenia az aks approuting enable.

az aks approuting enable --resource-group <resource-group-name> --name <cluster-name>

Nawiązywanie połączenia z klastrem usługi AKS

Aby nawiązać połączenie z klastrem Kubernetes z komputera lokalnego, należy użyć kubectlklienta wiersza polecenia kubernetes. Możesz zainstalować ją lokalnie przy użyciu az aks install-cli polecenia . Jeśli korzystasz z usługi Azure Cloud Shell, narzędzie kubectl jest już zainstalowane.

Skonfiguruj kubectl, aby nawiązać połączenie z klastrem Kubernetes za pomocą polecenia az aks get-credentials.

az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>

Wdrażanie aplikacji

Obiekty ruchu przychodzącego Kubernetes definiują reguły routingu dla kontrolera ruchu przychodzącego. Użyj zarządzanej klasy ingress dodatku routingu aplikacji i obsługiwanych adnotacji, aby skonfigurować sposób obsługi ruchu przez kontroler.

  1. Utwórz przestrzeń nazw aplikacji o nazwie aks-store , aby uruchomić przykładowe zasobniki przy użyciu kubectl create namespace polecenia .

    kubectl create namespace aks-store

  2. Wdróż aplikację magazynu AKS przy użyciu następującego pliku manifestu YAML:

    kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/sample-manifests/docs/app-routing/aks-store-deployments-and-services.yaml -n aks-store

Ten manifest tworzy rabbitmq, , product-serviceorder-servicei store-front wdrożenia i odpowiadające im usługi. store-front Usługa uwidacznia port 80, do którego kieruje ruch przychodzący w następnej sekcji.

Utwórz obiekt Ingress

Po włączeniu dodatku routingu aplikacji tworzy klasę ruchu przychodzącego o nazwie webapprouting.kubernetes.azure.com. Określ tę klasę w obiekcie ruchu przychodzącego, aby użyć zarządzanego kontrolera ruchu przychodzącego NGINX zarządzanego przez dodatek.

  1. Skopiuj następujący manifest YAML do nowego pliku o nazwie ingress.yaml i zapisz plik na komputerze lokalnym.

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: store-front
  namespace: aks-store
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  rules:
  - http:
      paths:
      - backend:
          service:
            name: store-front
            port:
              number: 80
        path: /
        pathType: Prefix

  2. Utwórz zasób Ingress przy użyciu polecenia kubectl apply.

    kubectl apply -f ingress.yaml -n aks-store

    W poniższych przykładowych danych wyjściowych przedstawiono utworzony zasób:

    ingress.networking.k8s.io/store-front created

Weryfikowanie zarządzanego zasobu ruchu przychodzącego

Możesz zweryfikować utworzenie zarządzanego Ingress za pomocą polecenia kubectl get ingress.

kubectl get ingress -n aks-store

W poniższym przykładowym wyniku przedstawiono utworzony zarządzany Ingress:

NAME          CLASS                                HOSTS   ADDRESS       PORTS   AGE
store-front   webapprouting.kubernetes.azure.com   *       51.8.10.109   80      110s

Możesz sprawdzić, czy magazyn usługi AKS działa, wskazując przeglądarkę na publiczny adres IP kontrolera ruchu przychodzącego. Następujące polecenie pobiera zewnętrzny adres IP przypisany przez moduł równoważenia obciążenia do usługi zarządzanego kontrolera nginx ruchu przychodzącego NGINX w app-routing-system przestrzeni nazw:

kubectl get service -n app-routing-system nginx -o jsonpath="{.status.loadBalancer.ingress[0].ip}"

Usuwanie dodatku routingu aplikacji

Aby usunąć skojarzona przestrzeń nazw, użyj kubectl delete namespace polecenia .

kubectl delete namespace aks-store

Aby usunąć dodatek routingu aplikacji z klastra, użyj az aks approuting disable polecenia .

az aks approuting disable --name <cluster-name> --resource-group <resource-group-name>

Uwaga

Aby uniknąć potencjalnych zakłóceń ruchu w klastrze po wyłączeniu dodatku routingu aplikacji, niektóre zasoby Kubernetes, w tym configMaps, wpisy tajne i wdrożenie , które uruchamia kontroler, pozostają w klastrze. Te zasoby znajdują się w przestrzeni nazw app-routing-system . Możesz usunąć te zasoby, jeśli nie są już potrzebne, usuwając przestrzeń nazw za pomocą polecenia kubectl delete ns app-routing-system.

Treści powiązane

  • Last updated on