Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Firewall

Azure Kubernetes Service (AKS)

Control de acceso basado en rol de Azure

En este artículo se proporciona una arquitectura de infraestructura de línea base recomendada para implementar un clúster de Azure Kubernetes Service (AKS). Sigue nuestros principios de diseño y se alinea con los procedimientos recomendados de arquitectura de AKS de Azure Well-Architected Framework. En el artículo se guían varios grupos interdisciplinares distintos, como las redes, la seguridad y los equipos de identidad, cuando implementan esta infraestructura de uso general.

Esta arquitectura no se centra en una carga de trabajo. Se centra en el propio clúster de AKS. Esta información es la línea base mínima recomendada para la mayoría de los clústeres de AKS. Se integra con los servicios de Azure que ofrecen observabilidad, una topología de red que admite el crecimiento multirregional y protege el tráfico en clúster.

Los requisitos empresariales influyen en la arquitectura de destino y pueden variar entre contextos de aplicación. Considere la arquitectura como punto de partida para las fases de preproducción y producción.

Kubernetes es un amplio ecosistema que se extiende más allá de las tecnologías de Azure y Microsoft. Al implementar un clúster de AKS, es responsable de muchas decisiones sobre cómo diseñar y operar el clúster. La ejecución de un clúster de AKS implica componentes de código cerrado de varios proveedores, incluido Microsoft, junto con componentes de código abierto del ecosistema de Kubernetes. El panorama cambia con frecuencia, por lo que revisa las decisiones con regularidad. Al adoptar Kubernetes, reconoce que la carga de trabajo necesita sus funcionalidades y que el equipo de cargas de trabajo está preparado para invertir de forma continua.

Puede usar una implementación de esta arquitectura en GitHub: implementación de referencia de línea base de AKS como punto de partida alternativo y configurarla para satisfacer sus necesidades.

Note

La arquitectura de referencia requiere conocimientos de Kubernetes y sus conceptos. Si necesita una actualización, complete las rutas de aprendizaje Introducción a Kubernetes y Desarrollo de implementación de aplicaciones en Kubernetes.

Architecture

Descargue un archivo Visio de esta arquitectura.

Para más información, consulte topología de red en estrella tipo hub-and-spoke en Azure.

Topología de red

Esta arquitectura utiliza una topología de red de concentrador y radial. Despliegue el concentrador y los radios en redes virtuales independientes que estén conectadas mediante el emparejamiento de red virtual. Esta topología tiene varias ventajas:

Habilitar la administración segregada. Se puede aplicar la gobernanza y cumplir con el principio de mínimo privilegio (PoLP). También admite el concepto de una zona de aterrizaje de Azure con separación de tareas.
Minimizar la exposición directa a los recursos de Azure de la red pública de Internet.
Proporcione topologías regionales en estrella tipo hub-and-spoke. Puede expandir topologías de red en estrella tipo hub-and-spoke en el futuro y proporcionar aislamiento de carga de trabajo.
Utilice un servicio de firewall de aplicaciones web para ayudar a inspeccionar el flujo de tráfico HTTP para todas las aplicaciones web.
Proporcionar compatibilidad con cargas de trabajo que abarcan varias suscripciones.
Hacer que la arquitectura sea extensible. Para acomodar nuevas características o cargas de trabajo, puede agregar nuevos radios en lugar de volver a diseñar la topología de red.
Compatibilidad con el uso compartido de recursos, como un firewall y zonas del sistema de nombres de dominio (DNS), entre redes.
Alinearse con la zona de aterrizaje a escala empresarial de Azure.

Red virtual de centro

La red virtual de centro es el punto central de conectividad y observabilidad. En esta arquitectura, el centro contiene los siguientes componentes:

Azure Firewall con directivas de firewall globales que definen los equipos de TI centrales para aplicar reglas de toda la organización
Azure Bastion, que establece un túnel seguro en el perímetro de red privada para que pueda realizar operaciones de administración de clústeres.
Una subred de puerta de enlace para la conectividad VPN
Azure Monitor para la observabilidad de red

Dentro de la red, la arquitectura tiene tres subredes.

Subred para hospedar Azure Firewall

Azure Firewall es un servicio de firewall administrado. La instancia de Azure Firewall protege el tráfico de red saliente. Sin este nivel de seguridad, el tráfico puede comunicarse con un servicio malintencionado, no de Microsoft, que podría exfiltrar los datos confidenciales de la carga de trabajo. Use Azure Firewall Manager para implementar y configurar de forma centralizada varias instancias de Azure Firewall y administrar directivas de Azure Firewall para este tipo de arquitectura de red virtual del concentrador.

Subred para hospedar una puerta de enlace

Esta subred es un marcador de posición de una VPN Gateway en una puerta de enlace de Azure ExpressRoute. La puerta de enlace proporciona conectividad entre los enrutadores de la red local y la red virtual.

Subred para hospedar Azure Bastion

Esta subred se usa para Azure Bastion. Puede usar Azure Bastion para acceder de forma segura a los recursos de Azure sin exponer los recursos a Internet. Esta arquitectura usa Azure Bastion para conectarse de forma segura al servidor de API del clúster de AKS para las operaciones de administración. La subred es solo para la administración y las operaciones.

Red virtual de radios

La red virtual de radios contiene el clúster de AKS y otros recursos relacionados. El radio tiene las siguientes subredes.

Subred para hospedar Azure Application Gateway

Azure Application Gateway es un equilibrador de carga de tráfico web que funciona en el nivel 7. La implementación de referencia usa la SKU de Application Gateway v2 que habilita Azure Web Application Firewall. Web Application Firewall protege el tráfico entrante frente a los ataques de tráfico web comunes, incluidos los bots. La instancia tiene una configuración de IP de front-end pública que recibe las solicitudes del usuario. Por diseño, una instancia de Application Gateway requiere una subred dedicada.

Subred para hospedar los recursos de entrada

Para enrutar y distribuir el tráfico, Traefik es el controlador de entrada que cumple los recursos de entrada de Kubernetes. Los equilibradores de carga internos de Azure existen en esta subred. Para obtener más información, vea Uso de un equilibrador de carga interno con AKS.

Subred para hospedar los nodos de clúster

AKS mantiene dos grupos independientes de nodos. El grupo de nodos del sistema hospeda los pods que ejecutan los servicios principales del clúster. El grupo de nodos de usuario ejecuta la carga de trabajo y el controlador de entrada para facilitar la comunicación entrante para la carga de trabajo.

Subred para hospedar los puntos de conexión de Azure Private Link

Cree conexiones de Azure Private Link para Azure Container Registry y Azure Key Vault para que los usuarios puedan acceder a estos servicios a través de un punto de conexión privado dentro de la red virtual de spoke. Los puntos de conexión privados no necesitan una subred dedicada. También puede colocar puntos de conexión privados en la red virtual del concentrador. En la implementación de línea base, los puntos de conexión se implementan en una subred dedicada dentro de la red virtual de radio. Este enfoque reduce el tráfico que pasa a través de la conexión de red emparejada. Mantiene los recursos que pertenecen al clúster en la misma red virtual. También puede aplicar reglas de seguridad pormenorizadas en el nivel de subred mediante grupos de seguridad de red (NSG).

Para más información, consulte Opciones de implementación de Private Link.

Subred del servidor de API de AKS

Puede configurar un clúster de AKS para que use la integración de red virtual del servidor de API, que proyecta el punto de conexión del servidor de API del clúster en una subred delegada de la red virtual. Esta configuración se denomina clúster privado porque garantiza que todo el tráfico entre el servidor de API, los grupos de nodos y los clientes conectados permanezcan completamente dentro de la red privada.

Toda la comunicación entre el servidor de API de Kubernetes administrado por AKS y los clientes (tanto los clientes internos del clúster como los externos) están restringidos a una red de confianza.

Con un clúster privado, puede usar NSG y otros controles de red integrados para proteger su entorno. Esta configuración prohíbe cualquier acceso público no autorizado entre Internet y el entorno. Para obtener más información, consulte Creación de un clúster de AKS privado.

Plan de direcciones IP

Descargue un archivo Visio de esta arquitectura.

Esta arquitectura de referencia usa varios enfoques de red, cada uno de los cuales requiere un espacio de direcciones IP:

La red virtual de Azure que utiliza para recursos como los nodos del clúster, el servidor API del clúster, los puntos de conexión privados para los servicios de Azure y el Portal de Aplicaciones.
El clúster usa Azure Container Networking Interface (CNI) Overlay, que asigna direcciones IP a los pods de un espacio de direcciones independiente de la red virtual de Azure.

Espacio de direcciones IP de red virtual

El espacio de direcciones de la red virtual de Azure debe ser lo suficientemente grande como para contener las subredes. Tenga en cuenta todas las entidades que reciben tráfico. Kubernetes asigna direcciones IP para las entidades desde el espacio de direcciones de subred. Tenga en cuenta los siguientes puntos al planear las direcciones IP de la red virtual de Azure:

Actualizaciones: AKS actualiza los nodos periódicamente para asegurarse de que las máquinas virtuales subyacentes están up-to-date en las características de seguridad y otras revisiones del sistema. Durante un proceso de actualización, AKS crea un nodo que hospeda temporalmente los pods, mientras que el nodo de actualización se acordona y se purga. Ese nodo temporal recibe una dirección IP de la subred del clúster. Asegúrese de que tiene suficiente espacio de direcciones para las direcciones IP del nodo temporal.

En esta arquitectura, los pods se asignan a direcciones IP en el espacio de direcciones de pods de superposición de Azure CNI, incluso durante las actualizaciones graduales. Este método reduce el número total de direcciones IP usadas en la red virtual de Azure en comparación con otros métodos de red de Kubernetes.
Escalabilidad: Tenga en cuenta el número total de nodos de usuario y sistema y sus límites máximos de escalabilidad. Por ejemplo, si desea aumentar la capacidad al 400%, necesita cuatro veces el número de direcciones para todos los nodos escalados horizontalmente.

Como esta arquitectura usa la superposición de Azure CNI, la escalabilidad de los pods no afecta al espacio de direcciones de la red virtual.
Direcciones de Private Link: factorice las direcciones que son necesarias para la comunicación con otros servicios de Azure a través de Private Link. Esta arquitectura tiene dos direcciones asignadas para los vínculos a Container Registry y Key Vault.
Direcciones del servidor de API de clúster privado: La integración de red virtual del servidor de API le ayuda a proyectar el servidor de API de AKS como punto de conexión dentro de la red virtual. Esta característica requiere un tamaño mínimo de subred, por lo que debe asegurarse de cumplir estos requisitos previos durante la planeación de red.
Direcciones IP reservadas: Azure reserva direcciones específicas para sus usos. No se pueden asignar.

La lista anterior no es exhaustiva. Si el diseño tiene otros recursos que afectan al número de direcciones IP disponibles, acomode esas direcciones.

Esta arquitectura está diseñada para una sola carga de trabajo. En un clúster de AKS de producción, separe siempre el grupo de nodos del sistema del grupo de nodos de usuario. Al ejecutar varias cargas de trabajo en el clúster, es posible que desee aislar los grupos de nodos de usuario uno de otro. Este aislamiento da como resultado más subredes que tienen un tamaño menor. El recurso de entrada también puede ser más complejo. Como resultado, es posible que necesite varios controladores de entrada que cada uno requiera direcciones IP adicionales.

Espacio de direcciones IP de pods

Azure CNI Overlay asigna direcciones IP a pods mediante un espacio de direcciones dedicado, que es independiente del espacio de direcciones que se usa en la red virtual. Use un espacio de direcciones IP que no se superponga con la red virtual ni con ninguna red virtual emparejada. Pero si crea varios clústeres de AKS, puede usar de forma segura el mismo espacio de direcciones de pod en cada clúster.

Azure CNI Overlay asigna a cada nodo un espacio de direcciones /24 para sus pods. Es importante asegurarse de que el espacio de direcciones del pod sea lo suficientemente grande. Permita tantos bloques /24 como necesite para el número de nodos del clúster. Recuerde incluir los nodos temporales creados durante las actualizaciones o las operaciones de escalabilidad horizontal. Por ejemplo, si usa un espacio de direcciones /16 para el intervalo de enrutamiento entre dominios (CIDR) sin clases, el clúster puede crecer hasta un máximo de aproximadamente 250 nodos.

Cada nodo admite hasta 250 pods y este límite incluye los pods que se crean temporalmente durante las actualizaciones.

Para más información, consulte las instrucciones sobre la planeación de direcciones IP para la superposición de Azure CNI.

Otras observaciones sobre el espacio de direcciones IP

