Preguntas más frecuentes sobre AKS

En este artículo se ofrecen respuestas a algunas de las preguntas más frecuentes sobre Azure Kubernetes Service (AKS).

Soporte técnico

¿AKS ofrece un Acuerdo de Nivel de Servicio?

AKS proporciona garantías de acuerdo de nivel de servicio (SLA) en el plan de tarifa Estándar con la característica de SLA de tiempo de actividad.

¿Qué es el soporte técnico para plataformas y qué incluye?

El soporte técnico para plataformas es un plan de soporte técnico reducido para clústeres de versión n-3 no admitidos. El soporte técnico para plataformas solo incluye soporte técnico para la infraestructura de Azure.

Para obtener más información, consulte la directiva de soporte técnico de la plataforma.

¿AKS actualizará automáticamente mis clústeres no admitidos?

Sí, AKS inicia actualizaciones automáticas para clústeres no admitidos. Cuando un clúster de una versión n-3 (donde n es la versión secundaria de disponibilidad general de AKS más reciente compatible) está a punto de pasar a n-4, AKS actualiza automáticamente el clúster a n-2 para permanecer en una directiva de soporte técnico de AKS.

Para obtener más información, consulte Versiones admitidas de Kubernetes, Ventanas de mantenimiento planificado y Actualizaciones automáticas.

¿Puedo aplicar descuentos de las reservas de Azure en mis nodos de agente de AKS?

Los nodos de agente de AKS se facturan como máquinas virtuales de Azure estándares. Si ha comprado reservas de Azure para el tamaño de máquina virtual que está usando en AKS, los descuentos se aplican automáticamente.

Operaciones

¿Puedo ejecutar contenedores de Windows Server en AKS?

Sí, AKS admite contenedores de Windows Server. Para obtener más información, consulte las Preguntas más frecuentes sobre Windows Server en AKS.

¿Qué sistemas operativos Linux (SO) se admiten en AKS?

AKS admite cuatro sistemas operativos Linux principales, como Ubuntu Linux, Azure Linux, Azure Linux OS Guard y Flatcar Container Linux para AKS. Al especificar --os-type Linux durante la creación del grupo de nodos o la creación del clúster, el sistema operativo predeterminado es Ubuntu Linux.

¿Qué versiones de sistemas operativos (SO) se admiten en AKS?

Al usar --os-sku Ubuntu, AKS tiene como valor predeterminado Ubuntu 22.04 en las versiones 1.25-1.34 de Kubernetes. AkS tiene como valor predeterminado Ubuntu 24.04 en las versiones 1.35 y posteriores de Kubernetes. Cuando se usa --os-sku AzureLinux, AKS tiene como valor predeterminado Azure Linux 3.0 en las versiones 1.32 y posteriores de Kubernetes. En algunos escenarios, como los grupos de nodos habilitados para FIPS, la versión predeterminada del sistema operativo podría diferir. Consulte imágenes de nodo para obtener más información.

¿Puedo mover o migrar mi clúster entre inquilinos de Azure?

No. Actualmente, no puede mover el clúster de AKS entre inquilinos.

¿Puedo mover o migrar mi clúster entre suscripciones?

No. Actualmente, no puede mover el clúster de AKS entre suscripciones.

¿Puedo mover el clúster de AKS o los recursos de infraestructura de AKS a otros grupos de recursos o cambiarles el nombre?

No. No se admite mover el clúster de AKS y sus recursos asociados ni cambiarles el nombre.

¿Puedo restaurar el clúster después de eliminarlo?

No. No puede restaurar el clúster después de eliminarlo. Al eliminar el clúster, también se eliminan el grupo de recursos del nodo y todos sus recursos.

Si desea conservar cualquiera de los recursos, muévalos a otro grupo de recursos antes de eliminar el clúster. Si desea protegerse frente a eliminaciones accidentales, puede bloquear el grupo de recursos administrado de AKS que hospeda los recursos del clúster mediante el bloqueo del grupo de recursos del nodo.

¿Puedo escalar el clúster de AKS a cero?

Puede detener completamente un clúster de AKS en ejecución o escalar o escalar automáticamente todos los grupos de nodos de User o nodos específicos a cero.

No se pueden escalar directamente grupos de nodos del sistema a 0.

¿Puedo usar las API del conjunto de escalado de máquinas virtuales para escalar manualmente?

No. No se admiten las operaciones de escalado que usan las API del conjunto de escalado de máquinas virtuales. Puede usar las API de AKS (az aks scale).

¿Puedo usar conjuntos de escalado de máquinas virtuales para escalar manualmente a 0 nodos?

No. No se admiten las operaciones de escalado que usan las API del conjunto de escalado de máquinas virtuales. Puede usar la API de AKS para escalar a cero grupos de nodos que no sean del sistema, o bien detener el clúster en su lugar.

¿Puedo detener o desasignar todas las máquinas virtuales?

No. No se admite esta configuración. Detenga el clúster en su lugar.

¿Por qué se crean dos grupos de recursos con AKS?

AKS se basa en diversos recursos de infraestructura de Azure, como los conjuntos de escalado de máquinas virtuales, las redes virtuales y los discos administrados. Estas integraciones le permitirán aplicar muchas de las funciones básicas referentes a la plataforma de Azure en el entorno de Kubernetes administrado que proporciona AKS. Por ejemplo, la mayoría de los tipos de máquinas virtuales de Azure se pueden usar directamente con AKS, y Azure Reservations se puede usar para recibir descuentos automáticamente en esos recursos.

Para habilitar esta arquitectura, cada implementación de AKS abarca dos grupos de recursos:

