Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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,HTTPRoutee outros recursos da API do Gateway sem injetar sidecars em suas cargas de trabalho e aplicar umEnvoyFiltercom escopo de gateway para configurá-los. Os problemas causados pela configuraçãoEnvoyFilternã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.ioe outros nos grupos de APInetworking.istio.io,security.istio.io,telemetry.istio.ioeextensions.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 istioObservaçã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
Telemetrydo 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.0ou posterior instalado. - CLI do Azure instalada e autenticada. Execute
az --versionpara localizar suaazure-cliversão e executeaz upgradepara 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-clicomando. Você usakubectlpara 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-istiogerenciado pelo AKS no cluster.
Crie um diretório para testar e executar o código terraform de exemplo e torná-lo o diretório atual.
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" }Inicialize o Terraform executando o
terraform initcomando. Esse comando baixa os provedores de Azure necessários para gerenciar Azure recursos com o Terraform.terraform initFormate e valide a configuração executando os comandos
terraform validateeterraform fmt.terraform fmt terraform validateCrie um plano de execução do Terraform executando o
terraform plancomando. Este comando mostra os recursos que o Terraform cria ou modifica em sua assinatura Azure.terraform planAplique o plano de execução do Terraform executando o
terraform applycomando. Esse comando cria os recursos definidos em seumain.tfarquivo em sua assinatura Azure. Quando solicitado, insirayespara confirmar.terraform apply
Conectar-se ao cluster do AKS usando o Terraform
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_nameConfigure
kubectlpara se conectar ao seu cluster usando o comandoaz 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, executeterraform output -raw get_credentials_commandpara obter o comando completo pronto para execução.az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>Verifique se o cluster está em execução executando o
kubectl get nodescomando.kubectl get nodes
Verificar a configuração da API do Gateway usando o Terraform
Confirme se os
istiodpods estão em execução noaks-istio-systemnamespace.kubectl get pods -n aks-istio-systemConfirme se o
approuting-istioGatewayClass existe e é aceito.kubectl get gatewayclassO
approuting-istioGatewayClass deve retornarTruenaACCEPTEDcoluna.
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.
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: SameAplique a
Gatewayconfiguração:kubectl apply -f gateway.yamlO exemplo também inclui um manifesto
HTTPRouteque roteia solicitações parahttpbin.example.com/getpara o serviçohttpbinna porta8000.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: 8000Aplique a
HTTPRouteconfiguraçã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
Conteúdo relacionado
- O que é AKS (Serviço de Kubernetes do Azure) Automático?
- Criar um cluster automático do AKS
- Configurar o DNS do Azure e o TLS com a implementação da API do Gateway de Roteamento de Aplicativos
- Proteger o tráfego de entrada com a implementação da API do Gateway de roteamento de aplicativos (configuração manual)