Para todos los aspectos sobre redes relacionados con esta arquitectura, consulte Topología de red de referencia de AKS. Para más información sobre cómo planear el direccionamiento IP para un clúster de AKS, consulte Configuración de redes de Azure CNI en AKS.

Complementos y características en vista previa (gb)

Kubernetes y AKS evolucionan continuamente, con ciclos de versión más rápidos que el software para entornos locales. Esta arquitectura de línea de base depende de características específicas de la versión preliminar de AKS y complementos de AKS. Tenga en cuenta las siguientes diferencias entre las características en versión preliminar y los complementos:

El equipo de AKS describe las características en versión preliminar como enviadas y mejorando porque muchas de las características en versión preliminar permanecen en ese estado durante solo unos meses antes de pasar a la fase de disponibilidad general (GA).
Los complementos y extensiones de AKS proporcionan funcionalidades adicionales admitidas. AKS administra su instalación, configuración y ciclo de vida.

La arquitectura base no incluye todas las características de vista previa ni complementos. En vez de eso, solo incluye las que aportan un valor significativo a un clúster de uso general. A medida que estas características salen de la versión preliminar, esta arquitectura de línea base se revisa en consecuencia. Hay otras características en versión preliminar o complementos de AKS que es posible que quiera evaluar en clústeres de preproducción. Estas características pueden mejorar la seguridad, la capacidad de administración u otros requisitos. Con complementos que no son de Microsoft, debe instalarlos y mantenerlos, lo que incluye el seguimiento de las versiones disponibles y la instalación de actualizaciones después de actualizar la versión de Kubernetes de un clúster.

Referencia de imágenes de contenedor

El clúster puede contener la carga de trabajo y otras imágenes, como el controlador de entrada. Algunas de esas imágenes pueden residir en registros públicos. Tenga en cuenta los siguientes puntos al extraer las imágenes en el clúster:

Autentique el clúster para extraer la imagen.
Si usa una imagen pública, importe la imagen en un registro de contenedores que se alinee con el objetivo de nivel de servicio (SLO). De lo contrario, la imagen podría estar sujeta a problemas de disponibilidad inesperados. Si la imagen no está disponible cuando la necesita, pueden producirse problemas operativos. Tenga en cuenta las siguientes ventajas de usar un registro de contenedor privado, como Azure Container Registry, en lugar de un registro público:
- Puede bloquear el acceso no autorizado a las imágenes.
- No tiene dependencias públicas.
- Puede acceder a los registros de extracción de imágenes para supervisar las actividades y evaluar los problemas de conectividad.
- Puede aprovechar las ventajas del examen de contenedores y el cumplimiento de imágenes integrados.
Extraiga las imágenes de registros autorizados. Puede aplicar esta restricción mediante Azure Policy. En esta implementación de referencia, el clúster solo extrae imágenes de la instancia dedicada de Azure Container Registry que se implementa con el clúster.

Configuración del cálculo del clúster base

En AKS, cada grupo de nodos normalmente se asigna a un conjunto de escalado de máquinas virtuales. Los nodos son máquinas virtuales (VM) en cada grupo de nodos.

Considere la posibilidad de usar un tamaño de máquina virtual más pequeño para el grupo de nodos del sistema a fin de minimizar los costos. Esta implementación de referencia despliega un grupo de nodos del sistema con tres nodos D2dv5. Ese tamaño es suficiente para satisfacer la carga esperada de los pods del sistema. El disco efímero del sistema operativo es de 64 GB.

Al planear la capacidad de un grupo de nodos de usuario, tenga en cuenta las siguientes recomendaciones:

Elija tamaños de nodo mayores para empaquetar el número máximo de pods establecido en un nodo. Los nodos grandes minimizan la superficie de los servicios que se ejecutan en todos los nodos, como la supervisión y el registro.
Si tiene requisitos específicos para la carga de trabajo, seleccione el tipo de máquina virtual adecuado. Por ejemplo, puede que necesite un producto optimizado para la memoria en algunas cargas de trabajo o un producto acelerado mediante GPU en otras. Para más información, consulte Tamaños de máquinas virtuales en Azure.
Implemente al menos dos nodos para que la carga de trabajo pueda seguir un patrón de alta disponibilidad con dos réplicas. Con AKS, puede cambiar el número de nodos sin volver a crear el clúster.
Planee los tamaños de nodo reales de la carga de trabajo en función de los requisitos que determine el equipo de diseño. En función de los requisitos empresariales, esta arquitectura usa la SKU D4dv5 para la carga de trabajo de producción.
Supongamos que la carga de trabajo consume hasta 80% de cada nodo al planear la capacidad del clúster. El 20 % restante está reservado para los servicios de AKS.
Establezca los pods máximos para cada nodo en función del planeamiento de capacidad. Si intenta establecer una línea base de capacidad, comience con un valor de 30. Ajuste ese valor en función de los requisitos de la carga de trabajo, el tamaño del nodo y las restricciones de dirección IP.

Selección de un sistema operativo

La mayoría de clústeres de AKS usan Linux como sistema operativo en sus grupos de nodos. En esta implementación de referencia, usamos Azure Linux, que es una distribución ligera y protegida de Linux que está optimizada para Azure. Puede elegir otra distribución de Linux como Ubuntu si lo prefiere o si Azure Linux no cumple sus requisitos. Si elige otro sistema operativo, asegúrese de que el disco del sistema operativo tenga el tamaño adecuado para esa imagen. Algunas distribuciones requieren más espacio que Azure Linux, por lo que es posible que tenga que aumentar el tamaño del disco para evitar problemas de implementación o tiempo de ejecución.

Si la carga de trabajo se compone de tecnologías mixtas, puede usar diferentes sistemas operativos en distintos grupos de nodos. Pero si no necesita sistemas operativos diferentes, se recomienda usar un único sistema operativo para todos los grupos de nodos de carga de trabajo para reducir la complejidad operativa.

Integración de Microsoft Entra ID para el clúster

Es fundamental proteger el acceso hacia el clúster y desde él. Use la perspectiva del clúster para comprender la diferencia entre el tráfico dentro y fuera del mismo:

Acceso dentro de fuera: Considere el acceso de AKS a componentes de Azure, como la infraestructura de red, Container Registry y Key Vault. Autorice solo los recursos a los que el clúster tiene permitido acceder.
Acceso externo: Proporcione acceso a identidades al clúster de Kubernetes. Autorice solo las entidades externas a las que se permite el acceso al servidor de API de Kubernetes y Azure Resource Manager.

Acceso de AKS a los componentes de Azure

Hay dos maneras de administrar el acceso de AKS a Azure a través de Microsoft Entra ID: entidades de servicio o identidades administradas para recursos de Azure.

De los dos métodos para administrar el acceso de AKS a Azure, se recomiendan identidades administradas. Con las entidades de servicio, debe administrar y rotar secretos, ya sea de forma manual o mediante programación. Con las identidades administradas, Microsoft Entra ID administra y realiza la autenticación y la rotación puntual de secretos automáticamente.

Se recomienda habilitar y usar identidades administradas en AKS para que el clúster pueda interactuar con recursos externos de Azure a través de Microsoft Entra ID. Si no usa la integración del identificador de Entra de Microsoft inmediatamente, puede agregarla más adelante.

De forma predeterminada, el clúster usa dos identidades principales: la identidad del clúster y la identidad de kubelet. Los componentes del plano de control de AKS usan la identidad del clúster para administrar los recursos del clúster, incluidos los equilibradores de carga de entrada y las direcciones IP públicas administradas de AKS. La identidad de kubelet se autentica con Container Registry. Algunos complementos también admiten la autenticación mediante una identidad administrada.

Debe usar identidades administradas cuando el clúster necesite extraer imágenes de un registro de contenedor. Esta acción requiere que el clúster obtenga las credenciales del registro, lo cual se logra otorgando acceso a la identidad administrada kubelet del clúster en su registro. Si no usa una identidad administrada, puede almacenar esa información en un secreto de Kubernetes y usarla imagePullSecrets para recuperarla. No se recomienda este enfoque porque presenta complejidades de seguridad, incluida la necesidad de conocer el secreto de antemano y almacenarlo en la canalización de DevOps. También agrega sobrecarga operativa porque debe rotar la clave secreta.

En esta arquitectura, el clúster tiene acceso a los recursos de Azure que están protegidos por Microsoft Entra ID y realiza operaciones que admiten identidades administradas. Asigne el control de acceso basado en rol de Azure (Azure RBAC) y los permisos a las identidades administradas del clúster, en función de las operaciones que el clúster haga. El clúster se autentica en Microsoft Entra ID y, a continuación, se le permite o deniega el acceso en función de los roles que tenga asignados. Estos son algunos ejemplos de esta implementación de referencia donde se han asignado roles integrados de Azure al clúster:

El rol Colaborador de red administra la capacidad del clúster para controlar la red virtual spokes. Con esta asignación de roles, la identidad asignada por el sistema del clúster de AKS puede funcionar con la subred dedicada para el servicio de controlador de entrada interno y el servidor de API privada de AKS.
El rol Colaborador de zona DNS privada administra la capacidad del clúster de vincular la zona directamente a la red virtual de radio que hospeda el clúster. Un clúster privado mantiene los registros DNS fuera de la red pública de Internet mediante una zona DNS privada. Pero todavía es posible crear un clúster de AKS privado con una dirección DNS pública. Se recomienda prohibir explícitamente esta característica estableciendo enablePrivateClusterPublicFQDN para false evitar la divulgación de la dirección IP privada del plano de control. Considere la posibilidad de usar Azure Policy para aplicar el uso de clústeres privados sin registros DNS públicos.
El Editor de métricas de monitoreo administra la capacidad del clúster para enviar métricas a Azure Monitor.
El rol AcrPull administra la capacidad del clúster para obtener imágenes desde las instancias especificadas del Registro de Contenedores.

Acceso al clúster

La integración de Microsoft Entra también simplifica la seguridad para el acceso de fuera hacia dentro. Por ejemplo, es posible que desee usar kubectl. Como paso inicial, puede ejecutar el comando az aks get-credentials para obtener las credenciales del clúster. Microsoft Entra ID autentica su identidad con los roles de Azure que tienen permitido obtener las credenciales del clúster. Para más información, consulte Permisos de los roles de clúster disponibles.

AKS admite el acceso a Kubernetes mediante Microsoft Entra ID como proveedor de identidades, integrándose con el RBAC nativo de Kubernetes o utilizando el RBAC nativo de Azure para controlar el acceso al clúster. Estas dos opciones se describen en las secciones siguientes.

Asociación de RBAC de Kubernetes con Microsoft Entra ID

Kubernetes admite RBAC mediante los siguientes objetos de API:

Un conjunto de permisos que se definen mediante un objeto Role o ClusterRole para los permisos de todo el clúster.
Enlaces que asignan usuarios y grupos que tienen permiso para realizar las acciones. Defina enlaces mediante un objeto RoleBinding o ClusterRoleBinding.

Kubernetes tiene algunos roles integrados, como el administrador de clústeres, la edición y la vista. Enlace esos roles a usuarios y grupos de Microsoft Entra para usar el directorio empresarial para administrar el acceso. Para obtener más información, consulte Uso de RBAC de Kubernetes con la integración de Microsoft Entra.

Asegúrese de incluir los grupos de Microsoft Entra para el acceso al clúster y al espacio de nombres en las revisiones de acceso de Microsoft Entra.

Uso de Azure RBAC para la autorización de Kubernetes

Se recomienda usar RBAC de Azure y asignaciones de roles de Azure para aplicar comprobaciones de autorización en el clúster. Este enfoque de autorización se integra con la autenticación de Microsoft Entra. Puede asignar roles en varios ámbitos, como el grupo de administración, la suscripción o el grupo de recursos. A continuación, todos los clústeres del ámbito heredan un conjunto coherente de asignaciones de roles con respecto a quién tiene permisos para acceder a los objetos del clúster de Kubernetes.

No recomendamos usar el RBAC nativo de Kubernetes con ClusterRoleBindings y RoleBindings.

Para obtener más información, consulte Autorización de Azure RBAC para Kubernetes.

Cuentas locales

AKS admite la autenticación de usuarios de Kubernetes nativa. No se recomienda utilizar este método para proporcionar acceso de usuario a los clústeres. Este método se basa en certificados y se realiza externamente en el proveedor de identidades principal, lo que dificulta el control de acceso y la gobernanza de usuarios centralizados. Administre siempre el acceso al clúster mediante el identificador de Entra de Microsoft y configure el clúster para prohibir explícitamente el acceso a la cuenta local.

En esta implementación de referencia, el acceso a las cuentas de clúster local está prohibido explícitamente cuando el sistema implementa el clúster.