1. Debe cree el primer grupo de recursos. Este grupo solo contiene el recurso del servicio de Kubernetes. El proveedor de recursos de AKS crea automáticamente el segundo grupo de recursos durante la implementación. Un ejemplo del segundo grupo de recursos es MC_myResourceGroup_myAKSCluster_eastus. Para obtener información sobre cómo especificar el nombre de este segundo grupo de recursos, consulte la sección siguiente.
2. El segundo grupo de recursos, conocido como el grupo de recursos del nodo, contiene todos los recursos de infraestructura asociados con el clúster. Estos recursos incluyen las máquinas virtuales de nodos de Kubernetes, las redes virtuales y el almacenamiento. De forma predeterminada, el grupo de recursos del nodo tiene un nombre como MC_myResourceGroup_myAKSCluster_eastus. AKS elimina automáticamente el grupo de recursos del nodo cada vez que se elimina el clúster. Use este grupo de recursos solo para los recursos que comparten el ciclo de vida del clúster.

Nota:

Modificar cualquier recurso bajo el grupo de recursos del nodo en el clúster AKS es una acción de admitida y causará errores en las operaciones del clúster. Puede impedir que se realicen cambios en el grupo de recursos del nodo. Impedir que los usuarios modifiquen los recursos que administra el clúster de AKS.

¿Puedo proporcionar mi propio nombre para el grupo de recursos del nodo de AKS?

De forma predeterminada, AKS asignará el nombre MC_resourcegroupname_clustername_location al grupo de recursos del nodo, pero también puede proporcionar su propio nombre.

Para especificar un nombre de su elección para el grupo de recursos, instale la versión de la extensión de la CLI de Azure aks-preview0.3.2 o una posterior. Cuando cree un clúster de AKS mediante el comando az aks create, use el parámetro --node-resource-group y especifique un nombre para el grupo de recursos. Si usa una plantilla de Azure Resource Manager para implementar un clúster de AKS, puede definir el nombre del grupo de recursos mediante la propiedad nodeResourceGroup.

• El proveedor de recursos de Azure crea automáticamente el grupo de recursos secundario.
• Solo puede especificar un nombre personalizado para el grupo de recursos cuando cree el clúster.

Al trabajar con el grupo de recursos de nodo, no puede:

• Especificar un grupo de recursos existente para el grupo de recursos del nodo.
• Especificar otra suscripción para el grupo de recursos del nodo.
• Cambiar el nombre del grupo de recursos del nodo después de haber creado el clúster.
• Especificar los nombres de los recursos administrados del grupo de recursos del nodo.
• Modificar o eliminar las etiquetas creadas en Azure de los recursos administrados del grupo de recursos del nodo.

¿Puedo modificar etiquetas y otras propiedades de los recursos de AKS en el grupo de recursos del nodo?

Es posible que obtenga errores inesperados de escalado y actualización si modifica o elimina etiquetas creadas por Azure y otras propiedades de recursos en el grupo de recursos del nodo. AKS permite crear y modificar etiquetas personalizadas generadas por usuarios finales, que se pueden agregar al crear un grupo de nodos. Es posible que quiera crear o modificar etiquetas personalizadas, por ejemplo, para asignar un centro de costos o una unidad de negocio. Otra opción es aplicar directivas y modificar etiquetas a través del propio recurso de AKS, específicamente a través del clúster y los grupos de nodos.

Las etiquetas creadas por Azure se crean para sus respectivos servicios de Azure y siempre debe permitirlas. Para AKS, hay las etiquetas aks-managed y k8s-azure. La modificación de las etiquetas creadas por Azure en los recursos del grupo de recursos de nodos en el clúster de AKS es una acción no admitida que interrumpe el objetivo de nivel de servicio (SLO, por sus siglas en inglés).

Nota:

En el pasado, el nombre de etiqueta Owner se reservaba para que AKS administrara la dirección IP pública asignada en la dirección IP de front-end del equilibrador de carga. Ahora, los servicios usan el prefijo aks-managed. En el caso de los recursos heredados, no use directivas de Azure para aplicar el nombre de etiqueta Owner. De lo contrario, se interrumpirán todas las operaciones de implementación y actualización del clúster de AKS. Esta restricción no se aplica a los recursos recién creados.

¿Por qué veo las versiones de Helm prefijo administradas por aks en mi clúster y por qué su recuento de revisiones sigue aumentando?

AKS usa Helm para entregar componentes al clúster. Puede omitir de forma segura las versiones de Helm con prefijo aks-managed. Se espera y es seguro aumentar continuamente las revisiones de estas versiones de Helm.

Cuotas, límites y disponibilidad de región

¿Qué regiones de Azure proporcionan actualmente AKS?

Para obtener una lista completa de las regiones disponibles, consulte AKS regions and availability (Regiones y disponibilidad de AKS).

¿Puedo propagar un clúster de AKS entre regiones?

No. Los clústeres de AKS son recursos regionales y no pueden abarcar regiones. Consulte Procedimientos recomendados de continuidad empresarial y recuperación ante desastres para obtener instrucciones sobre cómo crear una arquitectura que incluya varias regiones.

¿Puedo propagar un clúster de AKS entre zonas de disponibilidad?

Sí, puede implementar un clúster de AKS en una o más zonas de disponibilidad de regiones que las admitan.

¿Puedo tener diferentes tamaños de máquina virtual en un único clúster?

Sí, puede usar diferentes tamaños de máquinas virtuales en el clúster de AKS mediante la creación de varios grupos de nodos.

¿Cuál es el límite de tamaño de una imagen de contenedor en AKS?

AKS no establece un límite del tamaño de la imagen de contenedor. Pero cuanto mayor sea la imagen, mayor será la demanda de memoria. Un mayor tamaño puede superar los límites de recursos o la memoria total disponible de los nodos de trabajo. De forma predeterminada, la memoria para el tamaño de máquina virtual Standard_DS2_v2 para un clúster de AKS se establece en 7 GB.

Cuando una imagen de contenedor es excesivamente grande, como en el intervalo de terabyte (TB), es posible que kubelet no pueda extraerla del registro de contenedor a un nodo debido a la falta de espacio en disco.

Para los nodos de Windows Server, Windows Update no ejecuta ni aplica las actualizaciones más recientes de manera automática. Debe realizar una actualización en el clúster y los grupos de nodos de Windows Server en el clúster de AKS. Siga una programación regular basada en el ciclo de lanzamiento de Windows Update y su propio proceso de validación. Este proceso de actualización crea nodos que ejecutan la imagen y las revisiones más recientes de Windows Server y elimina los nodos anteriores. Para obtener más información sobre este proceso, consulte Actualización de un grupo de nodos en AKS.

