Zarządzany kontroler NGINX Ingress z rozszerzeniem do routingu aplikacji

Ostrzeżenie

Kubernetes SIG Network i Komitet reagowania na zabezpieczenia ogłosiły wycofanieprojektu Ingress NGINX z konserwacją zakończoną w marcu 2026 r. 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 jest zgodna z projektem Kubernetes i używa interfejsu Gateway API jako długoterminowego standardu dla ruchu przychodzącego i zarządzania ruchem L7. Przeprowadź migrację przed zakończeniem obsługi w listopadzie 2026 r. na podstawie Twoich wymagań:

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 użyciem NGINX ten dodatek tworzy, konfiguruje i zarządza kontrolerem Ingress w klastrze AKS.

W tym artykule pokazano, jak włączyć zarządzany kontroler Ingress NGINX i skonfigurować obiekt Ingress, aby kierować ruch do aplikacji w klastrze 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 „snippet” odpowiada dowolnej z poniższych zablokowanych wartości, zasób Ingress nie zostanie skonfigurowany:

    Zablokowana wartość Efekt
    load_module Ingress nie jest skonfigurowany.
    lua_package Ingress nie jest skonfigurowany.
    _by_lua Ingress nie jest skonfigurowany.
    location Ingress nie jest skonfigurowany.
    root Ingress nie jest skonfigurowany.
    proxy_pass Ingress nie jest skonfigurowany.
    serviceaccount Ingress nie jest skonfigurowany.
    { Ingress nie jest skonfigurowany.
    } Ingress nie jest skonfigurowany.
    ' Ingress nie jest skonfigurowany.
  • Dodatek oficjalnie nie obsługuje wstrzykiwania do zarządzanych przez siebie zasobników proxy ingress-nginx kontenerów sidecar niezarządzanych przez firmę Microsoft (na przykład niestandardowej telemetrii, rejestrowania w dziennikach lub agentów zabezpieczeń). 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.

Klastry wielodzierżawne

Ważne

Zarządzany kontroler Ingress NGINX nie izoluje tenantów na poziomie przestrzeni nazw. Nie używaj go jako granicy zabezpieczeń między dzierżawcami, które współużytkują klaster.

Zarządzany kontroler Ingress NGINX jest oparty na projekcie ingress-nginx upstream. Projekt ingress-nginx zakłada, że użytkownicy, którzy mogą tworzyć obiekty Ingress, są administratorami klastra. Projekt mówi, że nie należy używać ingress-nginx w wielodostępnych klastrach produkcyjnych. Aby uzyskać więcej informacji, zobacz wielodzierżawny Kubernetes w często zadawanych pytaniach ingress-nginx.

Następujące zachowania przekraczają granice przestrzeni nazw:

  • Jeden kontroler Ingress NGINX obsługuje obiekty Ingress swojej klasy Ingress ze wszystkich przestrzeni nazw. Kontroler scala reguły tych obiektów Ingress w jedną konfigurację NGINX. Aby uzyskać więcej informacji, zobacz Jak to działa.
  • Ingress w jednej przestrzeni nazw może dodawać ścieżki do hosta, którego używa Ingress w innej przestrzeni nazw. Jeśli dwa obiekty Ingress używają tego samego hosta, najstarszy obiekt Ingress kontroluje ustawienia protokołu TLS i adnotacje na poziomie serwera dla tego hosta. Jeśli również używają tej samej ścieżki, najstarszy obiekt Ingress otrzymuje ruch dla tej ścieżki.
  • Dodatek umożliwia adnotacje fragmentów kodu, z wyjątkiem zablokowanych wartości w Ograniczenia. Adnotacje fragmentów kodu dodają konfigurację serwera NGINX do udostępnionego kontrolera.
  • Kontroler Ingress NGINX może odczytywać Sekrety we wszystkich przestrzeniach nazw. Dodatek umożliwia allow-cross-namespace-resources tę opcję. Korzystając z tej opcji, niektóre adnotacje mogą odwoływać się do obiektu Secret lub ConfigMap w innej przestrzeni nazw.
  • Użytkownik, który może utworzyć obiekt Ingress, może używać dowolnej klasy Ingress. Oddzielna NginxIngressController dla każdego dzierżawcy nie izoluje dzierżawców.

Aby zmniejszyć to ryzyko, skorzystaj z następujących rozwiązań:

  • Nadaj uprawnienia do tworzenia lub aktualizowania obiektów Ingress tylko użytkownikom, którym ufasz na tym samym poziomie co administratorzy klastra.
  • Jeśli dzierżawcy nie ufają sobie nawzajem, użyj oddzielnego klastra dla każdego dzierżawcy. Aby uzyskać więcej informacji, zobacz Fizycznie izolowane klastry.

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 Ingress w Kubernetes definiują reguły trasowania dla kontrolera Ingress. Użyj zarządzanej klasy Ingress dodatku Application Routing oraz obsługiwanych adnotacji, aby skonfigurować sposób, w jaki jego kontroler obsługuje ruch.

  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, , order-serviceproduct-servicei store-front wdrożenia i odpowiadające im usługi. Usługa store-front udostępnia port 80, do którego Ingress kieruje ruch w następnej sekcji.

Utwórz obiekt Ingress

Po włączeniu dodatku Application Routing powoduje utworzenie klasy Ingress o nazwie webapprouting.kubernetes.azure.com. Określ tę klasę w obiekcie Ingress, aby używać zarządzanego kontrolera Ingress NGINX tego dodatku.

  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
    

Zweryfikować zarządzany zasób Ingress

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 sklep AKS działa, przechodząc w przeglądarce pod publiczny adres IP kontrolera Ingress. Następujące polecenie pobiera zewnętrzny adres IP przypisany przez moduł równoważenia obciążenia do usługi nginx zarządzanego kontrolera wejściowego NGINX w przestrzeni nazw app-routing-system:

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 przychodzącego do klastra po wyłączeniu dodatku do routingu aplikacji, niektóre zasoby Kubernetes, w tym configMaps, secrets oraz deployment uruchamiający 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.