Configurar a entrada com a API do Gateway do Kubernetes por meio de complemento de roteamento de aplicativos para o Serviço de Kubernetes do Azure (AKS)

O complemento de roteamento de aplicativos dá suporte à API de Gateway do Kubernetes para gerenciamento de tráfego de entrada. A API de Gateway do Kubernetes é um conjunto de recursos que fornece uma estrutura padronizada, orientada para funções e extensível para gerenciamento de tráfego, projetada para ser uma sucessora e evolução da API de Ingress. Assim, a implementação da API de Gateway de roteamento de aplicações tem o objetivo de substituir o complemento NGINX gerenciado, que se baseia na API Ingress legada e deixará de receber suporte do Azure após novembro de 2026. Se você estiver usando o NGINX gerenciado, deverá migrar para a implementação da API de Gateway de roteamento de aplicativos ou outra implementação com suporte até novembro de 2026.

Para cargas de trabalho de produção, esse modelo é o modelo de entrada padrão recomendado no AKS Automatic. A partir do AKS versão 1.36, os novos clusters automáticos do AKS usam a API do Gateway do Kubernetes por meio do complemento de roteamento de aplicativos por padrão. Para obter informações sobre os padrões de produção automática do AKS, consulte O que é AKS (Serviço de Kubernetes do Azure) Automático?

Comparação com o complemento Istio Service Mesh

A implementação da API do Kubernetes do Gateway, um complemento de roteamento de aplicativos, implanta um plano de controle Istio para gerenciar a infraestrutura dos recursos da API do Kubernetes do Gateway. No entanto, difere do complemento de malha de serviço do Istio para o AKS das seguintes maneiras:

Característica API de Roteamento de Aplicações do Gateway Complemento da malha de serviço do Istio
Nome da classe de gateway approuting-istio istio
Injeção de sidecar e suporte ao Istio CRD Sem suporte. Gerencia apenas a infraestrutura para recursos da API de Gateway do Kubernetes Supported
Revisão e atualizações Não revisado. Atualizado no local para atualizações de versão secundárias e de correção Revisado. Atualizado por meio de atualizações canárias para atualizações de versão secundária e no local para atualizações de versão patch

Quando usar a API do Gateway de roteamento de aplicativos em produção

Use essa implementação como o caminho de entrada padrão quando desejar:

  • Um padrão de entrada gerenciada e pronta para produção no AKS Automático.
  • Entrada HTTP/HTTPS nativa da API do Gateway do Kubernetes.
  • Infraestrutura de gateway gerenciado com proteções operacionais internas, como dimensionamento automático e orçamentos disruptivos nos proxies de gateway.

Considere alternativas quando você precisar de recursos fora do suporte atual neste artigo, como:

  • Gerenciamento de tráfego de malha de serviço.
  • Recursos listados em Limitações.