¿Las imágenes de AKS deben ejecutarse como raíz?

Las imágenes siguientes tienen requisitos funcionales para ejecutar como raíz y se deben presentar excepciones para cualquier directiva:

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Seguridad, acceso e identidad

¿Puedo limitar quién tiene acceso al servidor de API de Kubernetes?

Sí, hay dos opciones para limitar el acceso al servidor de API:

• Use intervalos de direcciones IP autorizadas del servidor de API si quiere mantener un punto de conexión público para el servidor de API, pero restringir el acceso a un conjunto de intervalos de direcciones IP de confianza.
• Use un clúster privado si quiere limitar el servidor de API para que solo sea accesible desde dentro de la red virtual.

¿Se aplican las actualizaciones de seguridad a los nodos de agente de AKS?

AKS aplica revisiones a las CVE que tienen una corrección del proveedor cada semana. Las CVE sin corrección están a la espera de una corrección por parte del proveedor antes de que se puedan corregir. Las imágenes de AKS se actualizan automáticamente en un plazo de 30 días. Se recomienda aplicar una imagen de nodo actualizada con una cadencia periódica para asegurarse de que todas las imágenes revisadas y las revisiones del sistema operativo más recientes se aplican y actualizan. Puedes realizar esta tarea:

• Manualmente, mediante Azure Portal o la CLI de Azure.
• Mediante la actualización del clúster de AKS. El clúster actualiza los nodos de acordonamiento y purga automáticamente. A continuación, pone un nuevo nodo en línea con la imagen más reciente de Ubuntu y una nueva versión de revisión o una versión secundaria de Kubernetes. Para más información, consulte Actualización de un clúster de Azure Kubernetes Service.
• Mediante el uso de la actualización de imágenes de nodo.

¿Hay amenazas de seguridad para AKS que deba tener en cuenta?

Microsoft proporciona instrucciones sobre las acciones adicionales que puede realizar para proteger las cargas de trabajo a través de servicios como Microsoft Defender para contenedores. Para obtener información sobre una amenaza de seguridad relacionada con AKS y Kubernetes, consulte Nueva campaña a gran escala dirigida a Kubeflow (8 de junio de 2021).

¿AKS guarda datos de los clientes fuera de la región del clúster?

No. Todos los datos se almacenan en la región del clúster.

¿Cómo puedo evitar problemas de lentitud debidos a la configuración de propiedad de permisos cuando el volumen tiene muchos archivos?

Tradicionalmente, si el pod se ejecuta como un usuario no raíz (como debería ser), debe especificar un parámetro fsGroup dentro del contexto de seguridad del pod para que el pod pueda leer y escribir en el volumen. Para obtener más información sobre este requisito, consulte Configuración de un contexto de seguridad para un pod o contenedor.

Un efecto secundario de la configuración fsGroup es que, cada vez que se monta un volumen, Kubernetes debe usar los comandos chown() y chmod() de forma recursiva en todos los archivos y directorios dentro del volumen, con algunas excepciones. Este escenario se produce incluso si la propiedad de grupo del volumen ya coincide con el parámetro fsGroup solicitado. Esta configuración puede ser costosa para volúmenes más grandes con muchos archivos pequeños, lo que puede hacer que el inicio del pod tarde mucho tiempo. Este escenario era un problema conocido antes de la versión 1.20. La solución alternativa es establecer el pod para que se ejecute como raíz:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

El problema se resolvió con la versión 1.20 de Kubernetes. Para obtener más información, consulte Kubernetes 1.20: Control pormenorizado de los cambios de permisos de volumen.

Redes

¿Cómo se comunica el plano de control administrado con mis nodos?

AKS usa una comunicación de túnel segura para permitir que los kubelets de api-server y de nodos individuales se comuniquen incluso en redes virtuales independientes. El túnel se protege mediante el cifrado de seguridad de la capa de transporte mutua. El túnel principal que usa AKS es Konnectivity, anteriormente conocido como apiserver-network-proxy. Compruebe que todas las reglas de red siguen las Reglas de red necesarias de Azure y los nombres de dominio completos (FQDN).

¿Pueden mis pods usar el FQDN del servidor de API en lugar de la dirección IP del clúster?

Sí, puede agregar la anotación kubernetes.azure.com/set-kube-service-host-fqdn a pods para establecer la variable KUBERNETES_SERVICE_HOST en el nombre de dominio del servidor de API en lugar de en la dirección IP del servicio en el clúster. Esta modificación es útil en los casos en los que la salida del clúster se realiza a través de un firewall de nivel 7. Un ejemplo es cuando se usa Azure Firewall con reglas de aplicación.

¿Se pueden configurar los grupos de seguridad de red con AKS?

AKS no aplica grupos de seguridad de red (NSG) a su subred y no modificará ninguno de los grupos de seguridad de red asociados a esa subred. AKS solo modifica la configuración de los grupos de seguridad de red referentes de la interfaz de red. Si usa la interfaz de red de contenedor (CNI), también debe asegurarse de que las reglas de seguridad de los NSG permiten el tráfico entre el nodo y los intervalos de enrutamiento entre dominios sin clases (CIDR). Si usa kubenet, también debe asegurarse de que las reglas de seguridad de los grupos de seguridad de red permiten el tráfico entre el nodo y el CIDR del pod. Para más información, consulte Grupo de seguridad de red.

¿Cómo funciona la sincronización de hora en AKS?

Los nodos de AKS ejecutan el servicio "chrony", que obtiene la hora del host local. Los contenedores que se ejecutan en pods obtienen la hora de los nodos de AKS. Las aplicaciones que se abren dentro de un contenedor usan la hora del contenedor del pod.

Complementos, extensiones e integraciones

¿Puedo usar extensiones de máquina virtual personalizadas?

No. AKS es un servicio administrado. No se admite la manipulación de los recursos de infraestructura como servicio (IaaS). Para instalar componentes personalizados, use los mecanismos y las API de Kubernetes. Por ejemplo, use DaemonSets para instalar los componentes necesarios.

