Compartir a través de

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 Acuerdo de Nivel de Servicio de tiempo de actividad.

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

La compatibilidad con la plataforma es un plan de soporte reducido para clústeres de versión n-3 no admitidos. La compatibilidad con la plataforma solo incluye compatibilidad con 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 AKS compatible más reciente que está disponible con carácter general) está a punto de quitarse 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.

¿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 de Windows Server en AKS.

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

Los nodos del agente de AKS se facturan como máquinas virtuales de Azure estándar. 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 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 se admite el traslado del 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 mantener 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 de Node.

¿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 cero 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 grupos de nodos que no son del sistema a cero o detener el clúster en su lugar.

¿Puedo detener o desasignar todas mis 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 muchos recursos de infraestructura de Azure, incluidos conjuntos de escalado de máquinas virtuales, redes virtuales y 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, puede usar la mayoría de los tipos de máquina virtual de Azure directamente con AKS y puede usar Azure Reservations para recibir descuentos en esos recursos automáticamente.

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 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. Al crear un clúster de AKS mediante el az aks create comando , use el --node-resource-group parámetro 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 nodeResourceGroup propiedad .

  • El proveedor de recursos de Azure crea automáticamente el grupo de recursos secundario.
  • Solo puede especificar un nombre de grupo de recursos personalizado al crear 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.
  • Cambie el nombre del grupo de recursos del nodo después de crear 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 creadas por los usuarios finales y puede agregarlas 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 administrado.

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 Owner de etiqueta 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 aks-managed prefijo. En el caso de los recursos heredados, no use directivas de Azure para aplicar el nombre de Owner etiqueta. 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 aks-managed de forma segura las versiones de Helm con prefijo. Se espera y es seguro aumentar continuamente las revisiones de estas versiones de Helm.

Cuotas, límites y disponibilidad de regiones

¿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. Para obtener instrucciones sobre cómo crear una arquitectura que incluya varias regiones, consulte procedimientos recomendados para la continuidad empresarial y la recuperación ante desastres.

¿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 en 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áquina virtual 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 el 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, a continuación, quita 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 ejecutarse 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:

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

Revisiones de AKS CV que tienen una corrección de proveedor cada semana. Los CV sin una corrección están esperando una corrección de un 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 en una cadencia regular para asegurarse de que todas las imágenes revisadas y las revisiones del sistema operativo más recientes se apliquen y estén actualizadas. Puede realizar esta tarea:

¿Hay amenazas de seguridad que tienen como destino AKS que debo tener en cuenta?

Microsoft proporciona instrucciones para otras acciones 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 New large-scale campaign targets Kubeflow (8 de junio de 2021).

¿Almacena AKS datos de 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 en la configuración de la propiedad de los permisos cuando el volumen tiene numerosos archivos?

Tradicionalmente, si el pod se ejecuta como un usuario que no es raíz (que debe), debe especificar un fsGroup parámetro dentro del contexto de seguridad del pod para que el pod pueda leer y escribir 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 chown() comandos y chmod() de forma recursiva para todos los archivos y directorios del volumen (con algunas excepciones). Este escenario se produce incluso si la propiedad de grupo del volumen ya coincide con el parámetro solicitado fsGroup . 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 más información, consulte Kubernetes 1.20: control granular 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 nodos individuales y 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 actual 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 modifica ninguno de los NSG asociados a esa subred. AKS modifica solo la configuración del grupo de seguridad de red 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 interdominios sin clases (CIDR). Si usa kubenet, también debe asegurarse de que las reglas de seguridad de los NSG permiten el tráfico entre el nodo y el CIDR del pod. Para más información, consulteGrupo de seguridad de red.

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

Los nodos de AKS ejecutan el servicio chrony, que extrae la hora del host local. Los contenedores que se ejecutan en pods obtienen el tiempo de los nodos de AKS. Las aplicaciones que se abren dentro de un contenedor usan el tiempo desde el 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 control-plane etiqueta . Por ejemplo:

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

Los firewalls de AKS salida del servidor de API para que los webhooks del controlador de admisión deberán ser accesibles desde el clúster.

¿Los webhooks del controlador de admisión pueden afectar a los espacios de nombres kube-system e internos de AKS?

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

Si tiene un caso de uso crítico para implementar algo en kube-system (no recomendado) para admitir 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 secrets Store CSI Driver proporciona una integración nativa de Azure Key Vault en 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 cosa más grande que una revisión, como los cambios de versión principal o secundaria (que pueden tener cambios importantes en los objetos implementados), se actualizan 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 de 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 las herramientas de supervisión en los 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:

  • Exportador de nodos: recopila la telemetría de hardware de la máquina virtual y la pone a disposición 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 e 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 de demonio de infraestructura: Servicio NTP inactivo
  • Problemas 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 no responde

La extensión no requiere acceso de salida adicional a ninguna dirección URL, direcciones IP ni puertos más allá de los requisitos de salida de AKS documentados. No requiere permisos especiales concedidos en Azure. kubeconfig Usa 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 tiempo en eliminar mi clúster?

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 puede tardar más tiempo o incluso un error. 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 crear o actualizar 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 en los estados NodeLost o Unknown, ¿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 se apaga, ¿puedo realizar una actualización?

No. Elimine o quite todos los nodos que estén en un estado con errores o de otro modo del clúster antes de actualizar.

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

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.

He ejecutado una actualización, pero ahora mis pods están en bucles de bloqueo y se produce un error en los sondeos de preparación.

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

Mi clúster estaba funcionando, 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 AKS Service Principal y credenciales de actualización de AKS.