Limitações

  • Você não pode configurar os limites de tamanho do cabeçalho e do corpo da solicitação, scripts Lua nem a limitação de taxa local e global por meio dessa implementação. A API do Gateway não tem campos padrão para esses recursos e a implementação da API do Gateway de Roteamento de Aplicativos não dá suporte EnvoyFilter.

    Se você precisar desses recursos ao migrar do ingress-nginx, considere o Gateway API ingress com o complemento de malha de serviço do Istio. Você pode usar Gateway, HTTPRoute e outros recursos da API do Gateway sem injetar sidecars em suas cargas de trabalho e aplicar um EnvoyFilter com escopo de gateway para configurá-los. Os problemas causados pela configuração EnvoyFilternão são cobertos pelo suporte do Azure. Se você escolher o complemento de malha de serviço Istio, deverá iniciar e concluir upgrades canário para atualizações de revisão secundária, mesmo ao usá-lo apenas para ingress.

    Teste cada substituição de uma anotação do Nginx ou de um trecho de código com sua revisão do Istio. Por exemplo, o filtro de buffer do Envoy impõe um limite de tamanho do corpo mantendo o corpo da solicitação completo na memória antes de encaminhá-lo. Não há vazamento para disco.

  • Você não pode habilitar a implementação do Gateway API de roteamento de aplicativos e o complemento de malha de serviço Istio ao mesmo tempo. Você deve desabilitar um primeiro e habilitar o outro em uma operação separada. Ao fazer a transição do complemento de malha de serviço Istio para a implementação da API de Gateway do roteamento de aplicativos, você deve excluir a GatewayClass do Istio e os CRDs do Istio após desabilitar o complemento Istio. O complemento do Istio instala CRDs (como virtualservices.networking.istio.io, destinationrules.networking.istio.io e outros nos grupos de API networking.istio.io, security.istio.io, telemetry.istio.io e extensions.istio.io) que não são removidos quando o complemento é desativado. Se esses CRDs permanecerem no cluster, o plano de controle Istio da API de Gateway do roteamento de aplicativos falha ao ser iniciado. Execute o seguinte comando para excluí-los:

    kubectl delete crd $(kubectl get crd -o name | grep -E 'istio\.io')
    kubectl delete gatewayclass istio
    

    Observação

    Se você tiver recursos personalizados do Istio existentes (como VirtualServices ou DestinationRules), excluir os CRDs também excluirá esses recursos. Verifique se você não precisa mais deles antes de continuar.

  • A implementação da API do Gateway de roteamento de aplicativos usa a mesma lista de autorização de personalização de recursos que o complemento do Istio destinado a validar personalizações do ConfigMap para os recursos Gateway. Webhooks gerenciados por add-ons bloqueiam personalizações que não estão na lista de permissões.

  • Não há suporte para o gerenciamento de tráfego de saída por meio da implementação da API de Gateway de roteamento de aplicativos.

  • Não há suporte oficial para a injeção de sidecars não gerenciados pela Microsoft (por exemplo, telemetria personalizada, coleta de logs ou agentes de segurança) nos pods de proxy de gateway do Istio gerenciados pelo complemento de roteamento de aplicativos. Se você optar por injetar seu próprio sidecar em um pod de proxy gerenciado, a Microsoft fornecerá apenas suporte em regime de melhor esforço para quaisquer problemas encontrados.

  • O log de acesso do Envoy é habilitado por padrão nos pods de proxy do Gateway, mas o formato do log, o escopo e o provedor não podem ser personalizados pela API Telemetry do Istio. Para personalizar, use a entrada de API do Gateway no complemento de malha de serviço do Istio em vez disso.

Pré-requisitos

Atualizar a versão da CLI do Azure

Você deve usar azure-cli versão 2.86.0 ou superior. Execute az --version para localizar sua azure-cli versão e execute az upgrade para atualizar.

Habilitar CRDs da API do Gateway Gerenciado

Habilite a instalação da API do Gateway Gerenciado. O uso de CRDs da API do Gateway autogerenciados com o complemento de roteamento de aplicativos não é compatível.

Comportamento padrão automático do AKS (AKS 1.36 e posterior)

Em novos clusters automáticos do AKS que executam o AKS 1.36 ou posterior, a API do Gateway do Kubernetes por meio do complemento de roteamento de aplicativos é habilitada por padrão.

Normalmente, você não precisa executar o comando de habilitação de recursos, a menos que seja:

  • Usando um cluster existente.
  • Executando uma versão anterior do AKS.
  • Reinserindo o recurso depois de desabilitá-lo.

Habilitar a implementação da API do Gateway de roteamento de aplicativos

Observação

Se você criar um novo cluster automático do AKS no AKS 1.36 ou posterior, esse recurso será habilitado por padrão. Use os comandos nesta seção para clusters padrão do AKS, versões anteriores ou clusters existentes que ainda não têm o recurso habilitado.

Habilitar durante a criação do cluster

Execute o seguinte comando para habilitar a implementação da API do Gateway de roteamento de aplicativos durante a criação do cluster Padrão do AKS:

# 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

Habilitar para um cluster existente