¿Qué controladores de admisión de Kubernetes admite AKS? ¿Se pueden agregar o eliminar los controladores de admisión?

AKS admite los siguientes controladores de admisión:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Actualmente, no puede modificar la lista de controladores de admisión en AKS.

¿Puedo utilizar webhooks de controlador de admisión en AKS?

Sí, puede usar webhooks de controlador de admisión en AKS. Se recomienda excluir espacios de nombres internos de AKS, que están marcados con la etiqueta control-plane. Por ejemplo:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS pasa por el firewall la salida del servidor de la API, por lo que los webhooks del controlador de admisión deben ser accesibles desde el clúster.

¿Los webhooks de controlador de admisión afectan a los espacios de nombres internos de kube-system y de AKS?

Para proteger la estabilidad del sistema y evitar que los controladores de admisión personalizados afecten a los servicios internos del espacio de nombres kube-system, AKS tiene un ejecutor de admisiones, que excluye automáticamente los espacios de nombres internos de kube-system y de AKS. Este servicio garantiza que los controladores de admisión personalizados no afecten a los servicios que se ejecutan en kube-system.

Si está ante un caso de uso crítico por tener un elemento implementado en kube-system (no se recomienda) que necesita que esté incluido en el webhook de admisión personalizado, puede agregar la siguiente etiqueta o anotación para que el aplicador de admisiones lo omita.

• Etiqueta: "admissions.enforcer/disabled": "true"
• Anotación: "admissions.enforcer/disabled": true

¿Azure Key Vault se integra con AKS?

El proveedor de Azure Key Vault para el controlador CSI del almacén de secretos proporciona integración nativa de Azure Key Vault con AKS.

¿Puedo usar bibliotecas criptográficas de FIPS con implementaciones en AKS?

Los nodos habilitados con los estándares federales de procesamiento de información (FIPS) ahora se admiten en grupos de nodos basados en Linux. Para obtener más información, consulte Adición de un grupo de nodos habilitado para FIPS.

¿Cómo se actualizan los complementos de AKS?

Cualquier revisión, incluyendo las revisiones de seguridad, se aplica automáticamente al clúster de AKS. Cualquier elemento mayor que una revisión, como los cambios de versión principal o secundaria (que pueden incluir cambios importantes en los objetos implementados), se implementa al actualizar el clúster si hay disponible una nueva versión. Para obtener información sobre cuándo hay disponible una nueva versión, consulte las notas de la versión de AKS.

¿Cuál es el propósito de la extensión Linux de AKS que veo instalada en mis instancias de conjuntos de escalado de máquinas virtuales Linux?

La extensión Linux de AKS es una extensión de máquina virtual de Azure que instala y configura herramientas de supervisión en nodos de trabajo de Kubernetes. La extensión se instala en todos los nodos de Linux nuevos y existentes. Configura las siguientes herramientas de supervisión:

• Node-exporter: recopila telemetría de hardware de la máquina virtual y hace que esté disponible mediante un punto de conexión de métricas. A continuación, una herramienta de supervisión, como Prometheus, puede extraer estas métricas.
• Node-problem-detector: tiene como objetivo hacer que varios problemas de nodo sean visibles para las capas ascendentes de la pila de administración de clústeres. Se trata de una unidad con sistema que se ejecuta en cada nodo, detecta problemas de nodo y los informa al servidor de API del clúster mediante Events y NodeConditions.
• ig: es un marco de código abierto con tecnología eBPF para depurar y observar sistemas Linux y Kubernetes. Proporciona un conjunto de herramientas (o gadgets) que recopilan información relevante que los usuarios pueden usar para identificar la causa de problemas de rendimiento, bloqueos u otras anomalías. En particular, su independencia de Kubernetes permite a los usuarios emplearla también para depurar problemas del plano de control.

Estas herramientas ayudan a proporcionar observabilidad en torno a muchos problemas relacionados con el estado del nodo, como:

• Problemas del demonio de infraestructura: servicio NTP inactivo
• Incidencias de hardware: CPU, memoria o disco incorrectos
• Problemas del kernel: interbloqueo del kernel, sistema de archivos dañado
• Problemas del entorno de ejecución del contenedor: demonio de tiempo de ejecución que no responde

La extensión no requiere ningún acceso de salida adicional a ninguna dirección URL, direcciones IP o puertos más allá de los requisitos de salida de AKS documentados. No requiere permisos especiales concedidos en Azure. Usa kubeconfig para conectarse al servidor de API para enviar los datos de supervisión recopilados.

Solución de problemas de clúster

¿Por qué tarda tanto la eliminación del clúster?

La mayoría de los clústeres se eliminan a petición del usuario. En algunos casos, especialmente en los que trae su propio grupo de recursos o realiza tareas entre grupos de recursos, la eliminación puede tardar más tiempo o incluso fallar. Si tiene un problema con eliminaciones, compruebe que no tiene bloqueos en el grupo de recursos. Asegúrese también de que los recursos fuera del grupo de recursos están desasociados del grupo de recursos.

¿Por qué tarda tanto tiempo en crearse o actualizarse mi clúster?

Si tiene problemas con la creación y actualización de clústeres, asegúrese de que no tiene ninguna directiva asignada o restricciones de servicio que puedan impedir que el clúster de AKS administre recursos como máquinas virtuales, equilibradores de carga o etiquetas.

Si tengo pods o implementaciones con el estado NodeLost o Desconocido, ¿puedo actualizar el clúster?

Se puede, pero no es aconsejable. Realice actualizaciones cuando el estado del clúster sea conocido y correcto.

Si tengo un clúster con uno o varios nodos en un estado incorrecto o si está apagado, ¿puedo realizar una actualización?

No. Elimine o quite del clúster todos los nodos que se encuentren en estado de fallo o de otro tipo antes de proceder a la actualización.

He intentado eliminar mi clúster, pero veo el error "[Errno 11001] getaddrinfo failed."

Normalmente, este error se produce si tiene uno o varios NSG en uso que todavía están asociados al clúster. Quítelos e intente eliminar el clúster de nuevo.