Integración de Microsoft Entra ID para la carga de trabajo

De forma similar a las identidades administradas por el sistema de Azure para todo el clúster, puede asignar identidades administradas en el nivel de pod. Una identidad de carga de trabajo permite que la carga de trabajo hospedada tenga acceso a los recursos a través de Microsoft Entra ID. Por ejemplo, supongamos que la carga de trabajo almacena archivos en Azure Storage. Cuando necesita acceder a esos archivos, el pod se autentica en el recurso como una identidad administrada de Azure.

En esta implementación de referencia, el ID de carga de trabajo de Microsoft Entra ID en AKS proporciona las identidades administradas para los pods. Este enfoque se integra con las funcionalidades nativas de Kubernetes para federarse con proveedores de identidades externos. Para más información, consulte Federación de identidades de carga de trabajo.

Selección de un modelo de red

Important

El 31 de marzo de 2028 , se retirarán las redes kubenet para Azure Kubernetes Service (AKS).

Para evitar interrupciones del servicio, deberáactualizar a la superposición de Azure Container Networking Interface (CNI)antes de esa fecha, cuando ya no se admita la ejecución de cargas de trabajo en kubenet para AKS.

AKS admite varios modelos de red, como kubenet, CNI y Overlay de Azure CNI. Los modelos de CNI son los modelos más avanzados y proporcionan un alto rendimiento. Cuando se comunican entre pods, el rendimiento de CNI es similar al rendimiento de las máquinas virtuales de una red virtual. CNI también proporciona un control de seguridad mejorado porque permite el uso de la directiva de red de Azure. Se recomienda un modelo de red basado en CNI.

En el modelo CNI no superpuesto, cada pod obtiene una dirección IP del espacio de direcciones de subred. Los recursos de la misma red (o recursos emparejados) pueden tener acceso a los pods directamente a través de su dirección IP. La traducción de direcciones de red (NAT) no es necesaria para enrutar ese tráfico.

En esta implementación de referencia, usamos Azure CNI Overlay. Solo asigna direcciones IP desde la subred del grupo de nodos para los nodos y usa una capa de superposición optimizada para direcciones IP de pod. Como la superposición de Azure CNI usa menos direcciones IP de red virtual que muchos otros modelos, se recomienda para las implementaciones restringidas por direcciones IP.

Para más información sobre los modelos, consulte Configuración de redes superpuestas de Azure CNI en AKS y Procedimientos recomendados para la conectividad de red y la seguridad en AKS.

implementación de recursos de entrada

Los recursos de entrada de Kubernetes gestionan el enrutamiento y la distribución del tráfico entrante al clúster. Hay dos partes de los recursos de entrada:

El equilibrador de carga interno que AKS administra: El equilibrador de carga expone el controlador de entrada a través de una dirección IP estática privada. Sirve de punto de contacto único que recibe los flujos entrantes.

Esta arquitectura usa Azure Load Balancer. Load Balancer está fuera del clúster, en una subred dedicada a los recursos de entrada. Recibe el tráfico de Application Gateway y la comunicación se realiza a través de la seguridad de la capa de transporte (TLS). Para más información sobre el cifrado TLS para el tráfico entrante, consulte la sección Flujo de tráfico de entrada .
Controlador de entrada: En este ejemplo se usa Traefik. Se ejecuta en el grupo de nodos de usuario del clúster. Recibe tráfico del equilibrador de carga interno, termina TLS y lo desvía a los pods de carga de trabajo a través de HTTP.

El controlador de entrada es un componente crítico del clúster. Tenga en cuenta los siguientes puntos al configurar este componente.

Restrinja el controlador de entrada a un ámbito específico de operaciones como parte de las decisiones de diseño. Por ejemplo, puede permitir que el controlador interactúe solo con los pods que ejecutan una carga de trabajo específica.
Evite colocar réplicas en el mismo nodo para repartir la carga y ayudar a garantizar la continuidad empresarial si un nodo falla. Use podAntiAffinity para este propósito.
Restrinja los pods para que se programen solo en el grupo de nodos de usuario mediante nodeSelectors. Esta configuración aísla la carga de trabajo y los pods del sistema.
Abra puertos y protocolos que permitan a entidades específicas enviar tráfico al controlador de entrada. En esta arquitectura, Traefik solo recibe tráfico de Application Gateway.
Configure los valores de readinessProbe y livenessProbe que supervisarán el mantenimiento de los pods en el intervalo especificado. El controlador de entrada debe enviar señales que indiquen el mantenimiento de los pods.
Considere la posibilidad de restringir el acceso del controlador de entrada a recursos específicos y limitar las acciones que puede realizar. Puede implementar esa restricción mediante los permisos RBAC de Kubernetes. Por ejemplo, en esta arquitectura, se han concedido permisos a Traefik para ver, obtener y enumerar servicios y puntos de conexión usando reglas en el objeto ClusterRole de Kubernetes.

Note

Elija un controlador de entrada adecuado en función de sus requisitos, carga de trabajo, conjunto de aptitudes del equipo y compatibilidad de las opciones de tecnología. Lo más importante es que el controlador de entrada debe cumplir sus expectativas de SLO.

Traefik es una opción de código abierto para un clúster de Kubernetes y se ha elegido para esta arquitectura con fines ilustrativos. Muestra la integración de productos que no son de Microsoft con los servicios de Azure. Por ejemplo, la implementación muestra cómo integrar Traefik con el ID de carga de trabajo de Microsoft Entra y Key Vault.

También puede usar el controlador de entrada de Application Gateway, que se integra bien con AKS. Application Gateway proporciona ventajas más allá de su rol como controlador de entrada. Actúa como punto de entrada de red virtual para el clúster y puede observar el tráfico que entra en el clúster. Use Application Gateway si la aplicación requiere un firewall de aplicaciones web. También habilita la terminación TLS.

Configuración del enrutador

El controlador de entrada usa rutas para determinar dónde enviar el tráfico. Las rutas especifican el puerto de origen en el que se recibe el tráfico e información sobre los puertos de destino y protocolos.

A continuación, se muestra un ejemplo de esta arquitectura:

Traefik usa el proveedor de Kubernetes para configurar las rutas. Las opciones annotations, tls y entrypoints indican que las rutas se atienden a través de HTTPS. La opción middlewares especifica que solo se permite el tráfico procedente de la subred de Application Gateway. Las respuestas usan la codificación gzip si el cliente acepta. Dado que Traefik realiza la terminación TLS, la comunicación con los servicios de back-end se realiza a través de HTTP.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port:
              number: 80

Protección del flujo de red

En esta arquitectura, el flujo de red incluye los siguientes tipos de tráfico:

Tráfico de entrada del cliente a la carga de trabajo que se ejecuta en el clúster.
El tráfico de salida de un pod o nodo del clúster a un servicio externo.
Tráfico de pod a pod entre pods. Este tráfico incluye la comunicación entre el controlador de entrada y la carga de trabajo. Si la carga de trabajo se compone de varias aplicaciones implementadas en el clúster, la comunicación entre esas aplicaciones también queda dentro de esta categoría.
Tráfico de administración entre el cliente y el servidor de API de Kubernetes.

Descargue un archivo Visio de esta arquitectura.

Esta arquitectura tiene varios niveles de seguridad para proteger todos los tipos de tráfico.

Flujo de tráfico de entrada

La arquitectura solo acepta las solicitudes cifradas TLS del cliente. TLS v1.2 es la versión mínima permitida con una serie restringida de cifrados. La correspondencia de la indicación de nombre de servidor (SNI) estricta está habilitada. TLS de un extremo a otro se configura a través de Application Gateway mediante el uso de dos certificados TLS diferentes, tal como se muestra en el siguiente diagrama.

Descargue un archivo Visio de esta arquitectura.

El cliente envía una solicitud HTTPS al nombre de dominio: bicycle.contoso.com. Ese nombre se asocia a través de un registro A de DNS a la dirección IP pública de Application Gateway. Este tráfico se cifra para ayudar a garantizar que no se pueda inspeccionar o cambiar el tráfico entre el explorador cliente y la puerta de enlace.
Application Gateway cuenta con un firewall de aplicaciones web integrado y negocia el protocolo de enlace TLS para bicycle.contoso.com y solo permite cifrados seguros. Application Gateway es un punto de terminación TLS, lo que es importante porque el firewall de aplicaciones web de Application Gateway debe inspeccionar la solicitud y la respuesta de texto no cifrado. Key Vault almacena el certificado TLS. El clúster accede a él con una identidad administrada asignada por el usuario que se integra con Application Gateway. Para obtener más información, consulte Terminación TLS con certificados de Key Vault.

Application Gateway procesa reglas de inspección de firewall de aplicaciones web y ejecuta reglas de enrutamiento que reenvían el tráfico al back-end configurado.
A medida que el tráfico pasa de Application Gateway a la parte posterior, se cifra de nuevo con otro certificado TLS, que es un comodín para *.aks-ingress.contoso.com, ya que se reenvía al equilibrador de carga interno. Este nuevo cifrado ayuda a garantizar que el tráfico no seguro no fluya hacia la subred del clúster.
El controlador de entrada recibe el tráfico cifrado a través del equilibrador de carga. El controlador es otro punto de terminación TLS para *.aks-ingress.contoso.com y reenvía el tráfico a los pods de carga de trabajo a través de HTTP. Los certificados se almacenan en Key Vault y se montan en el clúster mediante Container Storage Interface (CSI). Para más información, consulte Administración de secretos.

Puede implementar el tráfico TLS de un extremo a otro en cada salto hasta el pod de carga de trabajo. Asegúrese de medir el rendimiento, la latencia y el impacto operativo al tomar la decisión de proteger el tráfico de pod a pod. Para la mayoría de los clústeres de un solo inquilino, con RBAC del plano de control adecuado y prácticas maduras del ciclo de vida de desarrollo de software, es suficiente cifrar TLS hasta el controlador de entrada y proteger con el firewall de aplicaciones web. Este enfoque minimiza la sobrecarga en la administración de cargas de trabajo y la sobrecarga debido a un rendimiento de red deficiente. Los requisitos de carga de trabajo y cumplimiento dictan dónde se realiza la terminación TLS.

Flujo de tráfico de salida

En esta arquitectura, se recomienda que todo el tráfico de salida del clúster pase por Azure Firewall. También puede usar su propia aplicación virtual de red similar. No se recomiendan otras opciones de salida, como Azure NAT Gateway o un proxy HTTP porque no proporcionan inspección del tráfico de red. Para el control de Confianza Cero y la capacidad de inspeccionar el tráfico, envíe todo el tráfico de salida a través de Azure Firewall. Implemente esta configuración con rutas definidas por el usuario (UDR). El siguiente salto de la ruta es la dirección IP privada de Azure Firewall. Azure Firewall decide si se va a bloquear o permitir el tráfico de salida en función de las reglas que defina o las reglas integradas de inteligencia sobre amenazas.

Una alternativa a Azure Firewall es usar la característica de proxy HTTP de AKS. Todo el tráfico que sale del clúster va a la dirección IP del proxy HTTP, que reenvía el tráfico o lo descarta.

Para cualquiera de los métodos, revise las reglas de tráfico de red de salida necesarias para AKS.

Note

Si usa un equilibrador de carga público como punto público para el tráfico de entrada y el tráfico de salida a través de Azure Firewall mediante UDR, es posible que vea un escenario de enrutamiento asimétrico. Esta arquitectura usa equilibradores de carga internos en una subred de entrada dedicada detrás de Application Gateway. Esta elección de diseño mejora la seguridad y también elimina los problemas de enrutamiento asimétrico. O bien puede enrutar el tráfico de entrada a través de Firewall antes o después de Application Gateway, pero este enfoque no es necesario para la mayoría de las situaciones y no se recomienda. Para obtener más información sobre el enrutamiento asimétrico, consulte Integración de Firewall con Azure Standard Load Balancer.

Una excepción al control de confianza cero es cuando el clúster necesita comunicarse con otros recursos de Azure. Por ejemplo, el clúster podría necesitar extraer una imagen actualizada del registro de contenedor o secretos de Key Vault. En estos escenarios, se recomienda usar Private Link.

La ventaja de usar Private Link es que las subredes específicas llegan directamente al servicio y el tráfico entre el clúster y los servicios no pasa por Internet. Una desventaja es que Private Link necesita una configuración adicional en lugar de usar el servicio de destino a través de su punto de conexión público. Además, no todos los servicios o productos de Azure admiten Private Link. En esos casos, considere la posibilidad de habilitar un punto de conexión de servicio de red virtual en la subred para tener acceso al servicio.