Execute o seguinte comando para habilitar a implementação da API de Gateway de roteamento de aplicativos para um cluster existente:

# 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

Você deve visualizar pods istiod no namespace aks-istio-system:

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

Você também deve ver o ValidatingWebhookConfiguration ser implantado:

kubectl get validatingwebhookconfiguration
NAME                                        WEBHOOKS   AGE
aks-node-validating-webhook                 1          117m
azure-service-mesh-ccp-validating-webhook   1          4m2s

Se você tiver a instalação da API do Gateway Gerenciado habilitada, também deverá ver o ConfigMap de personalização do gateway Istio ser criado automaticamente:

kubectl get cm -n aks-istio-system
NAME                                  DATA   AGE
...
istio-gateway-class-defaults          2      43s
...

Configurar a entrada usando um Gateway do Kubernetes

Implantar um aplicativo de exemplo

Primeiro, implante o aplicativo de exemplo httpbin no default namespace:

export ISTIO_RELEASE="release-1.27"
kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_RELEASE/samples/httpbin/httpbin.yaml

Criar o Gateway do Kubernetes e o HTTPRoute

Em seguida, implante uma configuração de API de Gateway na namespace default com o gatewayClassName definido para approuting-istio.

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

Observação

O exemplo acima cria um serviço de balanceador de carga de entrada externo acessível de fora do cluster. Você pode adicionar anotações para criar um balanceador de carga interno e personalizar outras configurações do balanceador de carga.

Observação

Por padrão, o plano de controle do Istio acrescentará o GatewayClass nome approuting-istio ao nome dos recursos que ele provisiona para o Gateway. Você pode anotar o seu recurso Gateway com gateway.istio.io/name-override para sobrescrever o nome dos recursos provisionados. Os nomes de recurso devem ser menores que 63 caracteres e devem ser um nome DNS válido.

Verifique se Deployment, Service, HorizontalPodAutoscaler, e PodDisruptionBudget sejam criados para 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

Enviar solicitação para um aplicativo de exemplo

Por fim, tente enviar uma curl solicitação para o httpbin aplicativo. Primeiro, defina a variável de INGRESS_HOST ambiente:

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}')

Em seguida, tente enviar uma solicitação HTTP para httpbin:

curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

Você deve ver uma HTTP 200 resposta.

Observação

Para proteger o tráfego de entrada com a implementação da API de Gateway de roteamento de aplicativos e integrar com DNS do Azure para gerenciamento de nome de host, consulte Configurar DNS do Azure e TLS com a implementação da API de Gateway de roteamento de aplicativos para o fluxo de trabalho automatizado alimentado pelo operador de roteamento de aplicativos. Para um fluxo de trabalho manual de terminação TLS que não depende da integração do operador, consulte Proteger o tráfego de entrada com a implementação da API de roteamento de aplicativos do Gateway.

Para usar o Terraform para criar um cluster do AKS com a implementação da API de Gateway de roteamento de aplicativos habilitada, você precisa:

  • Terraform versão 1.9.0 ou posterior instalado.
  • CLI do Azure instalada e autenticada. Execute az --version para localizar sua azure-cli versão e execute az upgrade para atualizar. Use o CLI do Azure para se conectar ao cluster depois que o Terraform o criar.
  • kubectl instalado. Você pode instalá-lo localmente usando o az aks install-cli comando. Você usa kubectl para implantar o aplicativo de exemplo e os recursos da API de Gateway.

Implantar um cluster AKS com a implementação da API Gateway para roteamento de aplicativos usando o Terraform

Esta seção mostra como usar o Terraform para implantar um cluster do AKS com a instalação gerenciada da API de Gateway e a implementação da API de Gateway para roteamento de aplicações habilitadas.

Observação

O código de exemplo desta seção está localizado no repositório Azure Terraform GitHub. Você pode exibir o arquivo de log que contém os resultados dos testes das versões atuais e anteriores do Terraform.

Veja mais artigos e exemplos de código mostrando como usar o Terraform para gerenciar recursos do Azure.