Ejecuté una actualización, pero ahora mis pods están en bucles de bloqueo y se producen errores en los sondeos de preparación.

Confirme que la entidad de servicio no ha expirado. Para obtener más información, consulte Entidad de servicio de AKS y Credenciales de actualización de AKS.

Mi clúster funcionaba, pero de repente no puedo aprovisionar equilibradores de carga ni montar notificaciones de volumen persistente.

Confirme que la entidad de servicio no ha expirado. Para obtener más información, consulte Entidad de servicio de AKS y Credenciales de actualización de AKS.

Retiradas y desuso

¿Qué versiones del sistema operativo Linux están en desuso en AKS?

A partir del 17 de marzo de 2027, Azure Kubernetes Service (AKS) ya no admite ni proporciona actualizaciones de seguridad ubuntu 20.04. Las imágenes de nodo existentes se eliminarán y no podrá escalar ningún grupo de nodos que ejecute Ubuntu 20.04. Migre a una versión de Ubuntu compatible mediante la actualización de los grupos de nodos a la versión 1.35 y posteriores de Kubernetes. Para obtener más información sobre esta retirada, consulte la Incidencia sobre retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS.

¿Qué versiones del sistema operativo Windows están en desuso en AKS?

A partir del 1 de marzo de 2026, Azure Kubernetes Service (AKS) ya no admite grupos de nodos de Windows Server 2019. Los grupos de nodos que ejecutan kubernetes versión 1.33+ no pueden usar Windows Server 2019. A partir del 1 de abril de 2027, AKS quitará todas las imágenes de nodo existentes para Windows Server 2019, lo que significa que se producirá un error en las operaciones de escalado. Para obtener más información sobre esta retirada, consulte la Incidencia sobre retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS. A partir del 15 de marzo de 2027, Azure Kubernetes Service (AKS) ya no admite grupos de nodos de Windows Server 2022. Los grupos de nodos que ejecutan la versión 1.36+ de Kubernetes no pueden usar Windows Server 2022. A partir del 1 de abril de 2028, AKS quitará todas las imágenes de nodo existentes para Windows Server 2022, lo que significa que se producirá un error en las operaciones de escalado. Para obtener más información sobre esta retirada, consulte la Incidencia sobre retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS.

En este artículo se ofrecen respuestas a algunas de las preguntas más frecuentes sobre Azure Kubernetes Service (AKS).

AKS proporciona garantías de acuerdo de nivel de servicio (SLA) en el plan de tarifa Estándar con la característica de SLA de tiempo de actividad.

El soporte técnico para plataformas es un plan de soporte técnico reducido para clústeres de versión n-3 no admitidos. El soporte técnico para plataformas solo incluye soporte técnico para la infraestructura de Azure.

Para obtener más información, consulte la directiva de soporte técnico de la plataforma.

Sí, AKS inicia actualizaciones automáticas para clústeres no admitidos. Cuando un clúster de una versión n-3 (donde n es la versión secundaria de disponibilidad general de AKS más reciente compatible) está a punto de pasar a n-4, AKS actualiza automáticamente el clúster a n-2 para permanecer en una directiva de soporte técnico de AKS.

Para obtener más información, consulte Versiones admitidas de Kubernetes, Ventanas de mantenimiento planificado y Actualizaciones automáticas.

Los nodos de agente de AKS se facturan como máquinas virtuales de Azure estándares. Si ha comprado reservas de Azure para el tamaño de máquina virtual que está usando en AKS, los descuentos se aplican automáticamente.

Sí, AKS admite contenedores de Windows Server. Para obtener más información, consulte las Preguntas más frecuentes sobre Windows Server en AKS.

AKS admite cuatro sistemas operativos Linux principales, como Ubuntu Linux, Azure Linux, Azure Linux OS Guard y Flatcar Container Linux para AKS. Al especificar --os-type Linux durante la creación del grupo de nodos o la creación del clúster, el sistema operativo predeterminado es Ubuntu Linux.

Al usar --os-sku Ubuntu, AKS tiene como valor predeterminado Ubuntu 22.04 en las versiones 1.25-1.34 de Kubernetes. AkS tiene como valor predeterminado Ubuntu 24.04 en las versiones 1.35 y posteriores de Kubernetes. Cuando se usa --os-sku AzureLinux, AKS tiene como valor predeterminado Azure Linux 3.0 en las versiones 1.32 y posteriores de Kubernetes. En algunos escenarios, como los grupos de nodos habilitados para FIPS, la versión predeterminada del sistema operativo podría diferir. Consulte imágenes de nodo para obtener más información.

No. Actualmente, no puede mover el clúster de AKS entre inquilinos.

No. Actualmente, no puede mover el clúster de AKS entre suscripciones.

No. No se admite mover el clúster de AKS y sus recursos asociados ni cambiarles el nombre.

No. No puede restaurar el clúster después de eliminarlo. Al eliminar el clúster, también se eliminan el grupo de recursos del nodo y todos sus recursos.

Si desea conservar cualquiera de los recursos, muévalos a otro grupo de recursos antes de eliminar el clúster. Si desea protegerse frente a eliminaciones accidentales, puede bloquear el grupo de recursos administrado de AKS que hospeda los recursos del clúster mediante el bloqueo del grupo de recursos del nodo.

Puede detener completamente un clúster de AKS en ejecución o escalar o escalar automáticamente todos los grupos de nodos de User o nodos específicos a cero.

No se pueden escalar directamente grupos de nodos del sistema a 0.

No. No se admiten las operaciones de escalado que usan las API del conjunto de escalado de máquinas virtuales. Puede usar las API de AKS (az aks scale).

No. No se admiten las operaciones de escalado que usan las API del conjunto de escalado de máquinas virtuales. Puede usar la API de AKS para escalar a cero grupos de nodos que no sean del sistema, o bien detener el clúster en su lugar.

No. No se admite esta configuración. Detenga el clúster en su lugar.

