Preguntas más frecuentes sobre Azure Kubernetes Service (AKS)

  • Artículo

En este artículo se abordan las preguntas más frecuentes sobre Azure Kubernetes Service (AKS).

¿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 limitar quién tiene acceso al servidor de API de Kubernetes?

Sí. Hay dos opciones para limitar el acceso al servidor de API:

¿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.

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

Las revisiones de AKS CVE que tienen una "corrección del proveedor" cada semana. CVE sin una corrección están esperando una "corrección del proveedor" antes de que se pueda 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:

¿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. 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.

Nodos de Windows Server

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.

¿Hay amenazas de seguridad adicionales relevantes para AKS que debería 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. A continuación, se muestra una lista de amenazas de seguridad adicionales relacionadas con AKS y Kubernetes que debería tener en cuenta:

¿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 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.

¿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. 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.

¿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. Solo debería usar este clúster para los recursos que compartan 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 evitar que se hagan cambios en el grupo de recursos del nodo al bloquear usuarios para que no modifiquen recursos administrados por el clúster AKS.

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

Sí. De forma predeterminada, AKS asigna 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.

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. Puede ver la información adicional en la sección siguiente.

¿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 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 más información, consulte ¿AKS ofrece un contrato de nivel de servicio?

Nota:

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

¿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 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.

¿Los webhooks de controlador de admisión pueden afectar 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 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

¿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 ejecutar contenedores de Windows Server en AKS?

Sí, los contenedores de Windows Server están disponibles en AKS. Para ejecutar los contenedores de Windows Server en AKS, cree un grupo de nodos que ejecute Windows Server como sistema operativo invitado. Los contenedores de Windows Server solo pueden usar Windows Server 2019. Para empezar, vea Creación de un clúster de AKS con un grupo de nodos de Windows Server.

La compatibilidad de Windows Server con el grupo de nodos incluye algunas limitaciones que forman parte de la versión de Windows Server ascendente en el proyecto de Kubernetes. Para obtener más información sobre estas limitaciones, consulte Windows Server containers in AKS limitations (Limitaciones de los contenedores de Windows Server en AKS).

¿AKS ofrece un Acuerdo de Nivel de Servicio?

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 plan de tarifa Gratis no tiene ningún Acuerdo de Nivel de Servicio asociado, pero tiene un Objetivo de Nivel de Servicio del 99,5 %. Podría suceder que aparecieran problemas de conectividad transitorios debido a actualizaciones, nodos subyacentes incorrectos, mantenimiento de la plataforma, una aplicación que satura el servidor de la API con solicitudes, etc. Para cargas de trabajo críticas y de producción, o si la carga de trabajo no tolera reinicios del servidor de API, se recomienda usar el nivel Estándar, que incluye el Acuerdo de Nivel de Servicio de tiempo de actividad.

¿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.

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

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

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

Actualmente no se admite el movimiento de clústeres entre suscripciones.

¿Puedo trasladar los clústeres de AKS de la suscripción actual de Azure a otra?

No se admite el traslado de clústeres de AKS y de los recursos asociados entre suscripciones de Azure.

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

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

¿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 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.

¿Por qué tarda tanto la creación/actualización de mi clúster?

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.

¿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. Un ejemplo del segundo grupo de recursos es MC_myResourceGroup_myAKSCluster_eastus.

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.

¿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. La compatibilidad con la plataforma no incluye nada relacionado con lo siguiente:

  • Funcionalidad y componentes de Kubernetes
  • Creación de clústeres o grupos de nodos
  • Revisiones
  • Corrección de errores
  • Parches de seguridad
  • Componentes retirados

Para obtener más información sobre las restricciones, consulte la directiva de soporte de la plataforma.

AKS se basa en las versiones y revisiones de Kubernetes, que es un proyecto de código abierto que solo admite una ventana deslizante de tres versiones secundarias. AKS solo puede garantizar compatibilidad total mientras esas versiones tienen servicio ascendente. Puesto que no se producen más revisiones ascendentes, AKS puede dejar esas versiones sin revisión o bifurcación. Debido a esta limitación, el soporte técnico para plataformas no admitirá nada que dependa directamente de Kubernetes ascendente.

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

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. La actualización automática de un clúster compatible con la plataforma a una versión compatible está habilitada de manera predeterminada.

Por ejemplo, kubernetes v1.25 se actualiza a la versión 1.26 durante la versión v1.29 de disponibilidad general. Para minimizar las interrupciones, configure las ventanas de mantenimiento. Consulte Actualización automática para obtener más información sobre los canales de actualización automática.

Si tengo un pod o implementaciones con el estado "NodeLost" (Nodo perdido) o "Unknown" (Desconocido), ¿puedo actualizar el clúster?

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

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

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

Ejecuté una eliminación de clúster, pero me aparece el error [Errno 11001] getaddrinfo failed

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.

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. Consulte: Entidad de servicio de AKS y Credenciales de actualización de AKS.

Mi clúster estaba funcionando, pero, de repente, no puede aprovisionar equilibradores de carga, montar PVC, etc.

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

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