Este exemplo implanta:

  • Um grupo de recursos.
  • Um cluster do AKS que usa o plug-in de rede CNI Azure e um balanceador de carga padrão.
  • A instalação da API do Gateway Gerenciado e a implementação da API do Gateway de roteamento de aplicativos, ambas habilitadas no cluster por meio do provedor AzAPI. Habilitar ambas as configurações disponibiliza o GatewayClass approuting-istio gerenciado pelo AKS no cluster.
  1. Crie um diretório para testar e executar o código terraform de exemplo e torná-lo o diretório atual.

  2. Crie um arquivo chamado main.tf, depois insira o código a seguir:

    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. Inicialize o Terraform executando o terraform init comando. Esse comando baixa os provedores de Azure necessários para gerenciar Azure recursos com o Terraform.

    terraform init
    
  4. Formate e valide a configuração executando os comandos terraform validate e terraform fmt.

    terraform fmt
    terraform validate
    
  5. Crie um plano de execução do Terraform executando o terraform plan comando. Este comando mostra os recursos que o Terraform cria ou modifica em sua assinatura Azure.

    terraform plan
    
  6. Aplique o plano de execução do Terraform executando o terraform apply comando. Esse comando cria os recursos definidos em seu main.tf arquivo em sua assinatura Azure. Quando solicitado, insira yes para confirmar.

    terraform apply
    

Conectar-se ao cluster do AKS usando o Terraform

  1. Obtenha os nomes do grupo de recursos e do cluster a partir das saídas do Terraform.

    terraform output -raw resource_group_name
    terraform output -raw cluster_name
    
  2. Configure kubectl para se conectar ao seu cluster usando o comando az aks get-credentials. Este comando baixa as credenciais e configura a CLI do Kubernetes para usá-las. Substitua <resource-group-name> e <cluster-name> pelos valores das etapas anteriores. Como alternativa, execute terraform output -raw get_credentials_command para obter o comando completo pronto para execução.

    az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
    
  3. Verifique se o cluster está em execução executando o kubectl get nodes comando.

    kubectl get nodes
    

Verificar a configuração da API do Gateway usando o Terraform

  1. Confirme se os istiod pods estão em execução no aks-istio-system namespace.

    kubectl get pods -n aks-istio-system
    
  2. Confirme se o approuting-istio GatewayClass existe e é aceito.

    kubectl get gatewayclass
    

    O approuting-istio GatewayClass deve retornar True na ACCEPTED coluna.

Configurar a entrada usando um Gateway do Kubernetes com o Terraform

Implantar o aplicativo de exemplo usando o Terraform

Implante o aplicativo de exemplo httpbin no default namespace:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/httpbin/httpbin.yaml

Verifique se o httpbin pod e o serviço estão disponíveis:

kubectl get pods -l app=httpbin
kubectl get svc httpbin

Criar os recursos de Gateway e HTTPRoute usando o Terraform

O exemplo de implementação da Gateway API para roteamento de aplicativos inclui um manifesto Gateway que cria um listener HTTP na porta 80 e usa a GatewayClass approuting-istio gerenciada pelo AKS.

  1. Crie um arquivo chamado gateway.yaml, depois insira o código a seguir:

    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. Aplique a Gateway configuração:

    kubectl apply -f gateway.yaml
    

    O exemplo também inclui um manifesto HTTPRoute que roteia solicitações para httpbin.example.com/get para o serviço httpbin na porta 8000.

  3. Crie um arquivo chamado httproute.yaml, depois insira o código a seguir:

    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. Aplique a HTTPRoute configuração:

    kubectl apply -f httproute.yaml
    

Observação

O exemplo anterior cria um serviço de balanceador de carga de entrada externo acessível de fora do cluster. Você pode adicionar anotações para criar um balanceador de carga interno e personalizar outras configurações do balanceador de carga.

Verifique se Deployment, Service, HorizontalPodAutoscaler, e PodDisruptionBudget sejam criados para 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

