Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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:
- Przeprowadź migrację do dodatku routingu aplikacji z serwerem NGINX, aby skorzystać z oficjalnej pomocy technicznej do listopada 2026 r., jednocześnie planując długoterminową migrację do API Gateway.
- Przeprowadź migrację do implementacji Gateway API dla routingu aplikacji, aby uzyskać doświadczenie w zarządzaniu ruchem przychodzącym oparte na Gateway API.
- Przejdź do usługi Application Gateway dla kontenerów, która obsługuje zarówno Ingress API, jak i Gateway API.
- Wymagania dotyczące siatki usług lub zaawansowanego ruchu przychodzącego: Rozważ Ingress Gateway API z dodatkiem siatki usług Istio. Można go używać do ruchu przychodzącego bez wstrzykiwania przyczepek do obciążeń. Jeśli potrzebujesz limitów rozmiaru nagłówka i treści żądania, skryptów Lua lub ograniczania szybkości, zapoznaj się z ograniczeniami i alternatywami interfejsu Gateway API.
Dodatek routingu aplikacji obsługuje interfejs API bramy Kubernetes na potrzeby zarządzania ruchem przychodzącym. Kubernetes Gateway API to zestaw zasobów, które zapewniają ustandaryzowaną, zorientowaną na rolę i rozszerzalną platformę do zarządzania ruchem, zaprojektowaną jako następca i rozwinięcie Ingress API. Implementacja API routingu aplikacji ma zatem służyć jako następca zarządzanego dodatku NGINX, który jest oparty na starszym Ingress API i przestanie otrzymywać wsparcie od Azure po listopadzie 2026 r. Jeśli używasz zarządzanego serwera NGINX, musisz przeprowadzić migrację do implementacji interfejsu API routingu aplikacji lub innej obsługiwanej implementacji do listopada 2026 r.
W przypadku obciążeń produkcyjnych ten model jest zalecanym domyślnym modelem ruchu przychodzącego w AKS Automatic. Począwszy od wersji 1.36 usługi AKS nowe klastry AKS Automatic domyślnie używają interfejsu Kubernetes Gateway API za pośrednictwem dodatku Application Routing. Informacje na temat domyślnych ustawień produkcyjnych usługi AKS Automatic można znaleźć tutaj: Czym jest Azure Kubernetes Service (AKS) Automatic?
Porównanie z dodatkiem siatki usług Istio
Implementacja rozszerzenia routingu w interfejsie API usługi Kubernetes Gateway wdraża płaszczyznę sterowania Istio w celu zarządzania infrastrukturą zasobów interfejsu API usługi Kubernetes Gateway. Jednak różni się on od dodatku siatki usług Istio dla AKS następująco:
| Funkcja | Brama API trasowania aplikacji | Dodatek Istio do siatki usług |
|---|---|---|
| Nazwa klasy bramy | approuting-istio |
istio |
| Wstrzykiwanie przyczepki i obsługa Istio CRD | Niewspierane. Zarządza infrastrukturą tylko dla zasobów interfejsu API usługi Kubernetes Gateway | Wsparte |
| Poprawki i uaktualnienia | Niezrewidowane. Uaktualniono w miejscu zarówno aktualizacje wersji pomocniczej, jak i poprawkowej | Przebudowany. Uaktualniono za pomocą uaktualnień kanaryjnych dla aktualizacji wersji mniejszych i bezpośrednio dla aktualizacji wersji poprawek. |
Kiedy używać interfejsu API usługi Application Routing Gateway w środowisku produkcyjnym
Użyj tej implementacji jako domyślnej ścieżki ruchu przychodzącego, jeśli chcesz:
- Domyślna, zarządzana usługa ingress gotowa do wdrożeń produkcyjnych w AKS Automatic.
- Ruch przychodzący HTTP/HTTPS natywny dla interfejsu API Kubernetes Gateway.
- Infrastruktura bramy zarządzanej z wbudowanymi zabezpieczeniami operacyjnymi, takimi jak skalowanie automatyczne i budżety zakłóceń na serwerach proxy bramy.
Rozważ alternatywy, jeśli potrzebujesz możliwości spoza bieżącej pomocy technicznej w tym artykule, takich jak:
- Zarządzanie ruchem w siatkach usług.
- Funkcje wymienione w temacie Ograniczenia.
Ograniczenia
Nie można skonfigurować limitów rozmiaru nagłówka i treści żądania, skryptów Lua ani lokalnych i globalnych limitów szybkości za pomocą tej implementacji. Gateway API nie zawiera standardowych pól dla tych funkcji, a implementacja App Routing Gateway API nie obsługuje
EnvoyFilter.Jeśli potrzebujesz tych funkcji podczas migracji z ingress-nginx, rozważ ingress Gateway API z dodatkiem siatki usług Istio. Możesz używać zasobów
Gateway,HTTPRouteoraz innych zasobów Gateway API bez wstrzykiwania sidecarów do swoich obciążeń roboczych oraz zastosować elementEnvoyFiltero zakresie bramy, aby je skonfigurować. Problemy spowodowane konfiguracjąEnvoyFilterznajdują się poza pomoc techniczna platformy Azure. Jeśli wybierzesz dodatek service mesh Istio, musisz zainicjować i ukończyć aktualizacje kanarkowe przy aktualizacjach rewizji pomocniczych, nawet jeśli jest on używany wyłącznie do obsługi ruchu przychodzącego.Przetestuj każdy zamiennik adnotacji lub fragmentu kodu nginx względem swojej wersji Istio. Na przykład filtr buforu envoy wymusza limit rozmiaru treści, przechowując pełną treść żądania w pamięci przed przekazaniem go dalej. Nie rozla się na dysk.
Nie można jednocześnie włączyć implementacji interfejsu Gateway API routingu aplikacji i dodatku siatki usług Istio. Należy najpierw wyłączyć jedną i włączyć drugą w osobnej operacji. Podczas przechodzenia z dodatku siatki usługi Istio do implementacji interfejsu API routingu aplikacji należy usunąć elementy Istio GatewayClass i Istio CRD po wyłączeniu dodatku Istio. Dodatek Istio instaluje zasoby CRD (takie jak
virtualservices.networking.istio.io,destinationrules.networking.istio.ioi inne w grupach APInetworking.istio.io,security.istio.io,telemetry.istio.ioiextensions.istio.io), które nie są usuwane po wyłączeniu dodatku. Jeśli te CRD pozostaną w klastrze, uruchomienie płaszczyzny sterowania Istio Gateway API dla routingu aplikacji nie powiedzie się. Uruchom następujące polecenie, aby je usunąć:kubectl delete crd $(kubectl get crd -o name | grep -E 'istio\.io') kubectl delete gatewayclass istioUwaga / Notatka
Jeśli masz istniejące zasoby niestandardowe Istio (takie jak VirtualServices lub DestinationRules), usunięcie identyfikatorów CRD spowoduje również usunięcie tych zasobów. Przed kontynuowaniem upewnij się, że nie są już potrzebne.
Implementacja interfejsu API routingu aplikacji używa tej samej listy dozwolonych dostosowań zasobów co dodatek Istio do sprawdzania poprawności dostosowań ConfigMap dla
Gatewayzasobów. Webhooki zarządzane przez dodatki blokują modyfikacje, których nie ma na liście dozwolonych.Zarządzanie ruchem wychodzącym za pośrednictwem implementacji interfejsu API bramy routingu aplikacji nie jest obsługiwane.
Wstrzykiwanie kontenerów sidecar niezarządzanych przez firmę Microsoft (na przykład niestandardowych agentów telemetrii, rejestrowania lub zabezpieczeń) do podów proxy bramy Istio zarządzanych przez dodatek routingu aplikacji nie jest oficjalnie obsługiwane. 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.
Rejestrowanie dostępu do usługi Envoy jest domyślnie włączone w zasobnikach serwera proxy bramy, ale nie można dostosować formatu dziennika, zakresu i dostawcy za pośrednictwem interfejsu API Istio
Telemetry. Aby dostosować konfigurację, zamiast tego użyj wejścia Gateway API w dodatku Istio service mesh.
Wymagania wstępne
Aktualizowanie wersji interfejsu wiersza polecenia platformy Azure
Musisz użyć wersji azure-cli2.86.0 lub nowszej. Uruchom polecenie az --version , aby znaleźć swoją azure-cli wersję i uruchomić az upgrade polecenie , aby uaktualnić.
Włącz interfejsy CRD zarządzanego interfejsu Gateway API
Włącz instalację interfejsu API usługi Managed Gateway. Korzystanie z samodzielnie zarządzanych CRD bramy API z dodatkiem routingu aplikacji nie jest obsługiwane.
Automatyczne zachowanie domyślne w usłudze AKS (AKS 1.36 i nowsze)
W nowych klastrach AKS Automatic działających w wersji AKS 1.36 lub nowszej interfejs API Kubernetes Gateway za pośrednictwem dodatku routingu aplikacji jest domyślnie włączony.
Zwykle nie trzeba uruchamiać polecenia włączania funkcji, chyba że:
- Korzystanie z istniejącego klastra.
- Korzystanie ze starszej wersji AKS
- Ponowne włączenie funkcji po jej wyłączeniu.
Włącz implementację interfejsu API bramy routingu aplikacji
Uwaga / Notatka
Jeśli utworzysz nowy klaster AKS Automatic w wersji AKS 1.36 lub nowszej, ta funkcja jest domyślnie włączona. Użyj poleceń w tej sekcji dla klastrów usługi AKS w warstwie Standardowa, wcześniejszych wersji lub istniejących klastrów, które nie mają jeszcze włączonej funkcji.
Włączanie podczas tworzenia klastra
Uruchom następujące polecenie, aby włączyć implementację interfejsu API bramy routingu aplikacji podczas tworzenia klastra usługi AKS Standard:
# Set environment variables
export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>
# Enable the application routing Gateway API implementation during AKS Standard cluster creation
az aks create --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --enable-gateway-api --enable-app-routing-istio
Włącz dla istniejącego klastra
Uruchom następujące polecenie, aby włączyć implementację interfejsu API usługi Application Routing Gateway dla istniejącego klastra:
# Set environment variables
export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>
# Enable the application routing Gateway API implementation for an existing cluster
az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --enable-gateway-api --enable-app-routing-istio
Powinieneś zobaczyć istiod zasobniki w aks-istio-system przestrzeni nazw.
kubectl get pods -n aks-istio-system
NAME READY STATUS RESTARTS AGE
istiod-12a3bc45de-fghi6 1/1 Running 0 3m15s
istiod-78j9kl01mn-opqrs 1/1 Running 0 3m
Również powinieneś zobaczyć, jak ValidatingWebhookConfiguration zostaje wdrożony.
kubectl get validatingwebhookconfiguration
NAME WEBHOOKS AGE
aks-node-validating-webhook 1 117m
azure-service-mesh-ccp-validating-webhook 1 4m2s
Jeśli masz włączoną instalację interfejsu API bramy zarządzanej, powinien zostać również utworzony obiekt ConfigMap do dostosowywania bramy Istio.
kubectl get cm -n aks-istio-system
NAME DATA AGE
...
istio-gateway-class-defaults 2 43s
...
Konfigurowanie ingress przy użyciu Gateway Kubernetes
Wdrażanie przykładowej aplikacji
Najpierw wdróż przykładową httpbin aplikację w default przestrzeni nazw:
export ISTIO_RELEASE="release-1.27"
kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_RELEASE/samples/httpbin/httpbin.yaml
Tworzenie bramy Kubernetes i usługi HTTPRoute
Następnie wdróż konfigurację interfejsu API bramy w przestrzeni nazw z ustawionym default na gatewayClassName.
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: httpbin-gateway
spec:
gatewayClassName: approuting-istio
listeners:
- name: http
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: httpbin
spec:
parentRefs:
- name: httpbin-gateway
hostnames: ["httpbin.example.com"]
rules:
- matches:
- path:
type: PathPrefix
value: /get
backendRefs:
- name: httpbin
port: 8000
EOF
Uwaga / Notatka
Powyższy przykład tworzy zewnętrzny serwis równoważenia obciążenia wejściowego, który jest dostępny z zewnątrz klastra. Możesz dodać adnotacje , aby utworzyć wewnętrzny moduł równoważenia obciążenia i dostosować inne ustawienia modułu równoważenia obciążenia.
Uwaga / Notatka
Domyślnie płaszczyzna sterowania Istio dołączy nazwę GatewayClass do nazwy zasobów approuting-istio, które udostępnia dla zasobu Gateway. Możesz dodać adnotację do Gateway zasobu za pomocą polecenia gateway.istio.io/name-override , aby zastąpić nazwę zaaprowizowanych zasobów. Nazwy zasobów muszą być mniejsze niż 63 znaki i muszą być prawidłową nazwą DNS.
Sprawdź, czy utworzono element Deployment, Service, HorizontalPodAutoscaleri PodDisruptionBudget dla elementu httpbin-gateway:
kubectl get deployment httpbin-gateway-approuting-istio
NAME READY UP-TO-DATE AVAILABLE AGE
httpbin-gateway-approuting-istio 2/2 2 2 6m41s
kubectl get service httpbin-gateway-approuting-istio
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
httpbin-gateway-approuting-istio LoadBalancer 10.0.54.96 <external-ip> 15021:30580/TCP,80:32693/TCP 7m13s
kubectl get hpa httpbin-gateway-approuting-istio
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
httpbin-gateway-approuting-istio Deployment/httpbin-gateway-approuting-istio cpu: 3%/80% 2 5 2 8m13s
kubectl get pdb httpbin-gateway-approuting-istio
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
httpbin-gateway-approuting-istio 1 N/A 1 9m1s
Wysyłanie żądania do przykładowej aplikacji
Na koniec spróbuj wysłać curl żądanie do httpbin aplikacji. Najpierw ustaw zmienną środowiskową INGRESS_HOST :
kubectl wait --for=condition=programmed gateways.gateway.networking.k8s.io httpbin-gateway
export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -ojsonpath='{.status.addresses[0].value}')
Następnie spróbuj wysłać żądanie HTTP do :httpbin
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
Odpowiedź HTTP 200 powinna być widoczna.
Uwaga / Notatka
Aby zabezpieczyć ruch przychodzący za pomocą implementacji interfejsu API usługi Application Routing Gateway i zintegrować go z Azure DNS na potrzeby zarządzania nazwami hostów, zobacz Konfigurowanie Azure DNS i protokołu TLS przy użyciu implementacji interfejsu API usługi Application Routing Gateway dla zautomatyzowanego przepływu pracy obsługiwanego przez operatora routingu aplikacji. Informacje na temat ręcznego procesu kończenia połączeń TLS, który nie opiera się na integracji z operatorem, można znaleźć w dokumencie Zabezpieczanie ruchu przychodzącego przy użyciu implementacji interfejsu API bramy routingu aplikacji.
Aby użyć narzędzia Terraform do utworzenia klastra usługi AKS z włączoną implementacją interfejsu API routingu aplikacji, potrzebne są następujące elementy:
- Zainstalowano wersję
1.9.0programu Terraform lub nowszą. - Zainstalowany i uwierzytelniony Azure CLI. Uruchom polecenie
az --version, aby znaleźć swojąazure-cliwersję i uruchomićaz upgradepolecenie , aby uaktualnić. Użyjesz Azure CLI, aby nawiązać połączenie z klastrem po utworzeniu go przez narzędzie Terraform. - zainstalowano narzędzie kubectl. Możesz zainstalować ją lokalnie przy użyciu
az aks install-clipolecenia . Używaszkubectl, aby wdrożyć przykładową aplikację i zasoby interfejsu Gateway API.
Wdróż klaster AKS z implementacją interfejsu Gateway API routingu aplikacji za pomocą narzędzia Terraform
W tej sekcji pokazano, jak za pomocą narzędzia Terraform wdrożyć klaster usługi AKS z instalacją interfejsu API usługi Managed Gateway i włączoną implementacją interfejsu API routingu aplikacji.
Uwaga / Notatka
Przykładowy kod tej sekcji znajduje się w repozytorium Azure Terraform GitHub. Możesz wyświetlić plik dziennika zawierający wyniki testu z bieżących i poprzednich wersji programu Terraform.
Zobacz więcej artykułów i przykładowego kodu pokazującego, jak zarządzać zasobami platformy Azure przy użyciu narzędzia Terraform.
Ten przykład wdraża:
- Grupa zasobów.
- Klaster usługi AKS, który korzysta z wtyczki sieciowej Azure CNI i standardowego modułu równoważenia obciążenia.
- Instalacja interfejsu API usługi Managed Gateway i implementacja interfejsu API routingu aplikacji są włączone w klastrze za pośrednictwem dostawcy AzAPI. Włączenie obu ustawień powoduje, że zarządzana przez AKS klasa
approuting-istioGatewayClass jest dostępna w klastrze.
Utwórz katalog, aby przetestować i uruchomić przykładowy kod narzędzia Terraform, a następnie ustaw go jako bieżący katalog.
Utwórz plik o nazwie
main.tfi wstaw następujący kod:terraform { required_version = ">= 1.9.0" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 4.0" } azapi = { source = "Azure/azapi" version = "~> 2.0" } random = { source = "hashicorp/random" version = "~> 3.0" } } } provider "azurerm" { features {} } provider "azapi" { enable_preflight = true } resource "random_string" "suffix" { length = 6 upper = false special = false } locals { location = "eastus" resource_group_name = "rg-aks-gateway-api-${random_string.suffix.result}" cluster_name = "aks-gwapi-${random_string.suffix.result}" } resource "azurerm_resource_group" "example" { name = local.resource_group_name location = local.location } resource "azurerm_kubernetes_cluster" "example" { name = local.cluster_name location = azurerm_resource_group.example.location resource_group_name = azurerm_resource_group.example.name dns_prefix = local.cluster_name role_based_access_control_enabled = true default_node_pool { name = "system" node_count = 2 vm_size = "Standard_D4s_v4" upgrade_settings { drain_timeout_in_minutes = 0 max_surge = "10%" node_soak_duration_in_minutes = 0 } } identity { type = "SystemAssigned" } network_profile { network_plugin = "azure" load_balancer_sku = "standard" } } resource "azapi_update_resource" "gateway_api_app_routing" { type = "Microsoft.ContainerService/managedClusters@2026-03-01" resource_id = azurerm_kubernetes_cluster.example.id body = { properties = { ingressProfile = { gatewayAPI = { installation = "Standard" } webAppRouting = { gatewayAPIImplementations = { appRoutingIstio = { mode = "Enabled" } } } } } } response_export_values = [ "properties.ingressProfile" ] depends_on = [ azurerm_kubernetes_cluster.example ] } output "resource_group_name" { value = azurerm_resource_group.example.name } output "cluster_name" { value = azurerm_kubernetes_cluster.example.name } output "get_credentials_command" { value = "az aks get-credentials --resource-group ${azurerm_resource_group.example.name} --name ${azurerm_kubernetes_cluster.example.name} --overwrite-existing" }Zainicjuj narzędzie Terraform, uruchamiając polecenie
terraform init. To polecenie pobiera dostawców platformy Azure wymaganych do zarządzania zasobami Azure za pomocą narzędzia Terraform.terraform initSformatuj i zweryfikuj konfigurację, uruchamiając polecenia
terraform fmtiterraform validate.terraform fmt terraform validateUtwórz plan wykonywania narzędzia Terraform, uruchamiając
terraform planpolecenie . To polecenie pokazuje zasoby tworzone lub modyfikowane przez program Terraform w ramach subskrypcji Azure.terraform planZastosuj plan wykonania Terraform, uruchamiając polecenie
terraform apply. To polecenie tworzy zasoby zdefiniowane wmain.tfpliku w subskrypcji Azure. Po wyświetleniu monitu wprowadź polecenieyes, aby potwierdzić.terraform apply
Nawiązywanie połączenia z klastrem usługi AKS przy użyciu narzędzia Terraform
Pobierz nazwy grup zasobów i klastrów z danych wyjściowych programu Terraform.
terraform output -raw resource_group_name terraform output -raw cluster_nameSkonfiguruj
kubectl, aby połączyć się z klastrem za pomocą poleceniaaz aks get-credentials. To polecenie pobiera poświadczenia i konfiguruje Kubernetes CLI do ich użycia. Zamień<resource-group-name>i<cluster-name>na wartości z poprzedniego kroku. Możesz też uruchomić polecenieterraform output -raw get_credentials_command, aby uzyskać pełne, gotowe do uruchomienia polecenie.az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>Sprawdź, czy klaster jest uruchomiony, uruchamiając
kubectl get nodespolecenie .kubectl get nodes
Weryfikowanie konfiguracji interfejsu API bramy przy użyciu narzędzia Terraform
Upewnij się, że pody
istioddziałają w przestrzeni nazwaks-istio-system.kubectl get pods -n aks-istio-systemUpewnij się, że klasa
approuting-istioGatewayClass istnieje i została zaakceptowana.kubectl get gatewayclassKlasa
approuting-istioGatewayClass powinna zwracać wartośćTruew kolumnieACCEPTED.
Konfigurowanie ruchu przychodzącego przy użyciu bramy Kubernetes z programem Terraform
Wdrażanie przykładowej aplikacji przy użyciu narzędzia Terraform
Wdróż przykładową aplikację httpbin w przestrzeni nazw default:
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/httpbin/httpbin.yaml
Sprawdź, czy pod httpbin i usługa są dostępne:
kubectl get pods -l app=httpbin
kubectl get svc httpbin
Tworzenie zasobów bramy i usługi HTTPRoute przy użyciu programu Terraform
Przykładowa implementacja interfejsu Gateway API do routingu aplikacji zawiera manifest Gateway, który tworzy odbiornik HTTP na porcie 80 i używa zarządzanej przez AKS klasy GatewayClass approuting-istio.
Utwórz plik o nazwie
gateway.yamli wstaw następujący kod:apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: httpbin-gateway spec: gatewayClassName: approuting-istio listeners: - name: http port: 80 protocol: HTTP allowedRoutes: namespaces: from: SameZastosuj konfigurację
Gateway:kubectl apply -f gateway.yamlPrzykład zawiera także manifest
HTTPRoute, który kieruje żądania dlahttpbin.example.com/getdo usługihttpbinna porcie8000.Utwórz plik o nazwie
httproute.yamli wstaw następujący kod:apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: httpbin spec: parentRefs: - name: httpbin-gateway hostnames: - httpbin.example.com rules: - matches: - path: type: PathPrefix value: /get backendRefs: - name: httpbin port: 8000Zastosuj konfigurację
HTTPRoute:kubectl apply -f httproute.yaml
Uwaga / Notatka
Powyższy przykład tworzy usługę zewnętrznego modułu równoważenia obciążenia dla ruchu przychodzącego, dostępną spoza klastra. Możesz dodać adnotacje , aby utworzyć wewnętrzny moduł równoważenia obciążenia i dostosować inne ustawienia modułu równoważenia obciążenia.
Sprawdź, czy utworzono element Deployment, Service, HorizontalPodAutoscaleri PodDisruptionBudget dla elementu httpbin-gateway:
kubectl get deployment httpbin-gateway-approuting-istio
kubectl get service httpbin-gateway-approuting-istio
kubectl get hpa httpbin-gateway-approuting-istio
kubectl get pdb httpbin-gateway-approuting-istio
Wysyłanie żądania do przykładowej aplikacji przy użyciu narzędzia Terraform
Poczekaj, aż Gateway zaraportuje stan Programmed, a następnie pobierz jego adres zewnętrzny:
kubectl wait --for=condition=programmed gateways.gateway.networking.k8s.io httpbin-gateway
export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -ojsonpath='{.status.addresses[0].value}')
Następnie wyślij żądanie do httpbin za pośrednictwem bramy Gateway:
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
Odpowiedź HTTP 200 powinna być widoczna.
Rejestrowanie dostępu
Implementacja interfejsu Gateway API do routingu aplikacji domyślnie włącza rejestrowanie logów dostępu Envoy we wszystkich zarządzanych zasobnikach Gateway proxy. Dzienniki dostępu są zapisywane w standardowych danych wyjściowych kontenera proxy w domyślnym formacie tekstowym usługi Envoy. Dzienniki można wyświetlić przy użyciu polecenia kubectl logs:
kubectl logs deployment/<your-gateway-name>-approuting-istio
Każde żądanie obsługiwane przez bramę tworzy wiersz dziennika zawierający szczegóły, takie jak metoda HTTP, ścieżka, kod odpowiedzi, usługa nadrzędna oraz rozmiary żądań i odpowiedzi. Ten szczegół ułatwia obserwowanie ruchu przychodzącego i rozwiązywanie problemów z routingiem bez dodatkowej konfiguracji.
Wersjonowanie i aktualizacje
Implementacja interfejsu Gateway API do routingu aplikacji wdraża i aktualizuje płaszczyznę sterowania Istio na podstawie wersji Kubernetes klastra AKS zarówno w przypadku aktualizacji wersji pomocniczych, jak i poprawek. Ten model lokalny jest zgodny z domyślnymi ustawieniami produkcyjnymi usługi AKS Automatic, w której zarządzanie cyklem życia platformy zostało zaprojektowane tak, aby ograniczyć liczbę operacji ręcznych.
Wersja Istio to maksymalna obsługiwana wersja podrzędna Istio zgodna z wersją AKS Twojego klastra. Jeśli na przykład korzystasz z usługi AKS w wersji 1.34, maksymalna obsługiwana wersja podrzędna Istio, którą można zainstalować (stan na marzec 2026 r.), to 1.28. Należy pamiętać, że maksymalna obsługiwana wersja Istio dla danej wersji Kubernetes może się różnić między klastrami Long-Term Support (LTS) a klastrami innymi niż LTS.
Aby sprawdzić maksymalną obsługiwaną podrzędną wersję Istio dla używanej wersji Kubernetes w usłudze AKS, zobacz kalendarz wydań dodatku Service Mesh. Chociaż implementacja routingu aplikacji interfejsu Gateway API nie jest wersjonowana, pomocnicza wersja płaszczyzny sterowania Istio odpowiada danej rewizji dodatku service mesh (np. dla dodatku service mesh asm-1-28, pomocnicza wersja płaszczyzny sterowania Istio dla routingu aplikacji to 1.28). Możesz również sprawdzić podrzędną wersję Istio, sprawdzając wersję poprawki w obrazie wdrożenia istiod:
kubectl get deployment istiod -n aks-istio-system -o=jsonpath="{.spec.template.spec.containers[*].image}"
Aktualizacje
Poprawki i aktualizacje wersji podrzędnych płaszczyzny sterowania Istio dla implementacji interfejsu Gateway API na potrzeby routingu aplikacji odbywają się na miejscu. Uaktualnienia wersji poprawek są wyzwalane automatycznie w ramach wydań usługi AKS. Uaktualnienia wersji mniejszej można wyzwalać automatycznie lub ręcznie w zależności od wersji AKS Kubernetes oraz terminu wydania mniejszej wersji Istio. Aktualizacje wersji podrzędnej występują w następujących scenariuszach:
- Klaster usługi AKS jest uaktualniany do nowej wersji, która ma przypiętą do niej wyższą maksymalną obsługiwaną wersję istio. Płaszczyzna sterowania Istio jest aktualizowana do nowszej wersji podrzędnej w ramach aktualizacji klastra AKS.
- Nowa wersja istio jest wydana dla usługi AKS i staje się maksymalną obsługiwaną wersją istio dla wersji klastra usługi AKS. Po wdrożeniu w Twoim regionie płaszczyzna sterowania Istio w Twoim klastrze jest automatycznie uaktualniana do nowej wersji podrzędnej. Aby śledzić nowe wydania Istio i sprawdzić, kiedy nowa wersja trafi do Twojego regionu, śledź informacje o wersjach usługi AKS i harmonogram wdrażania wersji usługi AKS.
Podczas procesu uaktualniania mogą wystąpić zakłócenia ruchu. Aby zminimalizować zakłócenia podczas uaktualnień, dodatek routingu aplikacji wdraża mechanizm Horizontal Pod Autoscaler (HPA) z minimalną liczbą dwóch replik oraz obiekt PodDisruptionBudget (PDB) z minimalną dostępnością jednej dla każdego Gateway. Możesz dostosować te zasoby , aby zmodyfikować te ustawienia.
Dostosowania zasobów
Dostosowywanie poziomego skalowania automatycznego podów (HPA) na płaszczyźnie sterowania
Implementacja interfejsu API routingu aplikacji obsługuje dostosowywanie płaszczyzny sterowania Istio Horizontal Pod Autoscaler (HPA). Zasób istiod HPA ma następujące konfiguracje domyślne:
- Minimalna replika: dwie
- Maksymalna liczba replik: pięć
- Wykorzystanie procesora CPU: 80%
Uwaga / Notatka
Aby zapobiec konfliktom z PodDisruptionBudget, implementacja interfejsu Gateway API do routingu aplikacji nie pozwala ustawić minReplicas na wartość niższą niż początkowa wartość domyślna 2.
Konfigurację HPA można modyfikować za pomocą poprawek i bezpośrednich edycji. Przykład:
kubectl patch hpa istiod -n aks-istio-system --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'
Dostosowywanie zasobów bramy
Implementacja interfejsu API bramy routingu aplikacji wspiera dostosowywanie zasobów Gateway poprzez adnotacje i ConfigMapy. Routing aplikacji używa tej samej listy dopuszczalnych dostosowań zasobów co dodatek usługi Istio dla dostosowywania zasobów API Gateway. Wykonaj kroki opisane w dokumentacji interfejsu API bramy Istio z dodatkiem, aby skonfigurować zasoby wygenerowane dla elementu Gateways i zobaczyć, które pola znajdują się na liście dozwolonych pól.
Uwaga / Notatka
Obiekt istio-gateway-class-defaults ConfigMap jest udostępniany i synchronizowany przez AKS, gdy Managed Gateway API CRD i implementacja API routingu aplikacji są jednocześnie włączone. Jeśli wcześniej samodzielnie utworzyłeś instancję ConfigMap w ramach przestrzeni nazw istio-gateway-class-defaults, musisz usunąć tę samodzielnie zarządzaną instancję ConfigMap przed włączeniem zarządzanych CRD API Gateway, aby uniknąć konfliktów z synchronizacją ConfigMap zarządzanego przez usługę AKS.
Uwaga / Notatka
Implementacja interfejsu Gateway API na potrzeby routingu aplikacji dodaje adnotacje usługi Azure Load Balancer do usługi Gateway, aby skonfigurować sondy kondycji dla domyślnego ustawienia externalTrafficPolicy „Cluster”. Jeśli ustawisz spec.externalTrafficPolicy na wartość „Local”, musisz usunąć następujące adnotacje w obiekcie ConfigMap na poziomie klasy GatewayClass lub w obiekcie ConfigMap dla poszczególnej bramy:
service: |
spec:
externalTrafficPolicy: Local
metadata:
annotations:
service.beta.kubernetes.io/port_80_health-probe_port:
service.beta.kubernetes.io/port_80_health-probe_protocol:
service.beta.kubernetes.io/port_80_health-probe_request-path:
Wyłączanie implementacji interfejsu API bramy routingu aplikacji
Uruchom następujące polecenie, aby wyłączyć implementację interfejsu API usługi Application Routing Gateway:
az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --disable-app-routing-istio
Uprzątnij zasoby
Uruchom następujące polecenia, aby usunąć zasoby Gateway i HTTPRoute:
kubectl delete gateways.gateway.networking.k8s.io httpbin-gateway
kubectl delete httproute httpbin
Jeśli utworzono obiekt ConfigMap w celu dostosowania obiektu Gateway, uruchom następujące polecenie, aby usunąć obiekt ConfigMap:
kubectl delete configmap gw-options
Jeśli utworzono obiekt SecretProviderClass i obiekt Secret do terminacji TLS, usuń następujące zasoby:
kubectl delete secret httpbin-credential
kubectl delete pod secrets-store-sync-httpbin
kubectl delete secretproviderclass httpbin-credential-spc
Czyszczenie zasobów przy użyciu narzędzia Terraform
W tej sekcji wdrożono przykładową aplikację ograniczoną do przestrzeni nazw oraz zasoby interfejsu Gateway API. Jeśli nie potrzebujesz już tych zasobów platformy Kubernetes, usuń je przed usunięciem podstawowej infrastruktury Azure.
Usuń HTTPRoute, Gateway i przykładową aplikację za pomocą polecenia kubectl delete:
kubectl delete -f httproute.yaml
kubectl delete -f gateway.yaml
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/httpbin/httpbin.yaml
Warning
Następujące polecenie usuwa grupę zasobów, klaster usługi AKS i wszystkie inne zasoby skojarzone z grupą zasobów utworzoną dla tego przykładu. Jeśli w tej grupie zasobów wdrożono inne zasoby, polecenie je również usunie.
Usuń zasoby Azure utworzone przez program Terraform przy użyciu terraform destroy polecenia . Po wyświetleniu monitu wprowadź polecenie yes , aby potwierdzić.
terraform destroy
Treści powiązane
- Czym jest Azure Kubernetes Service (AKS) Automatic?
- Utwórz klaster automatyczny AKS
- Konfigurowanie Azure DNS i protokołu TLS przy użyciu implementacji interfejsu API routingu aplikacji
- Zabezpieczanie ruchu przychodzącego przy użyciu implementacji interfejsu API usługi Application Routing Gateway (konfiguracja ręczna)