Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El complemento de enrutamiento de aplicaciones admite la API de puerta de enlace de Kubernetes para la administración del tráfico de entrada. La API de Gateway de Kubernetes es un conjunto de recursos que proporcionan un marco estandarizado, orientado a roles y extensible para la administración del tráfico, diseñado para ser sucesor y evolución de la API de Ingress. Por lo tanto, la implementación de la API de enrutamiento del Gateway de aplicaciones tiene como objetivo servir como sucesor del complemento NGINX administrado, que se basa en la API de Ingress heredada y no recibirá soporte de Azure después de noviembre de 2026. Si usa NGINX administrado, debe migrar a la implementación de la API de gateway de enrutamiento de aplicaciones u otra implementación compatible, para noviembre de 2026.
En el caso de las cargas de trabajo de producción, este modelo es el modelo de entrada predeterminado recomendado en AKS Automatic. A partir de la versión 1.36 de AKS, los nuevos clústeres automáticos de AKS usan la API de puerta de enlace de Kubernetes mediante el complemento de enrutamiento de aplicaciones de forma predeterminada. Para obtener información general sobre los valores predeterminados para producción de AKS Automatic, consulte ¿Qué es Azure Kubernetes Service (AKS) Automatic?
Comparación con el complemento de malla de servicios Istio
La implementación del complemento de enrutamiento de aplicaciones de la API de puerta de enlace de Kubernetes despliega un plano de control de Istio para gestionar la infraestructura de los recursos de la API de puerta de enlace de Kubernetes. Sin embargo, difiere del complemento de malla de servicio Istio para AKS de las siguientes maneras:
| Feature | API Gateway de enrutamiento de aplicaciones | Complemento de malla de servicio de Istio |
|---|---|---|
| Nombre de clase del gateway | approuting-istio |
istio |
| Inyección de Sidecar y compatibilidad con CRD de Istio | No está soportado. Solo administra la infraestructura de los recursos de la API de puerta de enlace de Kubernetes. | Soportado |
| Revisión y actualizaciones | No revisado. Actualización local tanto para versiones secundarias como para versiones de parches | Revisado. Actualizado a través de actualizaciones controladas para las actualizaciones de versiones menores y locales para las actualizaciones de la versión de parches |
Cuándo usar la API de puerta de enlace de enrutamiento de aplicaciones en producción
Use esta implementación como ruta de acceso de entrada predeterminada cuando desee:
- Valor predeterminado de entrada administrada listo para producción en AKS Automatic.
- Entrada HTTP/HTTPS nativa de la API de pasarela de Kubernetes.
- Infraestructura de puerta de enlace administrada con medidas de seguridad operativas integradas, como el escalado automático y los presupuestos de interrupciones en servidores proxy de puerta de enlace.
Tenga en cuenta alternativas cuando necesite funcionalidades fuera de la compatibilidad actual en este artículo, como:
- Gestión del tráfico de la malla de servicios.
- Características enumeradas en Limitaciones.
Limitaciones
No se pueden configurar límites de tamaño de encabezado y cuerpo de solicitud, scripts de Lua ni limitación de velocidad local y global a través de esta implementación. La API de puerta de enlace no tiene campos estándar para estas características y la implementación de la API de puerta de enlace de enrutamiento de aplicaciones no admite
EnvoyFilter.Si necesita estas características al migrar desde ingress-nginx, considere el ingress de Gateway API con el complemento de malla de servicios Istio. Puede usar
Gateway,HTTPRoutey otros recursos de API Gateway sin inyectar sidecars en sus cargas de trabajo, y aplicar unEnvoyFiltercon ámbito de puerta de enlace para configurarlos. Los problemas causados por la configuración deEnvoyFilterestán fuera del soporte de Azure. Si elige el complemento de malla de servicios de Istio, debe iniciar y completar actualizaciones canarias para las actualizaciones de revisión menor, incluso cuando lo utilice únicamente para el ingreso.Pruebe cada reemplazo de una anotación o fragmento de código nginx en la revisión de Istio. Por ejemplo, el filtro de búfer de Envoy aplica un límite de tamaño de cuerpo manteniendo el cuerpo de la solicitud completa en la memoria antes de reenviarlo. No se derrama en el disco.
No se pueden habilitar al mismo tiempo la implementación de la API de Gateway de enrutamiento de aplicaciones y el complemento de malla de servicios de Istio. Debe deshabilitar uno primero y luego habilitar el otro como parte de una operación por separado. Al realizar la transición desde el complemento de malla de servicio de Istio a la implementación de la API de puerta de enlace de enrutamiento de aplicaciones, debe eliminar la GatewayClass de Istio y los CRD de Istio después de deshabilitar el complemento de Istio. El complemento de Istio instala las CRD (como
virtualservices.networking.istio.io,destinationrules.networking.istio.ioy otras en los grupos de APInetworking.istio.io,security.istio.io,telemetry.istio.ioyextensions.istio.io) que no se eliminan cuando se deshabilita el complemento. Si estos CRD permanecen en el clúster, el plano de control de Istio de la API de la puerta de enlace de enrutamiento de aplicaciones no se puede iniciar. Ejecute el siguiente comando para eliminarlos:kubectl delete crd $(kubectl get crd -o name | grep -E 'istio\.io') kubectl delete gatewayclass istioNota:
Si tiene recursos personalizados de Istio existentes (como VirtualServices o DestinationRules), la eliminación de los CRD también elimina esos recursos. Asegúrese de que ya no los necesita antes de continuar.
La implementación de la API de puerta de enlace de enrutamiento de aplicaciones usa la misma lista de permitidos de personalización de recursos que el complemento Istio para validar las personalizaciones de ConfigMap para los recursos
Gateway. Los webhooks gestionados por los complementos bloquean las personalizaciones que no están en la lista de elementos permitidos.No se admite la gestión del tráfico de salida a través de la implementación de Gateway API para el enrutamiento de aplicaciones.
No se admite oficialmente la inyección de sidecars no administrados por Microsoft (por ejemplo, telemetría personalizada, registro o agentes de seguridad) en los pods del proxy de puerta de enlace de Istio administrados por el complemento de enrutamiento de aplicaciones. Si decide inyectar su propio sidecar en un pod proxy administrado, Microsoft solo ofrece soporte limitado para cualquier problema que encuentre.
El registro de acceso de Envoy está habilitado de forma predeterminada en los pods del proxy de la puerta de enlace, pero el formato del registro, el alcance y el proveedor no se pueden personalizar mediante la API de Istio
Telemetry. Para personalizarlo, use en su lugar la entrada de la API de la puerta de enlace en el complemento de malla de servicios Istio.
Prerrequisitos
Actualización de la versión de la CLI de Azure
Debe usar azure-cli la versión 2.86.0 o superior. Ejecute az --version para buscar la azure-cli versión y ejecute az upgrade para actualizar.
Habilitar las CRD de la API de gateway administrado
Active la instalación de la API de puerta de enlace administrada. No se admite el uso de las CRD de la API de puerta de enlace autoadministradas con el complemento de enrutamiento de aplicaciones.
Comportamiento predeterminado automático de AKS (AKS 1.36 y versiones posteriores)
En los nuevos clústeres de AKS Automatic que ejecutan AKS 1.36 o posterior, la API de puerta de enlace de Kubernetes a través del complemento de enrutamiento de aplicaciones está habilitada de forma predeterminada.
Normalmente no es necesario ejecutar el comando de habilitación de características a menos que sea:
- Uso de un clúster existente.
- Uso de una versión anterior de AKS.
- Vuelva a habilitar la característica después de deshabilitarla.
Habilitar la implementación de la API de Gateway para el enrutamiento de aplicaciones
Nota:
Si crea un nuevo clúster automático de AKS en AKS 1.36 o posterior, esta característica está habilitada de forma predeterminada. Use los comandos de esta sección para los clústeres estándar de AKS, versiones anteriores o clústeres existentes que aún no tienen habilitada la característica.
Habilitar durante la creación del clúster
Ejecute el siguiente comando para habilitar la implementación de la API de puerta de enlace de enrutamiento de aplicaciones durante la creación del clúster estándar de 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 un clúster existente
Ejecute el siguiente comando para habilitar la implementación de la API de gateway de enrutamiento de aplicaciones para un clúster 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
Debería ver los pods istiod en el espacio de nombres 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
También debería observar que ValidatingWebhookConfiguration se ha implementado:
kubectl get validatingwebhookconfiguration
NAME WEBHOOKS AGE
aks-node-validating-webhook 1 117m
azure-service-mesh-ccp-validating-webhook 1 4m2s
Si tiene habilitada la instalación de la API de puerta de enlace administrada, también debería observar que el ConfigMap de personalización de la puerta de enlace de Istio se ha creado:
kubectl get cm -n aks-istio-system
NAME DATA AGE
...
istio-gateway-class-defaults 2 43s
...
Configurar ingreso usando un Gateway de Kubernetes
Implementación de una aplicación de ejemplo
En primer lugar, despliegue la aplicación httpbin de ejemplo en el espacio de nombres default.
export ISTIO_RELEASE="release-1.27"
kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_RELEASE/samples/httpbin/httpbin.yaml
Creación de una puerta de enlace de Kubernetes y HTTPRoute
A continuación, implemente una configuración de API de puerta de enlace en el espacio de nombres default con el gatewayClassName establecido en 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
Nota:
En el ejemplo anterior se crea un servicio de equilibrador de carga de entrada externo al que se puede acceder desde fuera del clúster. Puede agregar anotaciones para crear un equilibrador de carga interno y personalizar otra configuración del equilibrador de carga.
Nota:
De forma predeterminada, el plano de control de Istio anexará el nombre GatewayClassapprouting-istio al nombre de los recursos que aprovisiona para el Gateway. Puede anotar el recurso Gateway con gateway.istio.io/name-override para invalidar el nombre de los recursos aprovisionados. Los nombres de recursos deben tener menos 63 caracteres y deben ser un nombre DNS válido.
Compruebe que se han creado un Deployment, Service, HorizontalPodAutoscaler, y PodDisruptionBudget 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
Envío de una solicitud a una aplicación de ejemplo
Por último, intente enviar una curl solicitud a la httpbin aplicación. En primer lugar, establezca la variable de entorno 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}')
A continuación, intente enviar una solicitud HTTP a httpbin:
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
Debería ver una respuesta HTTP 200.
Nota:
Para proteger el tráfico de entrada con la implementación de Gateway API de enrutamiento de aplicaciones e integrar Azure DNS para la administración de nombres de host, consulte Configurar Azure DNS y TLS con la implementación de Gateway API de enrutamiento de aplicaciones para usar el flujo de trabajo automatizado impulsado por el operador de enrutamiento de aplicaciones. Para obtener un flujo de trabajo de terminación TLS manual que no dependa de la integración del operador, consulte Protección del tráfico de entrada con la implementación de la API de puerta de enlace de enrutamiento de aplicaciones.
Para usar Terraform para crear un clúster de AKS con la implementación de api de puerta de enlace de enrutamiento de aplicaciones habilitada, necesita lo siguiente:
- Tener instalada la versión
1.9.0o posterior de Terraform. - La CLI de Azure instalada y autenticada. Ejecute
az --versionpara buscar laazure-cliversión y ejecuteaz upgradepara actualizar. Use el CLI de Azure para conectarse al clúster después de que Terraform lo cree. -
kubectl instalado. Puede instalarlo localmente mediante el
az aks install-clicomando . Usekubectlpara desplegar la aplicación de ejemplo y los recursos de Gateway API.
Implemente un clúster de AKS con la implementación de la API de Gateway para el enrutamiento de aplicaciones mediante Terraform
En esta sección se muestra cómo usar Terraform para implementar un clúster de AKS con la instalación de la API de puerta de enlace administrada y la implementación de la API de puerta de enlace para el enrutamiento de aplicaciones habilitadas.
Nota:
El código de ejemplo de esta sección se encuentra en el repositorio de Azure terraform GitHub. Puedes ver el archivo de registro que contiene los resultados de las pruebas de las versiones actuales y anteriores de Terraform.
Consulte más artículos y código de ejemplo en el que se muestra cómo usar Terraform para administrar recursos de Azure.
En este ejemplo se implementa:
- Un grupo de recursos.
- Un clúster de AKS que usa el complemento de red de CNI Azure y un equilibrador de carga estándar.
- La instalación de la API de puerta de enlace administrada y la implementación de la API de puerta de enlace de enrutamiento de aplicaciones, ambas habilitadas en el clúster a través del proveedor AzAPI. Al habilitar ambas opciones, la clase GatewayClass administrada
approuting-istiopor AKS está disponible en el clúster.
Cree un directorio para probar y ejecutar el código de Terraform de ejemplo y convertirlo en el directorio actual.
Cree un archivo llamado
main.tfe inserte el siguiente código: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" }Para inicializar Terraform, ejecute el
terraform initcomando . Este comando descarga los proveedores de Azure necesarios para administrar Azure recursos con Terraform.terraform initDé formato y valide la configuración mediante la ejecución de los
terraform fmtcomandos yterraform validate.terraform fmt terraform validateCree un plan de ejecución de Terraform ejecutando el
terraform plancomando . Este comando muestra los recursos que Terraform crea o modifica en la suscripción de Azure.terraform planAplique el plan de ejecución de Terraform ejecutando el comando
terraform apply. Este comando crea los recursos definidos en su archivomain.tfen su suscripción de Azure. Cuando se le solicite, escribayespara confirmar.terraform apply
Conexión al clúster de AKS mediante Terraform
Obtenga el grupo de recursos y los nombres de clúster de las salidas de Terraform.
terraform output -raw resource_group_name terraform output -raw cluster_nameConfigure
kubectlpara conectarse a su clúster mediante el comandoaz aks get-credentials. Con este comando se descargan las credenciales y se configura la CLI de Kubernetes para usarlas. Sustituya<resource-group-name>y<cluster-name>por los valores del paso anterior. Como alternativa, ejecuteterraform output -raw get_credentials_commandpara obtener el comando completo listo para ejecutar.az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>Para comprobar que el clúster se está ejecutando, ejecute el
kubectl get nodescomando .kubectl get nodes
Comprobación de la configuración de la API de puerta de enlace mediante Terraform
Compruebe que los
istiodpods están en ejecución en el espacio de nombresaks-istio-system.kubectl get pods -n aks-istio-systemConfirme que gatewayClass
approuting-istioexiste y se acepta.kubectl get gatewayclassLa
approuting-istioGatewayClass debería devolverTrueen la columnaACCEPTED.
Configuración de la entrada mediante una puerta de enlace de Kubernetes con Terraform
Implementación de la aplicación de ejemplo mediante Terraform
Despliegue la aplicación de ejemplo httpbin en el espacio de nombres default:
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/httpbin/httpbin.yaml
Compruebe que el pod httpbin y el servicio están disponibles:
kubectl get pods -l app=httpbin
kubectl get svc httpbin
Creación de los recursos de Puerta de enlace y HTTPRoute mediante Terraform
El ejemplo de implementación de Gateway API para el enrutamiento de aplicaciones incluye un manifiesto Gateway que crea una escucha HTTP en el puerto 80 y usa la GatewayClass approuting-istio administrada por AKS.
Cree un archivo llamado
gateway.yamle inserte el siguiente código: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 la
Gatewayconfiguración:kubectl apply -f gateway.yamlEl ejemplo también incluye un manifiesto
HTTPRouteque enruta las solicitudes parahttpbin.example.com/getal serviciohttpbinen el puerto8000.Cree un archivo llamado
httproute.yamle inserte el siguiente código: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 la
HTTPRouteconfiguración:kubectl apply -f httproute.yaml
Nota:
En el ejemplo anterior se crea un servicio de equilibrador de carga de entrada externo al que se puede acceder desde fuera del clúster. Puede agregar anotaciones para crear un equilibrador de carga interno y personalizar otra configuración del equilibrador de carga.
Compruebe que se han creado un Deployment, Service, HorizontalPodAutoscaler, y PodDisruptionBudget 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
Envío de una solicitud a la aplicación de ejemplo mediante Terraform
Espere a que la puerta de enlace notifique una Programmed condición y obtenga su dirección externa:
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}')
A continuación, envíe una solicitud a httpbin a través de la puerta de enlace:
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
Debería ver una respuesta HTTP 200.
Registro de acceso
La implementación de la API de puerta de enlace para el enrutamiento de aplicaciones habilita, de forma predeterminada, el registro de acceso de Envoy en todos los pods de proxy administrados de Gateway. Los registros de acceso se escriben en la salida estándar del contenedor proxy en el formato de texto predeterminado de Envoy. Puede ver los registros mediante kubectl logs:
kubectl logs deployment/<your-gateway-name>-approuting-istio
Cada solicitud que procesa la puerta de enlace genera una línea de registro que contiene detalles como el método HTTP, la ruta de acceso, el código de respuesta, el servicio upstream y los tamaños de la solicitud y de la respuesta. Este detalle facilita la observación del tráfico de entrada y la solución de problemas de enrutamiento sin ninguna configuración adicional.
Control de versiones y actualizaciones
La implementación de Gateway API para el enrutamiento de aplicaciones despliega y actualiza el plano de control de Istio según la versión de Kubernetes del clúster de AKS, tanto en las actualizaciones de versiones secundarias como de parche. Este modelo local se alinea con los valores predeterminados de producción automática de AKS, donde la administración del ciclo de vida de la plataforma está diseñada para reducir las operaciones manuales.
La versión de Istio es la versión secundaria máxima admitida de Istio que es compatible con la versión de AKS del clúster. Por ejemplo, si tiene la versión de AKS 1.34, la versión máxima admitida de Istio que está instalada (a partir de marzo de 2026) es 1.28. Tenga en cuenta que la versión máxima admitida de Istio para una versión determinada de Kubernetes puede diferir entre los clústeres de soporte a largo plazo (LTS) y los clústeres que no son LTS.
Para conocer la versión secundaria máxima de Istio admitida para su versión de Kubernetes de AKS, consulte el calendario de versiones del complemento de malla de servicio. Aunque la implementación de API de puerta de enlace para el enrutamiento de aplicaciones no está versionada por revisiones, la versión secundaria del plano de control de Istio corresponde a la revisión indicada del complemento de malla de servicio (por ejemplo, para la revisión del complemento de malla de servicio asm-1-28, la versión secundaria del plano de control de Istio para el enrutamiento de aplicaciones es 1.28). Para ver la versión secundaria de Istio, también puede comprobar la versión de revisión en la imagen de implementación de Istio:
kubectl get deployment istiod -n aks-istio-system -o=jsonpath="{.spec.template.spec.containers[*].image}"
Actualizaciones
Las actualizaciones de la versión de parche y de la versión secundaria del plano de control de Istio para la implementación de la API de la puerta de enlace de enrutamiento de aplicaciones se realizan localmente. Las actualizaciones de versiones de parche se realizan automáticamente como parte de las versiones de AKS. Las actualizaciones de versiones secundarias pueden activarse automáticamente o manualmente según la versión de Kubernetes de AKS y la programación de las versiones secundarias de Istio. Las actualizaciones de versiones secundarias se producen en los escenarios siguientes:
- El clúster de AKS se actualiza a una nueva versión que tiene una versión superior máxima admitida de Istio anclada a él. El plano de control de Istio se actualiza a la versión secundaria más reciente como parte de la actualización del clúster de AKS.
- Se publica una nueva versión de Istio para AKS y se convierte en la versión máxima admitida de Istio para la versión del clúster de AKS. Después del despliegue en tu región, el plano de control de Istio en tu clúster se actualiza automáticamente a la nueva versión menor. Para realizar un seguimiento de los lanzamientos de nuevas versiones de Istio y ver cuándo se distribuye la nueva versión en su región, siga las notas de versiones de AKS y el rastreador de versiones de AKS.
Las interrupciones del tráfico pueden producirse durante el proceso de actualización. Para minimizar las interrupciones durante las actualizaciones, el complemento de enrutamiento de aplicaciones implementa Horizontal Pod Autoscaler (HPA) con dos réplicas mínimas y un PodDisruptionBudget (PDB) con una disponibilidad mínima de una para cada Gateway. Puede personalizar estos recursos para modificar esta configuración.
Personalizaciones de recursos
Personalización de Horizontal Pod Autoscaling (HPA) del plano de control
La implementación de la API de puerta de enlace de enrutamiento de aplicaciones admite la personalización de Horizontal Pod Autoscaler (HPA) del plano de control de Istio. El istiod recurso de HPA tiene las siguientes configuraciones predeterminadas:
- Réplicas mínimas: dos
- Número máximo de réplicas: Cinco
- Uso de CPU: 80%
Nota:
Para evitar conflictos con el PodDisruptionBudget, la implementación de la API Gateway de enrutamiento de aplicaciones no permite establecer minReplicas por debajo del valor predeterminado inicial de 2.
La configuración de HPA se puede modificar mediante revisiones y modificaciones directas. Ejemplo:
kubectl patch hpa istiod -n aks-istio-system --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'
Personalización de recursos de puerta de enlace
La implementación de la API de gateway de enrutamiento de aplicaciones admite la personalización de los Gateway recursos a través de anotaciones y ConfigMaps. El enrutamiento de aplicaciones usa la misma lista de permitidos para la personalización de recursos que el complemento de malla de servicio Istio para la personalización de recursos de la puerta de enlace de API. Siga los pasos descritos en los documentos de API de puerta de enlace del complemento Istio para configurar los recursos generados para Gateways y para ver qué campos se encuentran en la lista de permitidos.
Nota:
AKS aprovisiona y concilia el ConfigMap istio-gateway-class-defaults cuando las CRD de la API de puerta de enlace administrada y la implementación de la API de puerta de enlace de enrutamiento de aplicaciones están activadas conjuntamente. Si ha creado previamente el ConfigMap de istio-gateway-class-defaults en el espacio de nombres de aks-istio-system, debe eliminar la instancia de ConfigMap autoadministrada antes de habilitar los CRD de la API de la puerta de enlace administrada para evitar conflictos con la reconciliación del ConfigMap administrado por AKS.
Nota:
La implementación de la API de puerta de enlace de enrutamiento de aplicaciones agrega anotaciones de Azure Load Balancer al servicio Gateway para configurar sondeos de estado para la configuración predeterminada externalTrafficPolicy de "Cluster". Si establece spec.externalTrafficPolicy en "Local", debe eliminar las siguientes anotaciones, ya sea en el ConfigMap de nivel GatewayClass o en el 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:
Deshabilitar la implementación de la API de Gateway de enrutamiento de aplicaciones
Ejecute el siguiente comando para deshabilitar la implementación de la API de gateway de enrutamiento de aplicaciones:
az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --disable-app-routing-istio
Limpieza de recursos
Ejecute los comandos siguientes para eliminar los Gateway recursos y HTTPRoute :
kubectl delete gateways.gateway.networking.k8s.io httpbin-gateway
kubectl delete httproute httpbin
Si ha creado un objeto ConfigMap para personalizar Gateway, ejecute el siguiente comando para eliminar el ConfigMap:
kubectl delete configmap gw-options
Si creó un secretProviderClass y un secreto que se usará para la terminación TLS, elimine los siguientes recursos:
kubectl delete secret httpbin-credential
kubectl delete pod secrets-store-sync-httpbin
kubectl delete secretproviderclass httpbin-credential-spc
Limpieza de recursos mediante Terraform
En esta sección, ha implementado una aplicación de ejemplo con ámbito de espacio de nombres y recursos de la API de Gateway. Si ya no necesita estos recursos de Kubernetes, elimínelos antes de quitar la infraestructura de Azure subyacente.
Elimine HTTPRoute, Gateway y la aplicación de ejemplo con el 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
El comando siguiente quita el grupo de recursos, el clúster de AKS y todos los demás recursos asociados al grupo de recursos creado para este ejemplo. Si ha implementado otros recursos dentro de este grupo de recursos, el comando también los elimina.
Quite los recursos de Azure creados por Terraform mediante el terraform destroy comando . Cuando se le solicite, escriba yes para confirmar.
terraform destroy
Contenido relacionado
- ¿Qué es Azure Kubernetes Service (AKS) Automático?
- Creación de un clúster automático de AKS
- Configurar Azure DNS y TLS con la implementación de la API de Gateway para el enrutamiento de aplicaciones
- Protección del tráfico de entrada con la implementación de la API de gateway de enrutamiento de aplicaciones (configuración manual)