Enviar uma solicitação para o aplicativo de exemplo usando o Terraform

Aguarde até que o Gateway relate uma Programmed condição e, em seguida, obtenha seu endereço externo:

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}')

Em seguida, envie uma solicitação para httpbin por meio do Gateway:

curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

Você deve ver uma HTTP 200 resposta.

Registro de acesso

A implementação da API Gateway para roteamento de aplicativos habilita, por padrão, o registro de logs de acesso do Envoy em todos os pods de proxy Gateway gerenciados. Os logs de acesso são gravados na saída padrão do contêiner de proxy no formato de texto padrão do Envoy. Você pode exibir os logs usando kubectl logs:

kubectl logs deployment/<your-gateway-name>-approuting-istio

Cada solicitação que o gateway manipula produz uma linha de log contendo detalhes como o método HTTP, o caminho, o código de resposta, o serviço upstream e os tamanhos de solicitação e resposta. Esse detalhe facilita a observação do tráfego de entrada e solução de problemas de roteamento sem nenhuma configuração adicional.

Controle de versão e atualizações

A implementação da API do Gateway de roteamento de aplicativos implanta e atualiza o plano de controle do Istio com base na versão do Kubernetes do cluster do AKS, tanto para atualizações de versão secundária quanto para atualizações de versão de patch. Esse modelo in-loco está alinhado às configurações padrão de produção do AKS Automático, em que o gerenciamento de ciclo de vida da plataforma foi projetado para reduzir as intervenções manuais.

A versão do Istio é a versão secundária máxima do Istio compatível com a sua versão do AKS do cluster. Por exemplo, se você estiver na versão 1.34do AKS, a versão secundária máxima do Istio instalada e suportada (a partir de março de 2026) é 1.28. Tenha em mente que a versão máxima do Istio compatível com uma determinada versão do Kubernetes pode ser diferente entre os clusters de Suporte de Longo Prazo (LTS) e os clusters não LTS.

Para encontrar a versão secundária máxima do Istio compatível com a sua versão do Kubernetes no AKS, consulte o calendário de lançamentos do complemento de malha de serviço. Embora a implementação da API do Gateway de roteamento de aplicativos não seja versionada, a versão secundária do plano de controle do Istio corresponde à revisão do complemento de malha de serviço (exemplo: para o complemento de malha de serviço asm-1-28, a versão secundária do plano de controle do Istio para roteamento de aplicativos seria 1.28). Você também pode ver a versão menor do Istio verificando a versão de patch na imagem de implantação do istiod:

kubectl get deployment istiod -n aks-istio-system -o=jsonpath="{.spec.template.spec.containers[*].image}"

Atualizações

As atualizações de versão de patch e de versão secundária do plano de controle do Istio para a implementação da API do Gateway de roteamento de aplicativos ocorrem in-loco. As atualizações de patch são acionadas automaticamente como parte dos lançamentos do AKS. Atualizações de versões menores podem ser disparadas automaticamente ou manualmente, dependendo da versão do Kubernetes do AKS e do cronograma de lançamentos das versões menores do Istio. As atualizações de versão secundária ocorrem nos seguintes cenários:

  • O cluster do AKS foi atualizado para uma nova versão que possui uma versão máxima do Istio suportada mais alta. O plano de controle do Istio é atualizado para a versão secundária posterior como parte da atualização do cluster do AKS.
  • Uma nova versão do Istio é lançada para o AKS e se torna a versão máxima do Istio com suporte para a versão do cluster do AKS. Após a distribuição para sua região, o plano de controle do Istio em seu cluster é atualizado automaticamente para a nova versão secundária. Para acompanhar as novas versões do Istio e ver quando a nova versão é lançada para sua região, siga as notas de versão do AKS e o rastreador de versão do AKS.

Interrupções de tráfego podem ocorrer durante o processo de atualização. Para minimizar interrupções durante atualizações, o complemento de roteamento de aplicativos implanta um Dimensionador Automático de Pod Vertical (HPA) com no mínimo duas réplicas e um PodDisruptionBudget (PDB) com disponibilidade mínima de um para cada Gateway. Você pode personalizar esses recursos para modificar essas configurações.