AKS se basa en diversos recursos de infraestructura de Azure, como los conjuntos de escalado de máquinas virtuales, las redes virtuales y los discos administrados. Estas integraciones le permitirán aplicar muchas de las funciones básicas referentes a la plataforma de Azure en el entorno de Kubernetes administrado que proporciona AKS. Por ejemplo, la mayoría de los tipos de máquinas virtuales de Azure se pueden usar directamente con AKS, y Azure Reservations se puede usar para recibir descuentos automáticamente en esos recursos.

Para habilitar esta arquitectura, cada implementación de AKS abarca dos grupos de recursos:

1. Debe cree el primer grupo de recursos. Este grupo solo contiene el recurso del servicio de Kubernetes. El proveedor de recursos de AKS crea automáticamente el segundo grupo de recursos durante la implementación. Un ejemplo del segundo grupo de recursos es MC_myResourceGroup_myAKSCluster_eastus. Para obtener información sobre cómo especificar el nombre de este segundo grupo de recursos, consulte la sección siguiente.
2. El segundo grupo de recursos, conocido como el grupo de recursos del nodo, contiene todos los recursos de infraestructura asociados con el clúster. Estos recursos incluyen las máquinas virtuales de nodos de Kubernetes, las redes virtuales y el almacenamiento. De forma predeterminada, el grupo de recursos del nodo tiene un nombre como MC_myResourceGroup_myAKSCluster_eastus. AKS elimina automáticamente el grupo de recursos del nodo cada vez que se elimina el clúster. Use este grupo de recursos solo para los recursos que comparten el ciclo de vida del clúster.

Nota:

Modificar cualquier recurso bajo el grupo de recursos del nodo en el clúster AKS es una acción de admitida y causará errores en las operaciones del clúster. Puede impedir que se realicen cambios en el grupo de recursos del nodo. Impedir que los usuarios modifiquen los recursos que administra el clúster de AKS.

De forma predeterminada, AKS asignará el nombre MC_resourcegroupname_clustername_location al grupo de recursos del nodo, pero también puede proporcionar su propio nombre.

Para especificar un nombre de su elección para el grupo de recursos, instale la versión de la extensión de la CLI de Azure aks-preview0.3.2 o una posterior. Cuando cree un clúster de AKS mediante el comando az aks create, use el parámetro --node-resource-group y especifique un nombre para el grupo de recursos. Si usa una plantilla de Azure Resource Manager para implementar un clúster de AKS, puede definir el nombre del grupo de recursos mediante la propiedad nodeResourceGroup.

• El proveedor de recursos de Azure crea automáticamente el grupo de recursos secundario.
• Solo puede especificar un nombre personalizado para el grupo de recursos cuando cree el clúster.

Al trabajar con el grupo de recursos de nodo, no puede:

• Especificar un grupo de recursos existente para el grupo de recursos del nodo.
• Especificar otra suscripción para el grupo de recursos del nodo.
• Cambiar el nombre del grupo de recursos del nodo después de haber creado el clúster.
• Especificar los nombres de los recursos administrados del grupo de recursos del nodo.
• Modificar o eliminar las etiquetas creadas en Azure de los recursos administrados del grupo de recursos del nodo.

Es posible que obtenga errores inesperados de escalado y actualización si modifica o elimina etiquetas creadas por Azure y otras propiedades de recursos en el grupo de recursos del nodo. AKS permite crear y modificar etiquetas personalizadas generadas por usuarios finales, que se pueden agregar al crear un grupo de nodos. Es posible que quiera crear o modificar etiquetas personalizadas, por ejemplo, para asignar un centro de costos o una unidad de negocio. Otra opción es aplicar directivas y modificar etiquetas a través del propio recurso de AKS, específicamente a través del clúster y los grupos de nodos.

Las etiquetas creadas por Azure se crean para sus respectivos servicios de Azure y siempre debe permitirlas. Para AKS, hay las etiquetas aks-managed y k8s-azure. La modificación de las etiquetas creadas por Azure en los recursos del grupo de recursos de nodos en el clúster de AKS es una acción no admitida que interrumpe el objetivo de nivel de servicio (SLO, por sus siglas en inglés).

Nota:

En el pasado, el nombre de etiqueta Owner se reservaba para que AKS administrara la dirección IP pública asignada en la dirección IP de front-end del equilibrador de carga. Ahora, los servicios usan el prefijo aks-managed. En el caso de los recursos heredados, no use directivas de Azure para aplicar el nombre de etiqueta Owner. De lo contrario, se interrumpirán todas las operaciones de implementación y actualización del clúster de AKS. Esta restricción no se aplica a los recursos recién creados.

AKS usa Helm para entregar componentes al clúster. Puede omitir de forma segura las versiones de Helm con prefijo aks-managed. Se espera y es seguro aumentar continuamente las revisiones de estas versiones de Helm.

Para obtener una lista completa de las regiones disponibles, consulte AKS regions and availability (Regiones y disponibilidad de AKS).

No. Los clústeres de AKS son recursos regionales y no pueden abarcar regiones. Consulte Procedimientos recomendados de continuidad empresarial y recuperación ante desastres para obtener instrucciones sobre cómo crear una arquitectura que incluya varias regiones.

Sí, puede implementar un clúster de AKS en una o más zonas de disponibilidad de regiones que las admitan.

Sí, puede usar diferentes tamaños de máquinas virtuales en el clúster de AKS mediante la creación de varios grupos de nodos.

AKS no establece un límite del tamaño de la imagen de contenedor. Pero cuanto mayor sea la imagen, mayor será la demanda de memoria. Un mayor tamaño puede superar los límites de recursos o la memoria total disponible de los nodos de trabajo. De forma predeterminada, la memoria para el tamaño de máquina virtual Standard_DS2_v2 para un clúster de AKS se establece en 7 GB.

Cuando una imagen de contenedor es excesivamente grande, como en el intervalo de terabyte (TB), es posible que kubelet no pueda extraerla del registro de contenedor a un nodo debido a la falta de espacio en disco.