Si Private Link o los puntos de conexión de servicio no son una opción, puede llegar a otros servicios a través de sus puntos de conexión públicos y controlar el acceso a través de reglas de Azure Firewall y el firewall integrado en el servicio de destino. Dado que este tráfico pasa por las direcciones IP estáticas del firewall, puede agregar esas direcciones a la lista de direcciones IP permitidas del servicio.

Una desventaja de conectarse a los servicios de Azure a través de puntos de conexión públicos es que Azure Firewall necesita más reglas para asegurarse de que solo permite el tráfico desde una subred específica. Tenga en cuenta esas direcciones cuando planee usar varias direcciones IP para el tráfico de salida con Azure Firewall. De lo contrario, podría llegar al agotamiento del puerto. Para más información sobre cómo planificar varias direcciones IP, consulte para obtener más información Crear un Azure Firewall con varias direcciones IP.

Tráfico de pod a pod

De forma predeterminada, un pod puede aceptar el tráfico de cualquier otro pod del clúster. Use el elemento NetworkPolicy de Kubernetes para restringir el tráfico de red entre pods. Aplique las directivas cuidadosamente o podría tener una situación en la que se bloquee un flujo de red crítico. Solo permite rutas de comunicación específicas, según sea necesario, como el tráfico entre el controlador de entrada y la carga de trabajo. Para obtener más información, consulte Directivas de red.

Habilite la directiva de red al configurar el clúster porque no se puede agregar más adelante. Hay algunas opciones para las tecnologías que implementan NetworkPolicy. Se recomienda utilizar la política de red de Azure, que requiere Azure CNI. Otras opciones incluyen Calico Network Policy, una opción de código abierto conocida. Tenga en cuenta Calico si debe administrar directivas de red para todo el clúster. Calico no está incluida en el soporte técnico estándar de Azure.

Para obtener más información, consulte Diferencias entre los motores de directivas de red de Azure.

Tráfico de administración

Como parte de la ejecución del clúster, el servidor de API de Kubernetes recibe tráfico de los recursos que desean realizar operaciones de administración en el clúster, como las solicitudes para crear recursos para escalar el clúster. Algunos ejemplos de estos recursos son el grupo de agentes de compilación en una canalización DevOps, una instancia de Azure Bastion en la subred de Bastion y los propios grupos de nodos. En lugar de aceptar este tráfico de administración de todas las direcciones IP, se recomienda configurar un clúster de AKS privado.

Para obtener más información, consulte Definición de intervalos IP de servidor de API autorizado.

Se recomienda implementar el clúster de AKS como un clúster privado. Todo el tráfico del plano de control y del grupo de nodos permanece en la red privada y no se expone a la red pública de Internet. Esta implementación de referencia configura un clúster privado mediante la integración de red virtual del servidor de API.

El tráfico privado a un clúster de AKS privado puede originarse desde la red virtual de spoke, desde redes emparejadas o desde puntos de conexión privados en redes remotas. Aunque los nodos de AKS residen naturalmente en el satélite, los clientes que realizan tareas administrativas requieren una ruta de acceso de red dedicada para llegar de forma privada al servidor de API de AKS. Puede establecer esta conectividad de las siguientes maneras:

Use Azure Bastion para abrir un túnel directamente en el servidor de API de AKS.
Aprovisione una máquina virtual de jump-box y conéctese a ella a través de Azure Bastion.

En la implementación de referencia, se usa Azure Bastion para tunelizar al servidor de API de AKS al realizar operaciones de administración de clústeres.

Los entornos inferiores pueden considerar la posibilidad de relajar esta recomendación de clúster privado para mayor comodidad. Pero los clústeres de AKS de producción siempre deben implementarse como clústeres privados para una línea base de implementación segura.

Adición de administración de secretos

Almacene secretos en un almacén de claves administrado, como Key Vault. La ventaja es que un almacén de claves administrado maneja la rotación de secretos. Proporciona cifrado seguro y un registro de auditoría de acceso. También mantiene los secretos principales fuera de la canalización de implementación. En esta arquitectura, se habilita y configura un firewall de Key Vault y Private Link se usa para conectarse a los recursos de Azure, como para que Key Vault acceda a secretos y certificados.

Key Vault está bien integrado con otros servicios de Azure. Use la característica integrada de esos servicios para acceder a los secretos. Para obtener más información sobre cómo Azure Application Gateway accede a los certificados TLS para el flujo de entrada, consulte la sección Flujo de tráfico de entrada.

El modelo de permisos de RBAC de Azure para Key Vault permite asignar las identidades de carga de trabajo a la asignación de roles Usuario de secretos de Key Vault o Lector de Key Vault y acceder a los secretos. Para más información, consulte Acceso a Key Vault mediante RBAC de Azure.

Acceso a los secretos del clúster

Debe usar identidades de carga de trabajo para permitir que un pod acceda a secretos desde un almacén específico. Para facilitar el proceso de recuperación, use un controlador CSI de almacén de secretos. Cuando el pod necesita un secreto, el controlador se conecta al almacén especificado, recupera el secreto de un volumen y monta ese volumen en el clúster. A continuación, el pod puede obtener el secreto del sistema de archivos del volumen.

El controlador CSI tiene muchos proveedores para admitir varios almacenes administrados. Esta implementación usa Key Vault con el controlador CSI del almacén de secretos. El complemento recupera el certificado TLS de Key Vault y carga el controlador en el pod que ejecuta el controlador de entrada. Esta operación se realiza durante la creación del pod y el volumen almacena las claves públicas y privadas.

Almacenamiento de cargas de trabajo

La carga de trabajo en esta arquitectura no tiene estado. Si debe almacenar el estado, recomendamos que lo persista fuera del clúster. La guía para el estado de la carga de trabajo está fuera del ámbito de este artículo.

Para más información, consulte Opciones de almacenamiento para aplicaciones en AKS.

Gestión de políticas

Una manera eficaz de administrar un clúster de AKS consiste en aplicar la gobernanza por medio de directivas. Kubernetes implementa políticas a través de Open Policy Agent (OPA) Gatekeeper. En el caso de AKS, las directivas se proporcionan a través de Azure Policy. Cada directiva se aplica a todos los clústeres de su ámbito. OPA Gatekeeper maneja la aplicación de políticas en el clúster y registra todas las verificaciones de políticas. Los cambios de directiva no se reflejan inmediatamente en el clúster, puede haber algunos retrasos.

Para administrar los clústeres de AKS, puede usar Azure Policy de varias maneras:

Impedir o restringir la implementación de clústeres de AKS en un grupo de recursos o una suscripción. Aplicar estándares para su organización. Por ejemplo, puede seguir una convención de nomenclatura o especificar una etiqueta.
Proteger el clúster de AKS mediante Azure Policy para Kubernetes.

Un ejemplo común de dónde una política puede ser útil es en el ámbito de la gobernanza y validación de imágenes de contenedores. Las imágenes de contenedor pueden ser un origen de vulnerabilidades y algunas organizaciones requieren que las imágenes de contenedor que no son de confianza se validen mediante una herramienta de análisis de imágenes de contenedor y, a continuación, se aprueben antes de que se puedan usar en un clúster de producción. Puede aplicar este proceso mediante Azure Policy y bloquear la implementación de imágenes de contenedor que no son de confianza en el clúster. Para obtener más información, consulte el patrón de cuarentena.

Al establecer directivas, aplíquelas en función de los requisitos de la carga de trabajo. Tenga en cuenta estos factores:

Decida si quiere establecer una colección de directivas, conocidas como iniciativas, o elegir directivas individuales. Azure Policy incluye dos iniciativas integradas: una básica y otra restringida. Cada una de las iniciativas es una colección de directivas integradas aplicables a un clúster de AKS. Se recomienda seleccionar una iniciativa y elegir otras directivas para el clúster y los recursos, como Container Registry, Application Gateway o Key Vault, que interactúan con el clúster. Elija directivas en función de los requisitos de su organización.
Decida si desea auditar o denegar la acción. En el modo auditoría , la acción se permite pero se marca como No compatible. Utilice procesos específicos para comprobar periódicamente los estados no compatibles y adoptar las medidas necesarias. En el modo Denegar , la acción se bloquea porque infringe la directiva. Tenga cuidado al elegir el modo Denegar porque puede ser demasiado restrictivo para que funcione la carga de trabajo.
Decida si tiene áreas en la carga de trabajo que no deben ser compatibles por diseño. Azure Policy puede especificar espacios de nombres de Kubernetes que están exentos de la aplicación de directivas. Se recomienda seguir aplicando directivas en modo auditoría para que conozca esas instancias.
Decida si tiene requisitos que no están cubiertos por las directivas integradas. Puede crear una definición de Azure Policy personalizada para aplicar sus directivas personalizadas de OPA Gatekeeper. No aplique directivas personalizadas directamente en el clúster. Para obtener más información, consulte Creación y asignación de definiciones de directivas personalizadas.
Decida si tiene requisitos a nivel de toda la organización. En caso afirmativo, agregue esas directivas en el nivel de grupo de administración. El clúster también debe asignar sus propias directivas para la carga de trabajo, aunque la organización tenga directivas genéricas.
Decida si debe asignar directivas de Azure a ámbitos específicos. Asegúrese de que las directivas de producción también se validen en el entorno de preproducción. De lo contrario, al implementar en el entorno de producción, pueda que se produzcan inesperadas restricciones adicionales que no se hayan tenido en cuenta en la preproducción.

Esta implementación de referencia habilita Azure Policy cuando se crea el clúster de AKS. La iniciativa restrictiva se asigna en modo auditoría para obtener visibilidad sobre la falta de cumplimiento.

La implementación también establece más directivas que no forman parte de una iniciativa integrada. Esas directivas se establecen en modo Denegar . Por ejemplo, hay una directiva para comprobar que las imágenes solo se extraigan de la instancia de Container Registry implementada.

Considere la posibilidad de crear sus propias iniciativas personalizadas. Integre las directivas aplicables a la carga de trabajo en una única asignación.

Para observar cómo funciona Azure Policy dentro del clúster, acceda a los registros de todos los pods en el espacio de nombres gatekeeper-system y a los registros de los pods azure-policy y azure-policy-webhook en el espacio de nombres kube-system.

Escalabilidad de nodos y pods

Con una demanda creciente, Kubernetes puede escalar horizontalmente agregando más pods a los nodos existentes, mediante el escalado horizontal automático de pods. Cuando Kubernetes ya no pueda programar más pods, el número de nodos debe aumentarse mediante el escalado automático de clústeres de AKS. Una solución de escalado completa debe contar con maneras de escalar las réplicas de pods y el número de nodos en el clúster.

Hay dos enfoques: el escalado automático o el escalado manual.

Tanto el escalado automático como el enfoque manual requieren supervisar y establecer alertas sobre el uso de CPU o las métricas personalizadas. Para el escalado de pods, el operador de la aplicación puede aumentar o disminuir el número de réplicas de pods ajustando el elemento ReplicaSet a través de las API de Kubernetes. Para el escalado de clústeres, un método es recibir una notificación cuando se produce un error en el programador de Kubernetes. Otra manera es inspeccionar los pods pendientes a lo largo del tiempo. Puede ajustar el número de nodos mediante la CLI de Azure o Azure Portal.

Se recomienda usar el enfoque de escalado automático porque algunos de los mecanismos manuales están integrados en el escalador automático.

Como método general, empiece por pruebas de rendimiento con un número mínimo de pods y nodos. Use esos valores para establecer la expectativa de línea base. A continuación, use una combinación de métricas de rendimiento y escalado manual para localizar cuellos de botella y comprender la respuesta de la aplicación al escalado. Por último, use estos datos para establecer los parámetros del escalado automático.

Escalador automático horizontal de pods

El escalador horizontal automático de pods (HPA) es un recurso de Kubernetes que escala el número de pods.

En el recurso HPA, se recomienda establecer el número mínimo y máximo de réplicas. Estos valores restringen los límites de escalado automático.

HPA puede escalar en función del uso de la CPU, del uso de memoria y de métricas personalizadas. Solo se proporciona de forma nativa el uso de la CPU. La definición HorizontalPodAutoscaler especifica los valores de destino de las métricas. Por ejemplo, la especificación establece el uso de CPU de destino. Mientras se ejecutan los pods, el controlador HPA usa la API de métricas de Kubernetes para comprobar el uso de CPU de cada pod. Compara ese valor con el uso objetivo y calcula la proporción. A continuación, usa la proporción para determinar si los pods están sobreasignados o infraasignados. Se basa en el programador de Kubernetes para asignar nuevos pods a nodos o quitar pods de nodos.

