Preguntas más frecuentes sobre AKS

AKS proporciona garantías de Acuerdo de Nivel de Servicio en el plan de tarifa Estándar con la característica 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 planeado y Actualizaciones automáticas.

Sí, AKS admite contenedores de Windows Server. Para obtener más información, consulte las preguntas más frecuentes de Windows Server en 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.

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 quiere protegerse frente a eliminaciones accidentales, puede bloquear el grupo de recursos administrado de AKS que hospeda los recursos del clúster mediante bloqueo del grupo de recursos de 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 mediante el uso de 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 mediante el uso de 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, esta no es una configuración admitida. 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. Solo debería usar este grupo de recursos para los recursos que compartan el ciclo de vida del clúster.

De manera predeterminada, AKS asigna el nombre MC_resourcegroupname_clustername_location al grupo de recursos del nodo, pero usted 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][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.

Cuando trabaje con el grupo de recursos del nodo, tenga en cuenta que 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 una vez se haya 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 crear directivas de Azure con un ámbito en el grupo de recursos administrados.

Las etiquetas creadas por Azure se crean para sus respectivos servicios de Azure y siempre deben permitirse. 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).

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 en 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. Sin embargo, es importante comprender que 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 sacarla 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. En una programación normal del ciclo de versiones de Windows Update y su proceso de validación propio, debe realizar una actualización en el clúster y los grupos de nodos de Windows Server en el clúster de AKS. 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 desea limitar el servidor de API para que solo sea accesible desde dentro de la red virtual.

Las revisiones de AKS CVE que tienen una "corrección del proveedor" cada semana. Los CV sin una corrección están esperando una "corrección 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 regular para asegurarse de que todas las imágenes revisadas y las revisiones del sistema operativo más recientes se aplican y actualizan. Para ello, emplee uno de los métodos siguientes:

• Manualmente, mediante Azure Portal o la CLI de Azure.
• Mediante la actualización del clúster de AKS. Las actualizaciones del clúster acordonan y purgan los nodos automáticamente, y luego ponen un nuevo nodo en línea con la imagen de Ubuntu más reciente 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 (AKS).
• 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. A continuación, se muestra una lista de amenazas de seguridad adicionales relacionadas con AKS y Kubernetes que debería tener en cuenta:

• 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), deberá especificar un elemento fsGroup dentro del contexto de seguridad del pod para que este pueda leer y escribir en el volumen. Este requisito se trata con más detalle aquí.

Un efecto secundario de configurar fsGroup es que cada vez que se monte un volumen, Kubernetes deberá ejecutar chown() y chmod() en todos los archivos y directorios dentro del volumen (con algunas excepciones que se indican a continuación). Este escenario se producirá incluso aunque la propiedad del grupo del volumen ya coincida con el solicitado fsGroup. Podría ser costoso para volúmenes más grandes con muchos archivos pequeños, lo que podría hacer que el inicio del pod tome mucho tiempo. Esta situación ha sido un problema conocido antes de la versión v1.20 y la solución alternativa es configurar la ejecución del pod 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 granular 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 TLS. El túnel principal que usa AKS es Konnectivity, anteriormente conocido como apiserver-network-proxy. Asegúrese de que todas las reglas de red sigan las reglas de red necesarias de Azure y los nombres de dominio completo.

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. Esto es útil en los casos en los que la salida del clúster se realiza a través de un firewall de nivel 7, como 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 a las interfaces de red. Si usa CNI, 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 los rangos de CIDR del pod. 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, consulteGrupo de seguridad de red.

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

No, AKS es un servicio administrado y no se admite la manipulación de los recursos de IaaS. Para instalar componentes personalizados, use los mecanismos y las API de Kubernetes. Por ejemplo, aproveche 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 los espacios de nombres internos de AKS que estén marcados con la etiqueta de plano de control. 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 de kube-system, el espacio de nombres de 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 factor de admisión lo omita.

Etiqueta: "admissions.enforcer/disabled": "true" o 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 para FIPS ahora son compatibles con 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 cosa 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 averiguar cuándo hay disponible una nueva versión, visite 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. Entonces, una herramienta de supervisión, como Prometheus, es capaz de 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 de systemd 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: 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) diseñadas para recopilar información relevante, lo que permite a los usuarios 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 incorrecta, memoria o disco
• 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 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 traiga su propio grupo de recursos o realice tareas entre grupos de recursos, la eliminación podría tardar más tiempo o incluso producir un error. Si tiene un problema con las eliminaciones, compruebe que no tenga bloqueos en el grupo de recursos, que los recursos situados fuera del grupo estén desasociados de este, etc.

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

Se puede, pero no es aconsejable. Deberían realizar actualizaciones cuando el estado del clúster sea conocido o correcto.

No, elimine o quite cualquier nodo en estado fallido o de otro tipo del clúster antes de actualizar.

Normalmente, este error surgirá si tiene uno o varios grupos de seguridad de red (NSG) todavía en uso que están asociados al clúster. Quítelos e intente de nuevo la eliminación.

Confirme que la entidad de servicio no ha expirado. Consulte Entidad de servicio de AKS y Credenciales de actualización de AKS.

Confirme que la entidad de servicio no ha expirado. Consulte Entidad de servicio de AKS y Credenciales de actualización de AKS.