Personalizações de recursos

Personalização do dimensionamento automático horizontal do pod (HPA) do plano de controle

A implementação da API do Gateway de roteamento de aplicativos oferece suporte à personalização do Dimensionador Automático de Pod Horizontal (HPA) do plano de controle do Istio. O istiod recurso HPA tem as seguintes configurações padrão:

  • Réplicas mínimas: Duas
  • Réplicas máximas: cinco
  • Utilização da CPU: 80%

Observação

Para evitar conflitos com o PodDisruptionBudget, a implementação da API Gateway de roteamento de aplicativos não permite definir o minReplicas para um valor inferior ao padrão inicial de 2.

A configuração de HPA pode ser modificada por meio de patches e edições diretas. Exemplo:

kubectl patch hpa istiod -n aks-istio-system --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

Personalização de recursos do gateway

A implementação da API do Gateway de roteamento de aplicativos oferece suporte à personalização dos recursos Gateway por meio de anotações e ConfigMaps. O roteamento de aplicativos usa a mesma lista de permissões de personalização de recursos que o complemento de malha de serviço do Istio para personalização de recursos da API do Gateway. Siga as etapas nos documentos da API do Gateway de complemento do Istio para configurar os recursos gerados para o Gateways e para ver quais campos se enquadram na lista de permissões.

Observação

O ConfigMap istio-gateway-class-defaults é provisionado e reconciliado pelo AKS quando os CRDs da API do Gateway Gerenciado e a implementação da API do Gateway de Roteamento de Aplicativos estão habilitados em conjunto. Se você criou anteriormente o ConfigMap istio-gateway-class-defaults no namespace aks-istio-system por conta própria, deverá excluir a instância autogerenciada do ConfigMap antes de habilitar os CRDs da Managed Gateway API, para evitar conflitos com a reconciliação do ConfigMap gerenciado pelo AKS.

Observação

A implementação da API Gateway de roteamento de aplicativos adiciona anotações do Azure Load Balancer ao Serviço Gateway para configurar investigações de integridade para a configuração externalTrafficPolicy padrão "Cluster". Se você definir spec.externalTrafficPolicy como "Local", deverá remover as seguintes anotações no ConfigMap no nível de GatewayClass ou no ConfigMap por gateway:

 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:

Desabilitar a implementação da API do Gateway de roteamento de aplicativos

Execute o seguinte comando para desabilitar a implementação da API do Gateway de roteamento de aplicativos:

az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --disable-app-routing-istio

Limpar os recursos

Execute os seguintes comandos para excluir os recursos Gateway e HTTPRoute:

kubectl delete gateways.gateway.networking.k8s.io httpbin-gateway
kubectl delete httproute httpbin

Se você criou um ConfigMap para personalizar seu Gateway, execute o seguinte comando para excluir o ConfigMap:

kubectl delete configmap gw-options

Se você criou um SecretProviderClass e um segredo para usar para terminação TLS, exclua os seguintes recursos:

kubectl delete secret httpbin-credential
kubectl delete pod secrets-store-sync-httpbin
kubectl delete secretproviderclass httpbin-credential-spc

Limpar recursos usando o Terraform

Nesta seção, você implantou um aplicativo de exemplo com escopo de namespace e recursos de API de Gateway. Se você não precisar mais desses recursos do Kubernetes, exclua-os antes de remover a infraestrutura de Azure subjacente.

Exclua o HTTPRoute, o Gateway e o aplicativo de exemplo usando o comando 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

O comando a seguir remove o grupo de recursos, o cluster do AKS e todos os outros recursos associados ao grupo de recursos criado para este exemplo. Se você implantou outros recursos dentro desse grupo de recursos, o comando os excluirá também.

Remova os recursos de Azure criados pelo Terraform usando o terraform destroy comando. Quando solicitado, insira yes para confirmar.

terraform destroy