Puede detener completamente un clúster de AKS en ejecución, lo que ahorrará los costos de proceso respectivos. Además, puede optar por escalar manual o automáticamente todos los grupos de nodos User o algunos específicos a 0, manteniendo solo la configuración necesaria del clúster.

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 mediante el uso de las API del conjunto de escalado de máquinas virtuales. Use las API de AKS (az aks scale).

¿Puedo usar Virtual Machine Scale Sets para escalar manualmente a 0 nodos?

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.

¿Puedo detener o cancelar la asignación de todas las máquinas virtuales?

Aunque AKS tiene mecanismos de resistencia para admitir este tipo de configuración y recuperarse de él, no se admite esta configuración. Detenga el clúster en su lugar.

¿Puedo usar extensiones de máquina virtual personalizadas?

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 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.

¿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

¿Qué diferencias hay entre el modo transparente de Azure CNI y el modo puente?

A partir de la versión 1.2.0, Azure CNI tendrá habilitado el modo transparente de manera predeterminada para las implementaciones CNI de un solo inquilino en Linux. El modo transparente va a reemplazar al modo puente. En las siguientes secciones modo Puente y modo Transparente, se habla más sobre las diferencias entre ambos modos y las ventajas y limitaciones del modo Transparente en Azure CNI.

Modo puente

El modo Puente de Azure CNI crea un puente L2 denominado "azure0" de forma "Just-In-Time". Todas las interfaces de par veth de los pods del host se conectan a este puente. La comunicación entre pods de las máquinas virtuales y el tráfico restante pasan a través de este puente. El puente es un dispositivo virtual de capa 2 que, por su cuenta, no puede recibir ni transmitir nada, a menos que enlace uno o más dispositivos reales a él. Por este motivo, eth0 de la máquina virtual Linux debe convertirse en un puente subordinado a "azure0", que crea una topología de red compleja dentro de la máquina virtual Linux. Como síntoma, CNI tenía que controlar otras funciones de red, como las actualizaciones del servidor DNS.

Bridge mode topology

En el ejemplo siguiente se muestra el aspecto de la configuración de la ruta de dirección IP en el modo puente. Independientemente del número de pods que tenga el nodo, solo hay dos rutas. La primera ruta indica que el tráfico (excepto el local en azure0) va a la puerta de enlace predeterminada de la subred a través de la interfaz con IP "src 10.240.0.4", que es la dirección IP principal del nodo. La segunda dice que el espacio de pod "10.20.x.x" en kernel para que el kernel decida.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Modo transparente

El modo Transparente adopta un enfoque directo para configurar redes de Linux. En este modo, Azure CNI no cambia las propiedades de la interfaz eth0 en la máquina virtual Linux. Este enfoque para cambiar las propiedades de red de Linux ayuda a reducir los problemas complejos que podrían encontrarse los clústeres en el modo puente. En el modo Transparente, Azure CNI crea y agrega interfaces de par veth de los pods del host que se agreguen a la red del host. La comunicación entre pods de las máquinas virtuales se realiza a través de las rutas IP añadidas por CNI. Básicamente, la comunicación entre pods es sobre la capa 3 y las reglas de enrutamiento L3 enrutan el tráfico de pods.

Transparent mode topology

En el ejemplo siguiente, se muestra una configuración de ruta de dirección IP del modo Transparente. La interfaz de cada pod obtendrá una ruta estática asociada para que el tráfico con la misma dirección IP de destino que el pod se envíe directamente a la interfaz de par veth del host del pod.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Ventajas del modo Transparente

  • Proporciona mitigación para la condición de carrera paralela de DNS conntrack y evita los problemas de latencia de DNS de 5 segundos sin necesidad de configurar el DNS local del nodo (puede seguir usándolo por motivos de rendimiento).
  • Elimina la latencia inicial de 5 segundos de DNS que el modo puente de CNI causa actualmente debido a la configuración del puente "just in time".
  • Uno de los casos extremos del modo Puente es que Azure CNI no puede actualizar constantemente las listas de servidores DNS personalizados que los usuarios agregan a la red virtual o la NIC. Este escenario resulta en que CNI recoge solo la primera instancia de la lista de servidores DNS. Este problema se resuelve en el modo Transparente porque CNI no cambia las propiedades de eth0. Consulte más información aquí.
  • Se puede controlar mejor el tráfico UDP y se mitigan los desbordamientos de UDP cuando se agota el tiempo de espera de ARP. En el modo Puente, cuando el puente no conoce una dirección MAC del pod de destino en la comunicación entre pods de las máquinas virtuales, de forma predeterminada se generará una avalancha de paquetes en todos los puertos. Este problema se resuelve en el modo Transparente, ya que no hay ningún dispositivo L2 en la ruta de acceso. Consulte más información aquí.
  • El modo transparente funciona mejor en la comunicación entre pods de las máquinas virtuales en términos de rendimiento y latencia, en comparación con el modo Puente.

¿Cómo evitar los problemas de lentitud debido a la configuración de propiedad de permisos cuando el volumen tenga muchos archivos?

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 explica 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.

¿Puedo usar bibliotecas criptográficas de FIPS con implementaciones en 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.

¿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 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.

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

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.

¿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 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.

¿Cuál es el propósito de la extensión Linux de AKS que veo instalada en mis instancias Linux de Virtual Machine Scale Sets?

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.