Es posible que se produzca una condición de carrera, como cuando el HPA realiza comprobaciones antes de que finalice una operación de escalado. Por lo tanto, el resultado podría ser un cálculo de proporción incorrecto. Para obtener más información, consulte Recuperación de eventos de escalado.

Si la carga de trabajo está orientada a eventos, una conocida opción de código abierto es el Escalado automático controlado por eventos de Kubernetes (KEDA). Considere KEDA si un origen de eventos, como una cola de mensajes, impulsa su carga de trabajo, en lugar de que la carga de trabajo dependa de la CPU o de la memoria. KEDA admite muchos orígenes de eventos o escaladores. Use la lista de orígenes de eventos que KEDA puede escalar a escaladores KEDA. La lista incluye el escalador de Azure Monitor, que es una forma cómoda de escalar las cargas de trabajo de KEDA en función de las métricas de Azure Monitor.

Escalador automático de clúster

El escalador automático del clúster es un componente de complemento de AKS que escala el número de nodos de un grupo de nodos. Agréguelo durante el aprovisionamiento del clúster. Necesita un escalador automático de clústeres independiente para cada grupo de nodos de usuario.

El programador de Kubernetes desencadena el escalador automático de clústeres. Cuando el programador de Kubernetes no puede programar un pod debido a restricciones de recursos, el escalador automático configura automáticamente un nuevo nodo en el grupo de nodos. Por el contrario, el escalador automático de clústeres comprueba la capacidad sin usar de los nodos. Si el nodo no funciona en la capacidad de operación esperada, los pods se mueven a otro nodo y se elimina el nodo sin usar.

Al habilitar el escalador automático, establezca el número máximo y mínimo de nodos. Los valores recomendados dependen de la expectativa de rendimiento de la carga de trabajo, de cuánto se desea que crezca el clúster y de las implicaciones de costos. El número mínimo es la capacidad reservada para ese grupo de nodos. En esta implementación de referencia, el valor mínimo se establece en dos debido a la simplicidad de la carga de trabajo.

En el grupo de nodos del sistema, el valor mínimo recomendado es tres.

Decisiones de continuidad del negocio

Para mantener la continuidad empresarial, defina el SLO para la infraestructura y la aplicación. Para obtener más información, consulte Recomendaciones para definir objetivos de confiabilidad. Revise las condiciones del Acuerdo de Nivel de Servicio (SLA) para AKS en el artículo SLA más reciente para servicios en línea .

Nodos de clúster

Para cumplir el nivel mínimo de disponibilidad de las cargas de trabajo, se necesitan varios nodos en un grupo de nodos. Si un nodo falla, otro nodo del mismo grupo de nodos y clúster puede seguir ejecutando la aplicación. En cuanto a la confiabilidad, se recomiendan tres nodos para el grupo de nodos del sistema. Para el grupo de nodos de usuario, empiece con dos nodos al menos. Si necesita una mayor disponibilidad o capacidad, escale horizontalmente para agregar más nodos.

Aísle las aplicaciones de los servicios del sistema colocándolo en un grupo de nodos independiente, denominado grupo de nodos de usuario. De este modo, los servicios de Kubernetes se ejecutan en nodos dedicados y no compiten con la carga de trabajo. Se recomienda el uso de etiquetas y valores taint para identificar el grupo de nodos y programar la carga de trabajo. Asegúrese de que el grupo de nodos del sistema esté marcado con el taint CriticalAddonsOnly para evitar que los pods de aplicación se asignen a grupos de nodos del sistema.

Las tareas de mantenimiento normales en el clúster, como las actualizaciones oportunas, son cruciales para la confiabilidad. También se recomienda supervisar el mantenimiento de los pods a través de sondeos.

Disponibilidad del pod

Especifique los requisitos de recursos de Pod: Se recomienda especificar los requisitos de recursos de Pod en los despliegues. Después, el programador puede programar correctamente el pod. La confiabilidad se reduce considerablemente si no se pueden programar los pods.
Establecer presupuestos de interrupciones de pods: Esta configuración determina cuántas réplicas de una implementación pueden detenerse durante un evento de actualización o mejora. Para más información, consulte Presupuestos de interrupciones de pods.

Configure varias réplicas en la implementación para controlar interrupciones como errores de hardware. En el caso de eventos planeados como actualizaciones y mejoras, un presupuesto de interrupciones puede ayudar a garantizar que existan el número necesario de réplicas de pod para manejar la carga esperada de la aplicación.
Establezca cuotas de recursos en los espacios de nombres del entorno de trabajo: La cuota de recursos en un espacio de nombres ayuda a garantizar que las solicitudes y los límites de pod se configuran correctamente dentro de un despliegue. Para más información, consulte Aplicación de cuotas de recursos.

Note

Si establece cuotas de recursos en el nivel de clúster, pueden producirse problemas si implementa cargas de trabajo externas que no tienen solicitudes y límites adecuados. Al establecer cuotas en el nivel de espacio de nombres, garantiza que solo se aplican a los componentes de carga de trabajo.
Establecer solicitudes y límites de pod: Establezca solicitudes y límites para permitir que Kubernetes asigne eficazmente recursos de CPU y memoria a los pods. Proporciona una mayor densidad de los contenedores en un nodo. Las solicitudes y los límites también pueden aumentar la fiabilidad y, al mismo tiempo, reducir los costes debido a un mejor uso del hardware.

Para calcular los límites de una carga de trabajo, pruebe y cree una base de referencia. Comience con valores iguales para solicitudes y límites. A continuación, ajuste gradualmente esos valores hasta que establezca el umbral que provoca inestabilidad en el clúster.

Puede especificar solicitudes y límites en los manifiestos de implementación. Para más información, consulte Establecimiento de solicitudes y límites de pod.

Zonas de disponibilidad

Para protegerse contra algunos tipos de interrupciones, use zonas de disponibilidad si la región las admite. Los componentes del plano de control y los nodos de los grupos de nodos son, a continuación, con redundancia de zona, lo que significa que se distribuyen entre varias zonas. Si no está disponible una zona completa, un nodo de otra zona dentro de la región sigue estando disponible. Cada grupo de nodos se asigna a un conjunto de escalado de máquinas virtuales independiente, que administra las instancias de nodos y la escalabilidad. El servicio AKS administra las operaciones y la configuración del conjunto de escalado. Estas son algunas consideraciones que se deben tener en cuenta al habilitar varias zonas:

Toda la infraestructura: Elija una región que admita zonas de disponibilidad. Para más información, consulte las limitaciones. Para tener un SLA de tiempo de actividad, debe elegir el nivel Estándar o Premium. El SLA de disponibilidad es mayor cuando se utilizan zonas de disponibilidad.
Clúster: Solo puede establecer zonas de disponibilidad al crear el grupo de nodos. Después no se pueden cambiar. Los tamaños de nodo deben admitirse en todas las zonas para que sea posible la distribución esperada. El conjunto de escalado de máquinas virtuales subyacente proporciona la misma configuración de hardware entre zonas.

La redundancia de zona no solo se aplica a los grupos de nodos, sino también al plano de control. El plano de control de AKS abarca las zonas solicitadas, como los grupos de nodos. Si no usa la compatibilidad con zonas en el clúster, no se garantiza que los componentes del plano de control se distribuyan entre las zonas de disponibilidad.
Recursos dependientes: Para lograr el beneficio de resiliencia de usar zonas de disponibilidad, todas las dependencias de servicio también deben admitir zonas. Si un servicio dependiente no admite zonas, es posible que un error de zona provoque un error en el servicio.

Por ejemplo, supongamos que la carga de trabajo usa una base de datos que no es resistente a la zona. Si se produce un error, el nodo de AKS puede moverse a otra zona, pero la base de datos no se mueve con el nodo a esa zona, por lo que la carga de trabajo se interrumpe.

Para simplificar esta arquitectura, AKS se implementa en una sola región con grupos de nodos que abarcan tres zonas de disponibilidad. Otros recursos de la infraestructura, como Azure Firewall y Application Gateway, también se implementan en la misma región con compatibilidad con varias zonas. La replicación geográfica se habilita para Container Registry.

Varias regiones

Al habilitar zonas de disponibilidad, no es suficiente cobertura en el caso improbable de que se produzca un error en toda una región. Para tener una mayor disponibilidad, ejecute varios clústeres de AKS en diferentes regiones.

Se prefieren regiones emparejadas cuando estén disponibles. Una ventaja de utilizar regiones emparejadas es la fiabilidad durante las actualizaciones de plataforma. Azure se asegura de que solo se actualice una región del par cada vez. Algunas regiones no se pueden emparejar. Si la región no está emparejada, todavía puede implementar una solución de varias regiones seleccionando otras regiones que se vayan a usar. Considere la posibilidad de usar una canalización de integración continua y entrega continua (CI/CD), que se configura para orquestar la recuperación de un error de región. Las herramientas específicas de DevOps, como Flux, pueden facilitar las implementaciones de varias regiones.
Si un recurso de Azure admite redundancia geográfica, proporcione la ubicación en la que el servicio redundante tiene su región secundaria. Por ejemplo, al habilitar la replicación geográfica para Container Registry, replica automáticamente imágenes en las regiones de Azure seleccionadas. También proporciona acceso continuo a las imágenes incluso si la región primaria experimenta una interrupción.
Elija un enrutador de tráfico que pueda distribuir el tráfico entre zonas o regiones, en función de sus requisitos. Esta arquitectura implementa Load Balancer porque puede distribuir el tráfico no web entre zonas. Si necesita distribuir el tráfico entre regiones, considere la posibilidad de usar Azure Front Door. Para otras opciones, consulte Elección de equilibrador de carga.

Note

El escenario de ejemplo de línea de base de AKS para clústeres de varias regiones amplía la arquitectura de este artículo para incluir varias regiones en una configuración activa y de alta disponibilidad.

Recuperación ante desastres

Idealmente, si se produce un error en la región primaria, puede cambiar rápidamente a una instancia de otra región. Puede crear previamente un clúster o esperar a crearlo hasta que sea necesario. Tenga en cuenta las recomendaciones siguientes:

Use varias regiones. Si la región primaria tiene una región emparejada, use esta pareja. Si no es así, seleccione las regiones en función de los requisitos de residencia y latencia de los datos.
Use una carga de trabajo sin estado que pueda replicar de forma eficaz. Si debe almacenar el estado en el clúster, que no se recomienda, asegúrese de realizar copias de seguridad de los datos con frecuencia en otra región.
Integre la estrategia de recuperación, como la replicación en otra región, como parte del pipeline de DevOps para cumplir con el SLO.
Configure cada servicio de Azure mediante características que admiten la recuperación ante desastres. Por ejemplo, en esta arquitectura, Container Registry está habilitado para la replicación geográfica. Si una región falla, puede extraer imágenes de la región replicada.
Implemente la infraestructura como código, incluido el clúster de AKS y cualquier otro componente que necesite. Si necesita realizar la implementación en otra región, puede reutilizar los scripts o plantillas para crear una instancia idéntica.

Copia de seguridad del clúster

Para muchas arquitecturas, puede configurar un nuevo clúster y devolverlo al estado operativo mediante el arranque de clúster basado en GitOps, seguido de la implementación de aplicaciones. Pero si hay un estado de recurso crítico, como mapas de configuración, trabajos y secretos que no se pueden capturar en su proceso de inicialización, considere la estrategia de recuperación. Se recomienda ejecutar cargas de trabajo sin estado en Kubernetes. Si la arquitectura implica el estado basado en disco, también debe tener en cuenta la estrategia de recuperación para ese contenido.

Cuando la copia de seguridad del clúster debe formar parte de la estrategia de recuperación, debe instalar una solución que coincida con los requisitos empresariales dentro del clúster. Este agente es responsable de insertar el estado de los recursos del clúster en un destino de su elección y coordinar las instantáneas de volumen persistentes basadas en Azure Disk.

VMware Velero es un ejemplo de una solución de copia de seguridad de Kubernetes común que puede instalar y administrar directamente. O bien puede usar la extensión de copia de seguridad de AKS para proporcionar una implementación administrada de Velero. La extensión de copia de seguridad de AKS admite la copia de seguridad de recursos de Kubernetes y de volúmenes persistentes, con programaciones y ámbito de copia de seguridad externalizados como configuración del almacén en Azure Backup.

La implementación de referencia no permite implementar la copia de seguridad, lo que implica recursos adicionales de Azure para administrar, supervisar, comprar y proteger. Estos recursos pueden incluir una cuenta de Azure Storage, un almacén y una configuración de Azure Backup y la característica de acceso de confianza. En su lugar, la solución de recuperación es combinar GitOps con la intención de ejecutar cargas de trabajo sin mantenimiento de estado.