Para los nodos de Windows Server, Windows Update no ejecuta ni aplica las actualizaciones más recientes de manera automática. Debe realizar una actualización en el clúster y los grupos de nodos de Windows Server en el clúster de AKS. Siga una programación regular basada en el ciclo de lanzamiento de Windows Update y su propio proceso de validación. Este proceso de actualización crea nodos que ejecutan la imagen y las revisiones más recientes de Windows Server y elimina los nodos anteriores. Para obtener más información sobre este proceso, consulte Actualización de un grupo de nodos en AKS.

Las imágenes siguientes tienen requisitos funcionales para ejecutar como raíz y se deben presentar excepciones para cualquier directiva:

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Sí, hay dos opciones para limitar el acceso al servidor de API:

• Use intervalos de direcciones IP autorizadas del servidor de API si quiere mantener un punto de conexión público para el servidor de API, pero restringir el acceso a un conjunto de intervalos de direcciones IP de confianza.
• Use un clúster privado si quiere limitar el servidor de API para que solo sea accesible desde dentro de la red virtual.

AKS aplica revisiones a las CVE que tienen una corrección del proveedor cada semana. Las CVE sin corrección están a la espera de una corrección por parte del proveedor antes de que se puedan corregir. Las imágenes de AKS se actualizan automáticamente en un plazo de 30 días. Se recomienda aplicar una imagen de nodo actualizada con una cadencia periódica para asegurarse de que todas las imágenes revisadas y las revisiones del sistema operativo más recientes se aplican y actualizan. Puedes realizar esta tarea:

• Manualmente, mediante Azure Portal o la CLI de Azure.
• Mediante la actualización del clúster de AKS. El clúster actualiza los nodos de acordonamiento y purga automáticamente. A continuación, pone un nuevo nodo en línea con la imagen más reciente de Ubuntu y una nueva versión de revisión o una versión secundaria de Kubernetes. Para más información, consulte Actualización de un clúster de Azure Kubernetes Service.
• Mediante el uso de la actualización de imágenes de nodo.

Microsoft proporciona instrucciones sobre las acciones adicionales que puede realizar para proteger las cargas de trabajo a través de servicios como Microsoft Defender para contenedores. Para obtener información sobre una amenaza de seguridad relacionada con AKS y Kubernetes, consulte Nueva campaña a gran escala dirigida a Kubeflow (8 de junio de 2021).

No. Todos los datos se almacenan en la región del clúster.

Tradicionalmente, si el pod se ejecuta como un usuario no raíz (como debería ser), debe especificar un parámetro fsGroup dentro del contexto de seguridad del pod para que el pod pueda leer y escribir en el volumen. Para obtener más información sobre este requisito, consulte Configuración de un contexto de seguridad para un pod o contenedor.

Un efecto secundario de la configuración fsGroup es que, cada vez que se monta un volumen, Kubernetes debe usar los comandos chown() y chmod() de forma recursiva en todos los archivos y directorios dentro del volumen, con algunas excepciones. Este escenario se produce incluso si la propiedad de grupo del volumen ya coincide con el parámetro fsGroup solicitado. Esta configuración puede ser costosa para volúmenes más grandes con muchos archivos pequeños, lo que puede hacer que el inicio del pod tarde mucho tiempo. Este escenario era un problema conocido antes de la versión 1.20. La solución alternativa es establecer el pod para que se ejecute como raíz:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

El problema se resolvió con la versión 1.20 de Kubernetes. Para obtener más información, consulte Kubernetes 1.20: Control pormenorizado de los cambios de permisos de volumen.

AKS usa una comunicación de túnel segura para permitir que los kubelets de api-server y de nodos individuales se comuniquen incluso en redes virtuales independientes. El túnel se protege mediante el cifrado de seguridad de la capa de transporte mutua. El túnel principal que usa AKS es Konnectivity, anteriormente conocido como apiserver-network-proxy. Compruebe que todas las reglas de red siguen las Reglas de red necesarias de Azure y los nombres de dominio completos (FQDN).

Sí, puede agregar la anotación kubernetes.azure.com/set-kube-service-host-fqdn a pods para establecer la variable KUBERNETES_SERVICE_HOST en el nombre de dominio del servidor de API en lugar de en la dirección IP del servicio en el clúster. Esta modificación es útil en los casos en los que la salida del clúster se realiza a través de un firewall de nivel 7. Un ejemplo es cuando se usa Azure Firewall con reglas de aplicación.

AKS no aplica grupos de seguridad de red (NSG) a su subred y no modificará ninguno de los grupos de seguridad de red asociados a esa subred. AKS solo modifica la configuración de los grupos de seguridad de red referentes de la interfaz de red. Si usa la interfaz de red de contenedor (CNI), también debe asegurarse de que las reglas de seguridad de los NSG permiten el tráfico entre el nodo y los intervalos de enrutamiento entre dominios sin clases (CIDR). Si usa kubenet, también debe asegurarse de que las reglas de seguridad de los grupos de seguridad de red permiten el tráfico entre el nodo y el CIDR del pod. Para más información, consulte Grupo de seguridad de red.

Los nodos de AKS ejecutan el servicio "chrony", que obtiene la hora del host local. Los contenedores que se ejecutan en pods obtienen la hora de los nodos de AKS. Las aplicaciones que se abren dentro de un contenedor usan la hora del contenedor del pod.

No. AKS es un servicio administrado. No se admite la manipulación de los recursos de infraestructura como servicio (IaaS). Para instalar componentes personalizados, use los mecanismos y las API de Kubernetes. Por ejemplo, use DaemonSets para instalar los componentes necesarios.

AKS admite los siguientes controladores de admisión:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Actualmente, no puede modificar la lista de controladores de admisión en AKS.

Sí, puede usar webhooks de controlador de admisión en AKS. Se recomienda excluir espacios de nombres internos de AKS, que están marcados con la etiqueta control-plane. Por ejemplo:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS pasa por el firewall la salida del servidor de la API, por lo que los webhooks del controlador de admisión deben ser accesibles desde el clúster.

Para proteger la estabilidad del sistema y evitar que los controladores de admisión personalizados afecten a los servicios internos del espacio de nombres kube-system, AKS tiene un ejecutor de admisiones, que excluye automáticamente los espacios de nombres internos de kube-system y de AKS. Este servicio garantiza que los controladores de admisión personalizados no afecten a los servicios que se ejecutan en kube-system.

