Konfigurowanie ruchu przychodzącego przy użyciu interfejsu Gateway API platformy Kubernetes za pomocą dodatku routingu aplikacji dla 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:

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:

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, HTTPRoute oraz innych zasobów Gateway API bez wstrzykiwania sidecarów do swoich obciążeń roboczych oraz zastosować element EnvoyFilter o zakresie bramy, aby je skonfigurować. Problemy spowodowane konfiguracją EnvoyFilter znajdują 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.io i inne w grupach API networking.istio.io, security.istio.io, telemetry.istio.io i extensions.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 istio
    

    Uwaga / 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 Gateway zasobó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.0 programu Terraform lub nowszą.
  • Zainstalowany i uwierzytelniony Azure CLI. Uruchom polecenie az --version , aby znaleźć swoją azure-cli wersję i uruchomić az upgrade polecenie , 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-cli polecenia . Używasz kubectl, 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.

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-istio GatewayClass jest dostępna w klastrze.
  1. Utwórz katalog, aby przetestować i uruchomić przykładowy kod narzędzia Terraform, a następnie ustaw go jako bieżący katalog.

  2. 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"
    }
    
  3. 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 init
    
  4. Sformatuj i zweryfikuj konfigurację, uruchamiając polecenia terraform fmt i terraform validate.

    terraform fmt
    terraform validate
    
  5. Utwórz plan wykonywania narzędzia Terraform, uruchamiając terraform plan polecenie . To polecenie pokazuje zasoby tworzone lub modyfikowane przez program Terraform w ramach subskrypcji Azure.

    terraform plan
    
  6. Zastosuj plan wykonania Terraform, uruchamiając polecenie terraform apply. To polecenie tworzy zasoby zdefiniowane w main.tf pliku w subskrypcji Azure. Po wyświetleniu monitu wprowadź polecenie yes , aby potwierdzić.

    terraform apply
    

Nawiązywanie połączenia z klastrem usługi AKS przy użyciu narzędzia Terraform

  1. Pobierz nazwy grup zasobów i klastrów z danych wyjściowych programu Terraform.

    terraform output -raw resource_group_name
    terraform output -raw cluster_name
    
  2. Skonfiguruj kubectl, aby połączyć się z klastrem za pomocą polecenia az 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ć polecenie terraform 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>
    
  3. Sprawdź, czy klaster jest uruchomiony, uruchamiając kubectl get nodes polecenie .

    kubectl get nodes
    

Weryfikowanie konfiguracji interfejsu API bramy przy użyciu narzędzia Terraform

  1. Upewnij się, że pody istiod działają w przestrzeni nazw aks-istio-system.

    kubectl get pods -n aks-istio-system
    
  2. Upewnij się, że klasa approuting-istio GatewayClass istnieje i została zaakceptowana.

    kubectl get gatewayclass
    

    Klasa approuting-istio GatewayClass powinna zwracać wartość True w kolumnie ACCEPTED.

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.

  1. 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: Same
    
  2. Zastosuj konfigurację Gateway :

    kubectl apply -f gateway.yaml
    

    Przykład zawiera także manifest HTTPRoute, który kieruje żądania dla httpbin.example.com/get do usługi httpbin na porcie 8000.

  3. 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: 8000
    
  4. Zastosuj 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