Elija y valide una solución de copia de seguridad que cumpla con el objetivo empresarial, que incluye el objetivo de punto de recuperación definido y el objetivo de tiempo de recuperación. Defina su proceso de recuperación en un runbook de equipo y póngalo en práctica para todas las cargas de trabajo críticas para la empresa.

SLA del servidor de API de Kubernetes

Puede usar AKS como servicio gratuito, pero ese nivel no proporciona un Acuerdo de Nivel de Servicio respaldado financieramente. Para obtener un Acuerdo de Nivel de Servicio, debe elegir el nivel Estándar. Se recomienda que todos los clústeres de producción usen el nivel Estándar. Reserve el nivel Gratis para los clústeres de preproducción y el nivel Premium solo para cargas de trabajo críticas . Cuando se usen zonas de disponibilidad de Azure, el acuerdo de nivel de servicio del servidor de API de Kubernetes será más elevado. Los grupos de nodos y otros recursos se recogen en los propios SLA.

Para obtener más información sobre SLA específicos para cada servicio, consulte SLA para servicios en línea.

Compromiso

Hay una compensación entre costo y disponibilidad al implementar la arquitectura entre zonas y, especialmente, entre regiones. Algunas características de replicación, como la replicación geográfica en Container Registry, están disponibles en SKU premium, lo que es más caro. En el caso de las implementaciones de varias regiones, el coste también aumentará, ya que se aplican cargos de ancho de banda cuando el tráfico se mueve entre regiones.

Además, se espera una pequeña cantidad de latencia de red adicional en la comunicación de nodos entre zonas y una latencia más significativa en la comunicación entre regiones. Mida el impacto de esta decisión arquitectónica en la carga de trabajo.

Prueba con simulaciones y conmutaciones por error forzadas

Pruebe la confiabilidad de la solución mediante pruebas de conmutación por error forzadas con interrupciones simuladas. Las simulaciones pueden incluir la detención de un nodo, la desactivación de todos los recursos de AKS en una zona determinada para simular un error zonal o la invocación de un error de dependencia externa. También puede usar Azure Chaos Studio para simular varios tipos de interrupciones en Azure y en el clúster.

Para obtener más información, consulte Chaos Studio.

Supervisión y recopilación de registros y métricas

Se recomienda que los servicios de supervisión de Kubernetes de Azure Monitor supervisen el rendimiento de las cargas de trabajo de contenedor, ya que puede ver eventos en tiempo real. Azure Monitor captura los registros de contenedores de los pods en ejecución y los organiza para que puedan ser visualizados. También recopila información de la API de métricas sobre la utilización de memoria y CPU para supervisar el mantenimiento de los recursos y cargas de trabajo en ejecución. También puede usar Azure Monitor para supervisar el rendimiento a medida que se escalan los pods. Incluye telemetría que es fundamental para la supervisión, el análisis y la visualización de los datos recopilados.

Habilitación de la recopilación de registros desde pods

El esquema de registro ContainerLogV2 está diseñado para capturar registros de contenedor de pods de Kubernetes en un enfoque optimizado. Las entradas de registro se consolidan en la tabla ContainerLogV2 de un área de trabajo de Azure Log Analytics.

En un clúster de AKS, hay dos métodos principales para configurar la recopilación de registros de pod. Ambos enfoques le permiten personalizar la configuración. Puede filtrar espacios de nombres, ajustar intervalos de recopilación, habilitar o prohibir características específicas (como ContainerLogV2 o ContainerLogV2-HighScale) y especificar qué flujos de datos se van a recopilar.

Si necesita configuraciones de supervisión centralizadas y reutilizables en varios clústeres o prefiere que la configuración del clúster se externalice en recursos nativos de Azure, use reglas de recopilación de datos (DCR). Los DCR son recursos de Azure que el plano de control de Azure Resource Manager administra de forma nativa y puede incluirlos en archivos de Bicep. La implementación de referencia utiliza los DCR.
Como alternativa, puede definir la supervisión mediante ConfigMaps, que son objetos YAML noconfidentiales de Kubernetes configurados a través del plano de control de la API de Kubernetes. El agente de Azure Monitor que se ejecuta en el clúster supervisa los objetos ConfigMap. Usa la configuración predefinida para determinar qué datos se van a recopilar.

Cuando ambos métodos están habilitados, la configuración de ConfigMap tiene prioridad sobre los DCR. Evite mezclar la configuración de ConfigMap y DCR para la recopilación de registros de contenedor, ya que puede provocar problemas de registro difíciles de solucionar.

Alertas y métricas de Prometheus

Las interrupciones y los fallos suponen riesgos importantes para las aplicaciones de trabajo, lo que hace que sea esencial identificar proactivamente los problemas relacionados con la salud y el rendimiento de la infraestructura. Al supervisar el entorno y actuar sobre lo que aprende, reduce las interrupciones y mejora la confiabilidad de la solución. Para prever posibles condiciones de error en el clúster, habilite las reglas de alertas recomendadas de Prometheus para Kubernetes.

La mayoría de las cargas de trabajo hospedadas en pods emiten métricas de Prometheus. Azure Monitor se puede integrar con Prometheus. Puede ver las métricas de aplicación y carga de trabajo recopiladas de contenedores, pods, nodos y el clúster.

Algunas soluciones que no son de Microsoft se integran con Kubernetes, como Datadog, Grafana o New Relic. Por lo tanto, si su organización ya usa estas soluciones, puede aprovecharlas.

Registros del plano de control de La infraestructura y Kubernetes de Azure

Con AKS, Azure administra algunos de los servicios principales de Kubernetes. Azure implementa los registros de los componentes del plano de control de AKS como registros de recursos. Estas opciones pueden ayudarle a solucionar problemas de clúster y tienen una densidad de registro relativamente baja. Se recomienda habilitar las siguientes opciones en la mayoría de los clústeres:

ClusterAutoscaler: Consiga visibilidad en las operaciones de escalado mediante el registro. Para más información, consulte Recuperación de registros y estado del escalador automático del clúster.
KubeControllerManager: Obtenga observabilidad sobre la interacción entre Kubernetes y el Plano de Control de Azure.
kube-audit-admin: obtenga observabilidad sobre las actividades que modifican el clúster. No es necesario habilitar tanto kube-audit como kube-audit-admin, porque kube-audit es un superconjunto que también incluye operaciones sin modificación (lectura).
guard: Capturar el ID de Microsoft Entra y las auditorías de Azure RBAC.

Puede resultar útil habilitar otras categorías de registro, como KubeScheduler o kube-audit, durante el desarrollo inicial del ciclo de vida del clúster o de la carga de trabajo. El escalado automático del clúster agregado, la ubicación y la programación de pods, y datos similares pueden ayudarle a solucionar problemas de operaciones de clúster o carga de trabajo. Pero si mantiene los registros de solución de problemas ampliados durante todo el tiempo después de que finalicen sus necesidades de solución de problemas, podría estar incurriendo en costes innecesarios para ingerir y almacenar los datos en Azure Monitor.

Azure Monitor incluye un conjunto de consultas de registro existentes para empezar, pero también puede usarlas como base para ayudar a crear sus propias consultas. A medida que crece la biblioteca, puede guardar y reutilizar consultas de registro mediante uno o varios paquetes de consultas. La biblioteca personalizada de consultas proporciona una mayor observabilidad en el estado y el rendimiento de los clústeres de AKS. Admite la consecución de los SLO.

Para más información sobre los procedimientos recomendados de supervisión de AKS, consulte Supervisión de AKS con Azure Monitor.

Métricas de red

Las métricas básicas de red de clúster están disponibles con las métricas de plataforma y de Prometheus nativas. Puede además utilizar las métricas de red de nodos de AKS para exponer estas métricas a nivel de nodo utilizando métricas de Prometheus. La mayoría de los clústeres deben incluir observabilidad de red para proporcionar funcionalidades adicionales de solución de problemas de red y detectar problemas o uso de red inesperados en el nivel de nodo.

La implementación de referencia usa Azure Monitor, que también recopila algunas métricas relacionadas con la red. La implementación de referencia prohíbe recopilar directamente algunas métricas de red de Azure Monitor y, en su lugar, recopila las métricas de observabilidad de red mediante un área de trabajo de Azure Monitor con Prometheus administrado.

En el caso de las cargas de trabajo que son muy sensibles a la pérdida de paquetes, la latencia o la presión de DNS del Protocolo de control de transmisión (TCP) o del Protocolo de datagramas de usuario (UDP), las métricas de red a nivel de pod son importantes. En AKS, puede acceder a estas métricas detalladas mediante la característica Advanced Container Networking Services . La mayoría de las cargas de trabajo no requieren esta profundidad de observabilidad de red. No debe habilitar la observabilidad de red avanzada a menos que los pods exijan una red altamente optimizada, con sensibilidad hacia abajo hasta el nivel de paquete.

Optimización de costos para el registro

La implementación de referencia configura la tabla ContainerLogV2 para usar el plan Básico como punto de partida. Microsoft Defender para contenedores y las alertas creadas para la implementación de referencia no consultan esta tabla, por lo que es probable que el plan básico sea rentable porque reduce los costos de ingesta.

A medida que evolucionan los requisitos de volumen de registro y consulta, seleccione el plan de tabla más rentable para sus necesidades. Si la solución se vuelve intensiva de lectura, donde las consultas examinan con frecuencia los datos de la tabla, el plan de Análisis predeterminado podría ser más adecuado. El plan de Analytics elimina los cargos de consulta, lo que optimiza los escenarios en los que la actividad de consulta supera los costos de ingesta. Al supervisar los patrones de uso y ajustar los planes de tabla según sea necesario, puede lograr un equilibrio entre el costo y la funcionalidad de la solución de supervisión.

Para obtener más información, consulte Selección de un plan de tabla basado en el uso de datos en un área de trabajo de Log Analytics.

Habilitación de la recuperación automática

Supervise el mantenimiento de los pods estableciendo sondeos de ejecución y preparación. Si Kubernetes detecta un pod que no responde, lo reinicia. El sondeo de ejecución determina si el pod es correcto. Si Kubernetes detecta un pod que no responde, lo reinicia. El sondeo de preparación determina si el pod está listo para recibir solicitudes y tráfico.

Note

AKS tiene una característica de reparación automática de nodos que proporciona recuperación automática integrada para los nodos de infraestructura.

Actualizaciones rutinarias para clústeres de AKS

Algunas de las operaciones del día 2 para clústeres de Kubernetes consisten en realizar actualizaciones rutinarias de plataforma y sistema operativo. Hay tres capas de actualizaciones para aplicar cada clúster de AKS:

La versión de Kubernetes (como Kubernetes 1.32.3 a 1.32.7 o Kubernetes 1.32.7 a 1.33.1), podría incluir cambios en la API de Kubernetes y desaprobaciones. Los cambios de versión en esta capa afectan a todo el clúster.
La imagen de disco duro virtual (VHD) en cada nodo, que combina las actualizaciones del sistema operativo y las actualizaciones de componentes de AKS. Estas actualizaciones se prueban en la versión de Kubernetes del clúster. Los cambios de versión en esta capa se aplican en los grupos de nodos y no afectan a la versión de Kubernetes.
El propio proceso nativo de actualización del sistema operativo, como Windows Update o apt. El proveedor del sistema operativo proporciona estas actualizaciones directamente y no se prueban en la versión de Kubernetes del clúster. Los cambios de versión en esta capa afectan a un solo nodo y no afectan a la versión de Kubernetes.

Cada una de estas capas se controla de forma independiente. Decide cómo se controla cada capa para los clústeres de la carga de trabajo. Elija la frecuencia con la que cada clúster de AKS, sus grupos de nodos o sus nodos se actualizan (la cadencia). Además, elija los días o horas para aplicar las actualizaciones ( la ventana de mantenimiento). Elija si las actualizaciones se instalan manual o automáticamente o no se instalan. Al igual que para la carga de trabajo que se ejecuta en el clúster se necesita realizar un proceso de implementación seguro, también es necesario en las actualizaciones de los clústeres.

Para tener una visión completa de las revisiones y actualizaciones, consulte Guía de revisiones y actualizaciones de AKS en la Guía de operaciones del día 2 de AKS. Use la siguiente información para las recomendaciones de línea base en relación con esta arquitectura.

Infraestructura inmutable

Las cargas de trabajo que manejan clústeres de AKS como infraestructura inmutable no actualizan sus clústeres ni de forma automática ni manual. Establezca la actualización de imágenes de nodo en none y la actualización automática del clúster en none. En esta configuración, usted es el único responsable de todas las actualizaciones en todas las capas.

Cuando haya disponible una actualización que desee, debe realizar los pasos siguientes:

Pruebe la actualización en un entorno de preproducción y evalúe su compatibilidad en un nuevo clúster.
Implemente un sello de réplica de producción que incluya la versión actualizada de AKS y los VHD del grupo de nodos.
Cuando el nuevo clúster de producción esté listo, desagüe el clúster anterior y, finalmente, lo retire.

La infraestructura inmutable con implementaciones periódicas de la nueva infraestructura es la única situación en que a un clúster de producción no se le debe aplicar una estrategia de actualizaciones locales. Todos los demás clústeres deben tener incluida una estrategia de actualizaciones locales.

Actualizaciones in situ

Las cargas de trabajo que no operan clústeres de AKS como infraestructura inmutable deben actualizar periódicamente sus clústeres en ejecución para abordar las tres capas. Adapte el proceso de actualización a los requisitos de la carga de trabajo. Use las siguientes recomendaciones como punto de partida para diseñar el proceso de actualizaciones rutinarias.

Programe la característica de mantenimiento planeado de AKS para que pueda controlar las actualizaciones en el clúster. Esta función le permite realizar estas actualizaciones, una operación intrínsecamente arriesgada, en un momento controlado para reducir los efectos de un error inesperado.
Configure los presupuestos de interrupciones de pods de forma que la aplicación permanezca estable durante las actualizaciones que vayan lanzándose. Sin embargo, no configure los presupuestos para que sean tan agresivos que impidan que se realicen actualizaciones de nodo, ya que en la mayoría de actualizaciones se necesita aplicar un proceso de acordonamiento y purga en cada nodo.
Confirme la cuota de recursos de Azure y la disponibilidad de los recursos. Las actualizaciones en contexto implementan nuevas instancias de nodos, conocidas como nodos de sobrecarga, antes de quitar los nodos antiguos. Esto significa que la cuota de Azure y el espacio de direcciones IP deben estar disponibles para los nuevos nodos. Un valor de sobrecarga de 33% es un buen punto de partida para la mayoría de las cargas de trabajo.
Pruebe la compatibilidad de herramientas de infraestructura, como las mallas de servicio o los agentes de seguridad que haya agregado al clúster. Además, pruebe los componentes de carga de trabajo, como los controladores de entrada, las mallas de servicio y los pods de carga de trabajo. Ejecutar pruebas en un entorno de preproducción.

Actualizaciones contextuales para nodos

Use el canal de actualización automática NodeImage para las actualizaciones de imágenes de sistema operativo para el nodo. Este canal configura el clúster para actualizar el disco duro virtual en cada nodo con actualizaciones a nivel de nodo. Microsoft prueba las actualizaciones en la versión de AKS. En el caso de los nodos de Windows, las actualizaciones se producen aproximadamente una vez al mes. En el caso de los nodos de Linux, las actualizaciones se producen una vez por semana.

Las actualizaciones nunca cambian la versión de AKS o Kubernetes, por lo que no hay problemas de compatibilidad con la API de Kubernetes.
Cuando se usa NodeImage como canal de actualización, respeta la ventana de mantenimiento planificado, que debe establecer durante al menos una vez por semana. Establézcalo independientemente del sistema operativo de imagen de nodo que use para ayudar a garantizar la aplicación oportuna de las actualizaciones.
Estas actualizaciones incluyen actualizaciones de seguridad, compatibilidad y funcionales para el sistema operativo, opciones de configuración del sistema operativo y actualizaciones de componentes de AKS.
Se puede llevar un control de las versiones de imagen y sus números de versión de componente incluidos mediante el seguimiento de versiones de AKS.

Si los requisitos de seguridad del clúster exigen una cadencia de implementación de parches más agresiva y el clúster puede tolerar las posibles interrupciones, use el canal de actualizaciones SecurityPatch en su lugar. Microsoft también prueba estas actualizaciones. Las actualizaciones solo se publican si hay actualizaciones de seguridad que Microsoft considera lo suficientemente importantes como para liberarlas, antes de la siguiente actualización programada de la imagen de nodo. Al usar el canal SecurityPatch, también obtendrá las actualizaciones que recibió el canal NodeImage. La SecurityPatch opción de canal sigue respetando las ventanas de mantenimiento, por lo que asegúrese de que la ventana de mantenimiento tenga intervalos más frecuentes (como diarios o cada dos días) para admitir estas actualizaciones de seguridad inesperadas.

La mayoría de clústeres que realizan actualizaciones locales deben evitar las opciones de canal de actualizaciones de imágenes None y Unmanaged.

Actualizaciones contextuales del clúster

Kubernetes es una plataforma en constante evolución y las actualizaciones periódicas incluye revisiones de seguridad importantes, así como nuevas funcionalidades. Es importante que tenga siempre todo al día con las actualizaciones de Kubernetes. Debe permanecer dentro de las dos versiones más recientes (N-2). La actualización a la versión más reciente de Kubernetes es fundamental porque se publican nuevas versiones con frecuencia.

La mayoría de clústeres deben poder realizar actualizaciones contextuales de versión de AKS con suficiente precaución y rigor. El riesgo de realizar una actualización de versión loca de AKS se puede reducir principalmente a través de las mínimas pruebas de preproducción suficientes, la validación de cuotas y la configuración del presupuesto de interrupciones de pods. Sin embargo, cualquier actualización local podría funcionar de forma inesperada. Si las actualizaciones contextuales se consideran demasiado arriesgadas para la carga de trabajo, se recomienda usar la estrategia implementación azul-verde de clústeres de AKS, en lugar de seguir las otras recomendaciones.

Se recomienda evitar usar la característica de actualización automática de clústeres al implementar por primera vez un clúster de Kubernetes. Use un método manual, que le dé el tiempo necesario para probar una nueva versión del clúster de AKS en sus entornos de preproducción antes de que las actualizaciones lleguen al entorno de producción. Esta forma de proceder también logra el mayor nivel de previsibilidad y control. Sin embargo, debe tener especial cuidado cuando supervise nuevas actualizaciones en la plataforma de Kubernetes y vaya a implantar rápidamente nuevas versiones a medida que se lanzan. Es mejor adoptar una mentalidad de "mantenerse al día" a través de un enfoque de apoyo a largo plazo .

Warning

No se recomienda aplicar parches ni actualizaciones automáticamente en un clúster de AKS en producción, incluso con actualizaciones de versiones secundarias, a menos que estas actualizaciones se hayan probado primero en los entornos inferiores. Para obtener más información, consulte Actualización regular a la versión más reciente de Kubernetes y Actualización de un clúster de AKS.

Puede recibir notificaciones cuando haya disponible una nueva versión de AKS para el clúster mediante el sistema AKS para Azure Event Grid. La implementación de referencia despliega este sistema de Event Grid para que pueda suscribirse al evento desde su solución de notificación de flujo de eventos Microsoft.ContainerService.NewKubernetesVersionAvailable. Revise las notas de la versión de AKS para conocer los problemas de compatibilidad específicos, cambios en el funcionamiento o características obsoletas.

Quizá legue finalmente a confiar totalmente al usar las versiones de Kubernetes, las versiones de AKS, el clúster, sus componentes de clúster y la carga de trabajo, para adentrarse más en la función de actualizaciones automáticas. En el caso de los sistemas de producción, es raro pasar más allá de patch. Además, cuando actualice automáticamente la versión de AKS, compruebe la configuración de la versión de AKS en la infraestructura como código (IaC) para que los dos no se desconcronicen. Configure la ventana de mantenimiento planeado para admitir la operación de actualización automática.

Supervisión de seguridad

Supervise la infraestructura de contenedores tanto de las amenazas activas como de los potenciales riesgos de la seguridad. Para obtener más información, consulte los siguientes recursos:

Microsoft Defender para contenedores identifica y corrige las recomendaciones de Defender for Cloud para las imágenes de contenedor.
Defender para contenedores examina periódicamente las imágenes de contenedor en busca de vulnerabilidades.
Defender para contenedores también genera alertas de seguridad en tiempo real para actividades sospechosas.
Conceptos de seguridad para aplicaciones y clústeres en AKS proporciona detalles acerca de cómo la seguridad de los contenedores protege todo el pipeline, desde el desarrollo hasta las cargas de trabajo de las aplicaciones que se ejecutan en AKS.

Operaciones de clúster y de carga de trabajo

Para conocer las consideraciones sobre las operaciones de clúster y carga de trabajo (DevOps), consulte el pilar de Principios de diseño de excelencia operativa.

Arranque del clúster

Después de configurar el clúster, es un clúster en funcionamiento, pero es posible que tenga más pasos para poder implementar cargas de trabajo. El proceso de preparación del clúster se denomina bootstrap. La inicialización a menudo consiste en desplegar imágenes de requisitos previos en los nodos del cluster, crear espacios de nombres y realizar otras tareas que cumplan con los requisitos del caso de uso de la organización.

Para acelerar la transición de un clúster recién configurado a uno configurado correctamente, debe definir el proceso de arranque único y preparar los recursos pertinentes de antemano. Por ejemplo, si usa una malla de servicio como Linkerd o Consul Connect, normalmente se implementa la malla antes de que se puedan programar cargas de trabajo de aplicaciones. Antes de configurar el clúster, debe validar que las imágenes de la malla de servicio existen en un registro de contenedor creado anteriormente. Esta validación ayuda a evitar retrasos o errores de implementación.

El proceso de arranque se puede configurar mediante uno de los métodos siguientes:

Extensión de clúster Flux v2 con GitOps
Pipelines
Autoconfiguración con Flux o Argo CD, por ejemplo

Note

Cualquiera de estos métodos funcionará con cualquier topología de clúster, pero se recomienda la extensión de clúster Flux v2 con GitOps para flotas debido a la uniformidad y a una gobernanza más sencilla a gran escala. Cuando se ejecutan solo unos pocos clústeres, GitOps puede ser demasiado complejo. En su lugar, puede optar por integrar el proceso en una o varias canalizaciones de implementación para asegurarse de que se produzca el arranque. Use el método que mejor se alinee con los objetivos de la organización y el equipo.

Una de las principales ventajas de usar la extensión de clúster Flux v2 con GitOps para AKS es que realmente no hay ninguna diferencia entre un clúster aprovisionado y un clúster arrancado. Configura el entorno con una base de administración sólida y también admite la inclusión de la inicialización como sus plantillas de recursos para alinearse con su estrategia de IaC.

Por último, cuando se usa la extensión de clúster de GitOps Flux v2, kubectl no es necesario para ninguna parte del proceso de arranque. Puede reservar el acceso basado en kubectl para situaciones de interrupción de emergencia. Entre las plantillas para las definiciones de recursos de Azure y el arranque de manifiestos mediante la extensión de GitOps, se pueden realizar todas las actividades de configuración normales sin necesidad de usar kubectl.

Aislamiento de las responsabilidades de la carga de trabajo

Divida la carga de trabajo por equipos y tipos de recursos para administrar cada parte de forma individual.

Comience por una carga de trabajo básica que contenga los componentes fundamentales y vaya construyendo sobre ella. Una tarea inicial es configurar las redes. Establecer redes virtuales para el "hub" y los "satélites" y las subredes dentro de esas redes. Por ejemplo, un spoke tiene subredes independientes para los grupos de nodos del sistema y de usuario, los recursos de entrada y el servidor de API privado de AKS. Implemente una subred para Azure Firewall en el centro.

Otra tarea es integrar la carga de trabajo básica con Microsoft Entra ID.

Uso de IaC

Elija un método declarativo idempotente sobre un enfoque imperativo, siempre que sea posible. En lugar de escribir una secuencia de comandos que especifiquen opciones de configuración, use la sintaxis declarativa que describe los recursos y sus propiedades. La implementación de referencia usa Bicep, pero puede elegir usar terraform o plantillas de Azure Resource Manager (plantillas de ARM) en su lugar.

Asegúrese de configurar los recursos según las directivas de gobernanza. Por ejemplo, al seleccionar los tamaños de las máquinas virtuales, no se salga de las restricciones de costes y de las opciones de zonas de disponibilidad para que se adapten a los requisitos de la aplicación. También puede usar Azure Policy para aplicar las directivas de su organización en estas decisiones.

Si necesita escribir una secuencia de comandos, use la CLI de Azure. Estos comandos cubren una variedad de servicios de Azure y se pueden automatizar mediante scripting. Windows y Linux admiten la CLI de Azure. Otra opción multiplataforma es Azure PowerShell. Su elección dependerá de sus técnicas y procedimientos preferidos.

Almacene y cree versiones de los scripts y los archivos de plantillas en el sistema de control de código fuente.

CI/CD de carga de trabajo

Las canalizaciones de flujo de trabajo e implementación deben tener la capacidad de crear e implementar aplicaciones de forma continua. Las actualizaciones se deben implementar de forma segura y rápida, y poderse revertir en caso de que haya problemas.

La estrategia de implementación debe incluir una canalización de entrega continua confiable y automatizada. Implemente los cambios en las imágenes de contenedor de carga de trabajo automáticamente en el clúster.

En esta arquitectura, Acciones de GitHub administra el flujo de trabajo y la implementación. Otras opciones populares incluyen Azure DevOps Services y Jenkins.

CI/CD del clúster

Descargue un archivo Visio de esta arquitectura.

En lugar de usar un enfoque imperativo como kubectl, use herramientas que sincronicen automáticamente los cambios de clúster y repositorio. Para administrar el flujo de trabajo, como la versión de una nueva versión y la validación en esa versión antes de realizar la implementación en producción, considere un flujo de GitOps.

Una parte esencial del flujo de CI/CD es el arranque de un clúster recién aprovisionado. Un enfoque de GitOps es útil porque permite a los operadores definir de forma declarativa el proceso de arranque como parte de la estrategia de IaC y ver la configuración reflejada en el clúster automáticamente.

Cuando use GitOps, se implementará un agente en el clúster para garantizar que el estado del clúster esté coordinado con la configuración almacenada en el repositorio de Git privado. Uno de estos agentes es Flux, que usa uno o varios operadores del clúster para desencadenar implementaciones dentro de Kubernetes. Flux realiza las siguientes tareas:

Supervisa todos los repositorios configurados
Detecta nuevos cambios de configuración
Desencadena las implementaciones
Actualiza la configuración en ejecución deseada en función de esos cambios.

También puede establecer directivas que rijan cómo se implementan esos cambios.

En el diagrama de ejemplo siguiente se muestra cómo automatizar la configuración del clúster con GitOps y Flux.

Descargue un archivo Visio de esta arquitectura.

Un desarrollador confirma los cambios en el código fuente, como los archivos YAML de configuración, que se almacenan en un repositorio de Git. Después, los cambios se insertan en un servidor de Git.
Flux se ejecuta en un pod junto con la carga de trabajo. Flux tiene acceso de solo lectura al repositorio de Git para asegurarse de que Flux solo aplica los cambios solicitados por los desarrolladores.
Flux reconoce los cambios en la configuración y los aplica mediante los comandos kubectl.
Los desarrolladores no tienen acceso directo a la API de Kubernetes a través de kubectl.

Puede tener directivas de rama en el servidor git para que varios desarrolladores puedan aprobar los cambios a través de una solicitud de incorporación de cambios antes de que el cambio se aplique a producción.

Aunque puede configurar GitOps y Flux manualmente, se recomienda la extensión de clúster gitOps con Flux v2 para AKS.

Estrategias de implementación de carga de trabajo y clúster

Implemente cualquier cambio, como componentes de la arquitectura, carga de trabajo y configuración del clúster, en al menos un clúster de AKS de preproducción. Este proceso simula el cambio y podría identificar problemas antes de implementarlos en producción.

Ejecute pruebas y validaciones en cada fase antes de continuar con la siguiente fase. Ayuda a garantizar que pueda enviar actualizaciones al entorno de producción de una manera altamente controlada y minimizar las interrupciones de problemas de implementación imprevistos. La implementación debe seguir un patrón similar al de producción, y usar la misma canalización de Acciones de GitHub u operadores de Flux.

Las técnicas avanzadas de implementación, como la implementación azul-verde, las pruebas A/B y las versiones canarias, requieren procesos adicionales y posiblemente herramientas adicionales. Flagger es una solución popular de código abierto que ayuda a resolver escenarios de implementación avanzados.

Administración de costos

Empiece por revisar la lista de comprobación de diseño de optimización de costes y la lista de recomendaciones descritas en Marco de buena arquitectura para AKS. Use la calculadora de precios de Azure para estimar los costes de los servicios usados en la arquitectura. Para ver otros procedimientos recomendados, consulte Optimización de costos.

Considere la posibilidad de usar el análisis de costes de AKS para la asignación pormenorizada de costes de infraestructura de clúster mediante construcciones específicas de Kubernetes.

Provision

Conozca de dónde proceden sus costes. No hay costes mínimos asociados a AKS en la implementación, administración y operaciones del clúster de Kubernetes. Lo que influye en el coste son las instancias de máquina virtual, el almacenamiento, los datos de registro y los recursos de red consumidos por el clúster. Considere la posibilidad de elegir máquinas virtuales más baratas para grupos de nodos de sistema. La serie Ddv5 es un tipo de máquina virtual típico para el grupo de nodos del sistema y la implementación de referencia usa la SKU de Standard_D2d_v5.
No use la misma configuración para entornos de desarrollo y pruebas y producción. Las cargas de trabajo de producción tienen requisitos adicionales para la alta disponibilidad y suelen ser más costosas. Esta configuración no es necesaria en el entorno de desarrollo y pruebas.
Para cargas de trabajo de producción, agregue un SLA de tiempo de actividad. Sin embargo, se ahorra con los clústeres diseñados para desarrollo/pruebas o cargas de trabajo experimentales en los que no es necesario garantizar la disponibilidad. Por ejemplo, el SLO podría ser suficiente. Además, si la carga de trabajo lo admite, considere la posibilidad de usar grupos de nodos de acceso puntual dedicados que ejecutan máquinas virtuales de acceso puntual.

Para cargas de trabajo que no son de producción que incluyen Azure SQL Database o Azure App Service como parte de la arquitectura de carga de trabajo de AKS, evalúe si es apto para usar suscripciones de desarrollo y pruebas de Azure y recibir descuentos de servicio.
En lugar de comenzar con un clúster sobredimensionado para satisfacer las necesidades de escalado, aprovisione un clúster con un número mínimo de nodos y permita que el escalador automático del clúster supervise y tome las decisiones de tamaño.
Establezca las peticiones y los límites de pod para permitir que Kubernetes asigne recursos de nodo con mayor densidad, de modo que utilice la capacidad completa de los nodos.
Tenga en cuenta que, al habilitar diagnósticos en el clúster, puede aumentar el coste.
Si se espera que la carga de trabajo se realice durante un período largo, puede confirmar instancias reservadas de máquina virtual de uno o tres años para reducir los costes de nodo. Para obtener más información, consulte Ahorro de costes con Azure Reserved Virtual Machine Instances.
Use etiquetas al crear grupos de nodos. Las etiquetas ayudan al crear informes personalizados para realizar un seguimiento de los costes incurridos. Puede usar etiquetas para realizar un seguimiento del total de gastos y de asignar cualquier coste a un equipo o recurso específico. Si el clúster se comparte entre equipos, cree informes de contracargo para cada consumidor para identificar los costos medidos de los servicios en la nube compartidos. Para más información, consulte Especificación de un valor taint o una etiqueta para un grupo de nodos.
Prevea costes de ancho de banda adicionales si la carga de trabajo es de varias regiones y replica datos entre regiones. Para obtener más información, consulte Precios del ancho de banda.
Cree presupuestos para permanecer dentro de las restricciones de coste identificadas por la organización. Puede crear presupuestos a través de Microsoft Cost Management. También puede crear alertas para obtener notificaciones cuando se superen umbrales específicos. Para obtener más información, consulte Creación de un presupuesto mediante una plantilla.

Monitor

Puede hacer un seguimiento de todo el clúster, así como de los costes de procesamiento, almacenamiento, ancho de banda, firewall y registros. Azure proporciona las siguientes opciones para supervisar y analizar los costos:

Supervise los costos en tiempo real o según una programación regular para que pueda tomar medidas antes del final del mes, cuando ya se calculen los costos. Supervise las tendencias mensuales a lo largo del tiempo para mantenerse dentro del presupuesto.

Para tomar decisiones basadas en los datos, identifique qué recurso (en un nivel pormenorizado) supone más costes. Tenga unos buenos conocimientos de los medidores que se usan para calcular el uso de cada recurso. Por ejemplo, mediante el análisis de métricas, puede determinar si la plataforma está sobredimensionada. Puede ver los medidores de uso en las métricas de Azure Monitor.

Optimize

Siga las recomendaciones de Azure Advisor. Explore otras formas de optimizar:

Habilite el escalador automático de clústeres para detectar y quitar nodos infrautilizados en el grupo de nodos.

Important

Realizar cambios rápidos o frecuentes en la configuración del escalador automático del clúster, como los recuentos mínimos y máximos de nodos de un grupo de nodos, para controlar los costos podría dar lugar a resultados no deseados o contraproductivos. Por ejemplo, si scale-down-unneeded-time se establece en 10 minutos y la configuración de nodo mínima y máxima se modifica cada cinco minutos en función de las características de la carga de trabajo, el número de nodos nunca se reduce. Se debe a que el cálculo del tiempo innecesario para cada nodo se restablece cuando se actualiza la configuración del escalador automático del clúster.
Elija una SKU inferior para los grupos de nodos, si la carga de trabajo lo admite.
Si la aplicación no requiere el escalado de ráfagas, considere ajustar el tamaño del clúster analizando las métricas de rendimiento a lo largo del tiempo.
Si la carga de trabajo lo permite, escale los grupos de nodos de usuario a cero nodos cuando no se espere su ejecución. Si no hay cargas de trabajo programadas para ejecutarse en el clúster, considere la posibilidad de usar la característica de inicio y detención de AKS para apagar todo el proceso, que incluye el grupo de nodos del sistema y el plano de control de AKS.

Para más información, consulte Precios de AKS.

Pasos siguientes

Arquitectura de microservicios avanzada de Azure Kubernetes Service (AKS)
Arquitectura de microservicios en AKS
Uso de Azure Firewall para ayudar a proteger un clúster de AKS
GitOps para AKS
Streaming de datos mediante AKS

Comentarios

¿Le resultó útil esta página?

Compartir vía

Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)

Configuración de red

Proceso de clúster

Administración de identidades

Protección del flujo de datos

Continuidad empresarial

Operations

Architecture

Topología de red

Red virtual de centro

Subred para hospedar Azure Firewall

Subred para hospedar una puerta de enlace

Subred para hospedar Azure Bastion

Red virtual de radios

Subred para hospedar Azure Application Gateway

Subred para hospedar los recursos de entrada

Subred para hospedar los nodos de clúster

Subred para hospedar los puntos de conexión de Azure Private Link

Subred del servidor de API de AKS

Plan de direcciones IP

Espacio de direcciones IP de red virtual

Espacio de direcciones IP de pods

Otras observaciones sobre el espacio de direcciones IP

Complementos y características en vista previa (gb)

Referencia de imágenes de contenedor

Configuración del cálculo del clúster base

Selección de un sistema operativo

Integración de Microsoft Entra ID para el clúster

Acceso de AKS a los componentes de Azure

Acceso al clúster

Asociación de RBAC de Kubernetes con Microsoft Entra ID

Uso de Azure RBAC para la autorización de Kubernetes

Cuentas locales

Integración de Microsoft Entra ID para la carga de trabajo

Selección de un modelo de red

implementación de recursos de entrada

Configuración del enrutador

Protección del flujo de red

Flujo de tráfico de entrada

Flujo de tráfico de salida

Tráfico de pod a pod

Tráfico de administración

Adición de administración de secretos

Acceso a los secretos del clúster

Almacenamiento de cargas de trabajo

Gestión de políticas

Escalabilidad de nodos y pods

Escalador automático horizontal de pods

Escalador automático de clúster

Decisiones de continuidad del negocio

Nodos de clúster

Disponibilidad del pod

Zonas de disponibilidad

Varias regiones

Recuperación ante desastres

Copia de seguridad del clúster

SLA del servidor de API de Kubernetes

Compromiso

Prueba con simulaciones y conmutaciones por error forzadas

Supervisión y recopilación de registros y métricas

Habilitación de la recopilación de registros desde pods

Alertas y métricas de Prometheus

Registros del plano de control de La infraestructura y Kubernetes de Azure

Métricas de red

Optimización de costos para el registro

Habilitación de la recuperación automática

Actualizaciones rutinarias para clústeres de AKS

Infraestructura inmutable

Actualizaciones in situ

Actualizaciones contextuales para nodos

Actualizaciones contextuales del clúster

Supervisión de seguridad

Operaciones de clúster y de carga de trabajo

Arranque del clúster

Aislamiento de las responsabilidades de la carga de trabajo

Uso de IaC

CI/CD de carga de trabajo

CI/CD del clúster

Estrategias de implementación de carga de trabajo y clúster