Si está ante un caso de uso crítico por tener un elemento implementado en kube-system (no se recomienda) que necesita que esté incluido en el webhook de admisión personalizado, puede agregar la siguiente etiqueta o anotación para que el aplicador de admisiones lo omita.

• Etiqueta: "admissions.enforcer/disabled": "true"
• Anotación: "admissions.enforcer/disabled": true

El proveedor de Azure Key Vault para el controlador CSI del almacén de secretos proporciona integración nativa de Azure Key Vault con AKS.

Los nodos habilitados con los estándares federales de procesamiento de información (FIPS) ahora se admiten en grupos de nodos basados en Linux. Para obtener más información, consulte Adición de un grupo de nodos habilitado para FIPS.

Cualquier revisión, incluyendo las revisiones de seguridad, se aplica automáticamente al clúster de AKS. Cualquier elemento mayor que una revisión, como los cambios de versión principal o secundaria (que pueden incluir cambios importantes en los objetos implementados), se implementa al actualizar el clúster si hay disponible una nueva versión. Para obtener información sobre cuándo hay disponible una nueva versión, consulte las notas de la versión de AKS.

La extensión Linux de AKS es una extensión de máquina virtual de Azure que instala y configura herramientas de supervisión en nodos de trabajo de Kubernetes. La extensión se instala en todos los nodos de Linux nuevos y existentes. Configura las siguientes herramientas de supervisión:

• Node-exporter: recopila telemetría de hardware de la máquina virtual y hace que esté disponible mediante un punto de conexión de métricas. A continuación, una herramienta de supervisión, como Prometheus, puede extraer estas métricas.
• Node-problem-detector: tiene como objetivo hacer que varios problemas de nodo sean visibles para las capas ascendentes de la pila de administración de clústeres. Se trata de una unidad con sistema que se ejecuta en cada nodo, detecta problemas de nodo y los informa al servidor de API del clúster mediante Events y NodeConditions.
• ig: es un marco de código abierto con tecnología eBPF para depurar y observar sistemas Linux y Kubernetes. Proporciona un conjunto de herramientas (o gadgets) que recopilan información relevante que los usuarios pueden usar para identificar la causa de problemas de rendimiento, bloqueos u otras anomalías. En particular, su independencia de Kubernetes permite a los usuarios emplearla también para depurar problemas del plano de control.

Estas herramientas ayudan a proporcionar observabilidad en torno a muchos problemas relacionados con el estado del nodo, como:

• Problemas del demonio de infraestructura: servicio NTP inactivo
• Incidencias de hardware: CPU, memoria o disco incorrectos
• Problemas del kernel: interbloqueo del kernel, sistema de archivos dañado
• Problemas del entorno de ejecución del contenedor: demonio de tiempo de ejecución que no responde

La extensión no requiere ningún acceso de salida adicional a ninguna dirección URL, direcciones IP o puertos más allá de los requisitos de salida de AKS documentados. No requiere permisos especiales concedidos en Azure. Usa kubeconfig para conectarse al servidor de API para enviar los datos de supervisión recopilados.

La mayoría de los clústeres se eliminan a petición del usuario. En algunos casos, especialmente en los que trae su propio grupo de recursos o realiza tareas entre grupos de recursos, la eliminación puede tardar más tiempo o incluso fallar. Si tiene un problema con eliminaciones, compruebe que no tiene bloqueos en el grupo de recursos. Asegúrese también de que los recursos fuera del grupo de recursos están desasociados del grupo de recursos.

Si tiene problemas con la creación y actualización de clústeres, asegúrese de que no tiene ninguna directiva asignada o restricciones de servicio que puedan impedir que el clúster de AKS administre recursos como máquinas virtuales, equilibradores de carga o etiquetas.

Se puede, pero no es aconsejable. Realice actualizaciones cuando el estado del clúster sea conocido y correcto.

No. Elimine o quite del clúster todos los nodos que se encuentren en estado de fallo o de otro tipo antes de proceder a la actualización.

Normalmente, este error se produce si tiene uno o varios NSG en uso que todavía están asociados al clúster. Quítelos e intente eliminar el clúster de nuevo.

Confirme que la entidad de servicio no ha expirado. Para obtener más información, consulte Entidad de servicio de AKS y Credenciales de actualización de AKS.

Confirme que la entidad de servicio no ha expirado. Para obtener más información, consulte Entidad de servicio de AKS y Credenciales de actualización de AKS.

A partir del 17 de marzo de 2027, Azure Kubernetes Service (AKS) ya no admite ni proporciona actualizaciones de seguridad ubuntu 20.04. Las imágenes de nodo existentes se eliminarán y no podrá escalar ningún grupo de nodos que ejecute Ubuntu 20.04. Migre a una versión de Ubuntu compatible mediante la actualización de los grupos de nodos a la versión 1.35 y posteriores de Kubernetes. Para obtener más información sobre esta retirada, consulte la Incidencia sobre retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS.

A partir del 1 de marzo de 2026, Azure Kubernetes Service (AKS) ya no admite grupos de nodos de Windows Server 2019. Los grupos de nodos que ejecutan kubernetes versión 1.33+ no pueden usar Windows Server 2019. A partir del 1 de abril de 2027, AKS quitará todas las imágenes de nodo existentes para Windows Server 2019, lo que significa que se producirá un error en las operaciones de escalado. Para obtener más información sobre esta retirada, consulte la Incidencia sobre retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS. A partir del 15 de marzo de 2027, Azure Kubernetes Service (AKS) ya no admite grupos de nodos de Windows Server 2022. Los grupos de nodos que ejecutan la versión 1.36+ de Kubernetes no pueden usar Windows Server 2022. A partir del 1 de abril de 2028, AKS quitará todas las imágenes de nodo existentes para Windows Server 2022, lo que significa que se producirá un error en las operaciones de escalado. Para obtener más información sobre esta retirada, consulte la Incidencia sobre retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS.