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

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). Usa nuestros principios de diseño y se basa en los procedimientos recomendados de arquitectura de AKS del Marco de buena arquitectura de Azure. Este artículo ayuda a guiar a 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.

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

Kubernetes es un ecosistema eficaz que se extiende más allá de las tecnologías de Azure y Microsoft. Si implementa un clúster de AKS, asumirá la responsabilidad de tomar numerosas decisiones sobre cómo se debe diseñar y operar el clúster. La ejecución de un clúster de AKS implica una combinación de componentes de código cerrado de diferentes proveedores, incluido Microsoft, así como componentes de código abierto del ecosistema de Kubernetes. El entorno cambia con frecuencia y es posible que tenga que volver a consultar las decisiones con regularidad. Al implementar Kubernetes, acepta 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. Úsela como punto de partida alternativo y configúrela en función de sus necesidades.

Configuración de red

Topología de red
Plan de direcciones IP
implementación de recursos de entrada

Cálculo del clúster

Cálculo del clúster base
Referencia de imagen de contenedor
Administración de directivas

Administración de identidades

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

Protección del flujo de datos

Protección del flujo de red
Adición de administración de secretos

Continuidad empresarial

Escalabilidad
Disponibilidad de clústeres y nodos
Disponibilidad y compatibilidad con varias regiones

Operaciones

Canalizaciones de CI/CD de carga de trabajo y clúster
Mantenimiento y métricas del clúster
Administración de costos e informes

Topología de red

Esta arquitectura usa una topología en estrella tipo hub-and-spoke. 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. Use esta topología para:

• Habilitar la administración segregada. Puede aplicar la gobernanza y cumplir el principio de privilegios mínimos. 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.

• Proporcionar topologías en estrella tipo hub-and-spoke regionales. Puede expandir las topologías de red en estrella tipo hub-and-spoke y proporcionar aislamiento de la carga de trabajo.

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

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

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.

Para obtener más información sobre los cambios de diseño de red incluidos en los contenedores de Windows en la arquitectura de referencia de línea base de AKS, consulte Contenedores de Windows en AKS.

Red virtual de centro

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

• Un Azure Firewall con directivas de firewall globales definidas por los equipos centrales de TI para aplicar la directiva de firewall en toda la organización.
• Azure Bastion para el acceso remoto a máquinas virtuales.
• Una subred de puerta de enlace para la conectividad de 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 es un marcador de posición de Azure Bastion. Puede usar Azure Bastion para acceder de forma segura a los recursos de Azure sin exponer los recursos a Internet. Esta 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

Application Gateway es un equilibrador de carga de tráfico web que opera 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

Traefik es el controlador de entrada que atenderá los recursos de entrada de Kubernetes para enrutar y distribuir el tráfico. 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 Private Link para Azure Container Registry y Azure Key Vault para que los usuarios puedan acceder a estos servicios mediante puntos de conexión privados dentro de la red virtual de radio. 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 granulares en el nivel de subred mediante grupos de seguridad de red.

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

Plan de direcciones IP

Descargue un archivo Visio de esta arquitectura.

Esta arquitectura de referencia usa varios modos de conexión de red y cada uno requiere un espacio de direcciones IP:

• La red virtual de Azure, que se usa para recursos como nodos de clúster, puntos de conexión privados y Application Gateway.
• El clúster usa la superposición de Azure CNI que asigna direcciones IP a pods en un espacio de direcciones independiente a 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 esas entidades desde el espacio de direcciones de la subred. Tenga en cuenta estos aspectos cuando prevea las direcciones IP de la red virtual de Azure.

• Actualizaciones: AKS actualiza los nodos con regularidad para que las características de seguridad de las máquinas virtuales subyacentes y otras revisiones del sistema estén al día. 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. A ese nodo temporal se le asigna una dirección IP de la subred del clúster. Asegúrese de que tiene suficiente espacio de direcciones en estas direcciones IP de nodo temporales.

  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 de todos los nodos del sistema y de usuario, así como su límite máximo de escalabilidad. Supongamos que desea escalar horizontalmente un 400 %. Necesitará 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 IP reservadas: Azure reserva algunas direcciones para usarlas. 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. Esta opción da lugar a más subredes de menor tamaño. Además, el recurso de entrada puede resultar más complejo, por lo que es posible que necesite varios controladores de entrada que requieran direcciones IP adicionales.

Espacio de direcciones IP de pods

La superposición de Azure CNI asigna direcciones IP a pods mediante un espacio de direcciones específico, 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. Sin embargo, si crea varios clústeres de AKS, puede usar de forma segura el mismo espacio de direcciones de pods en cada clúster.

A cada nodo se le asigna un espacio de direcciones /24 para sus pods, por lo que es importante asegurarse de que el espacio de direcciones de los pods es lo suficientemente grande como para permitir tantos bloques /24 como necesite según 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 en el rango del CIDR, 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 obtener más información, consulte las instrucciones sobre la planificació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 obtener información relacionada con la planificación de direcciones IP en un clúster de AKS, consulte Planificación de direcciones IP en el clúster.

Para obtener más información sobre las consideraciones de planificación de direcciones IP incluidas en los contenedores de Windows en la arquitectura de referencia de línea base de AKS, consulte Contenedores de Windows en AKS.

Complementos y características en vista previa (gb)

Kubernetes y AKS evolucionan continuamente, con ciclos de lanzamiento más rápidos que el software para entornos locales. Esta arquitectura de línea base depende de las características en vista previa de AKS y los complementos de AKS seleccionados. Esta es la diferencia principal entre las dos:

• El equipo de AKS describe las características en vista previa como enviadas y en proceso de mejora porque muchas de las características en vista previa 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.

Esta arquitectura de referencia no incluye todas las características en vista previa o 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 vista previa o complementos de AKS que es posible que desee evaluar en clústeres de preproducción. Estas características pueden mejorar la seguridad, la capacidad de administración u otros requisitos. En el caso de los complementos que no son de Microsoft, debe instalarlos y mantenerlos, incluido 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

Además de la carga de trabajo, el clúster podría contener otras imágenes, como el controlador de entrada. Algunas de esas imágenes pueden residir en registros públicos. Tenga en cuenta estos puntos al extraer las imágenes en el clúster.

• Autentique el clúster para extraer la imagen.

• Importe una imagen pública en el registro de contenedor que se alinee con el objetivo de nivel de servicio (SLO), si usa una imagen pública. De lo contrario, la imagen podría estar sujeta a problemas de disponibilidad inesperados. Si la imagen no está disponible cuando la necesita, puede causar problemas operativos. Estas son algunas de las 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 de Container Registry que se implementa.

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

En AKS, cada grupo de nodos se asigna a un conjunto de escalado de máquinas virtuales. Los nodos son máquinas virtuales 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 implementa el grupo de nodos del sistema con tres nodos DS2_v2. Ese tamaño es suficiente para satisfacer la carga esperada de los pods del sistema. El disco del sistema operativo es de 512 GB.

Estas son algunas consideraciones para el grupo de nodos de usuario:

• Elija tamaños de nodo mayores para empaquetar el número máximo de pods establecido en un nodo. Los nodos más grandes minimizan la superficie de memoria 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 obtener más información, consulte Tamaños de máquinas virtuales en Azure.

• Implemente al menos dos nodos. De este modo, la carga de trabajo tendrá 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.

• Planifique los tamaños de nodo reales de la carga de trabajo según los requisitos determinados por el equipo de diseño. Teniendo en cuenta los requisitos empresariales, esta arquitectura usa DS4_v2 para la carga de trabajo de producción. Para reducir los costes, puede reducir el tamaño a DS3_v2, que es la recomendación mínima.

• Supongamos que la carga de trabajo consume hasta el 80 % de cada nodo al planificar la capacidad del clúster. El 20 % restante está reservado para los servicios de AKS.

• Establezca el número máximo de pods por nodo en función del planeamiento de capacidad. Si está intentando 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 de los nodos y las restricciones de 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, se usa Azure Linux, que es una distribución ligera y protegida de Linux que se ha optimizado para Azure. Puede optar por usar otra distribución de Linux, como Ubuntu, si lo prefiere, o si sus requisitos no los puede cumplir Azure Linux.

AKS también admite grupos de nodos que ejecutan el sistema operativo Windows Server. Hay requisitos especiales para algunos aspectos de un clúster que ejecuta Windows. Para obtener más información sobre la arquitectura del grupo de nodos de Windows, consulte Ejecución de contenedores de Windows en AKS.

Si tiene una carga de trabajo formada por varias tecnologías, puede usar diferentes sistemas operativos en grupos de nodos diferentes. Sin embargo, si no necesita sistemas operativos diferentes para la carga de trabajo, se recomienda usar un único sistema operativo para todos los grupos de nodos de la carga de trabajo.

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

Es fundamental proteger el acceso hacia el clúster y desde él. Piense desde la perspectiva del clúster cuando efectúe las elecciones de seguridad:

• Acceso de dentro hacia 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 de fuera hacia dentro. Proporcione acceso a las 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 Azure

Hay dos maneras de administrar el acceso de AKS a Azure mediante 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 las identidades administradas para que el clúster pueda interactuar con los recursos externos de Azure mediante Microsoft Entra ID. Incluso si no usa la integración de Microsoft Entra ID de inmediato, puede incorporarlo 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 de clúster para administrar los recursos de 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. Si no usa una identidad administrada, puede almacenar esa información en forma de objeto de secreto de Kubernetes y usar imagePullSecrets para recuperar el secreto. No se recomienda este enfoque debido a las complejidades de seguridad. No solo necesita conocer previamente el secreto, sino que también necesita almacenarlo en la canalización de DevOps. Otra razón por la que no se recomienda este enfoque es la sobrecarga operativa de administrar la rotación del secreto. En su lugar, conceda acceso a AcrPull a la identidad administrada de kubelet del clúster en el registro. Este enfoque soluciona estos problemas.

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:

• Rol de colaborador de red. Administra la capacidad del clúster para controlar la red virtual de radio. Con esta asignación de rol, la identidad asignada por el sistema de clúster AKS puede funcionar con la subred dedicada para el servicio del controlador de entrada interno.

• Rol del publicador de métricas para supervisión. Administra la capacidad del clúster para enviar métricas a Azure Monitor.

• Rol AcrPull. Administra la capacidad del clúster para extraer imágenes de las instancias de Azure Container Registry especificadas.

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 permite el acceso a Kubernetes mediante el Microsoft Entra ID de dos maneras. La primera es usar Microsoft Entra ID como proveedor de identidades integrado con el sistema RBAC nativo de Kubernetes. El otro método usa Azure RBAC nativo 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:

• 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, administración, edición y visualización de clústeres. 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

En lugar de usar RBAC nativo de Kubernetes, ClusterRoleBindings y RoleBindings para la autorización con la autenticación integrada de Microsoft Entra, se recomienda usar asignaciones de roles de Azure RBAC y Azure. Este enfoque aplica comprobaciones de autorización en el clúster. Puede incluso asignar esos roles en los ámbitos de grupo de administración, suscripción o 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.

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 de forma externa al proveedor de identidades principal, lo que dificulta el control de acceso y la gobernanza de los usuarios desde un punto central. Administre siempre el acceso al clúster mediante Microsoft Entra ID y configúrelo para deshabilitar explícitamente el acceso a la cuenta local.

En esta implementación de referencia, el acceso a las cuentas de clúster locales se deshabilita 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, 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 obtener más información sobre la federación de ID de carga de trabajo de Microsoft Entra, consulte Federación de identidades de carga de trabajo.

Selección de un modelo de red

AKS admite varios modelos de red, como kubenet, CNI y la superposición de Azure CNI. Los modelos de CNI son los más avanzados y tienen un alto rendimiento. Cuando se comunica entre pods, el rendimiento de CNI es similar al de las máquinas virtuales de una red virtual. CNI también ofrece un control de seguridad mejorado porque permite usar Azure Network Policy. Se recomienda un modelo de red basado en CNI.

En el modelo de CNI no superpuesto, cada pod obtiene una dirección IP del espacio de direcciones de la 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 la superposición de Azure CNI, que solo asigna direcciones IP a través de la subred del grupo de nodos para los nodos y usa una capa de superposición altamente optimizada para las direcciones IP de pods. 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 obtener información sobre los modelos, consulte Elección de un modelo de red de Container Networking Interface para usar y Comparación de los modelos de red de kubenet y Azure Container Networking Interface.

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, administrado por AKS. 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 obtener más información sobre el cifrado TLS para el tráfico entrante, consulte Flujo de tráfico de entrada.

• El 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 puntos siguientes 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 la de realizar determinadas acciones. 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.

Para obtener más información sobre el diseño de entrada para los contenedores de Windows en AKS en la arquitectura de referencia de línea base, consulte Contenedores de Windows en AKS.

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:

• Tráfico de entrada desde el cliente a la carga de trabajo que se ejecuta en el clúster.

• Tráfico de salida desde 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.

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

2. 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, que es importante porque el firewall de aplicaciones web de Application Gateway debe inspeccionar 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 está integrada 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.

3. A medida que el tráfico se mueve de Application Gateway al servidor back-end, se cifra de nuevo con otro certificado TLS, que es un comodín de *.aks-ingress.contoso.com, mientras 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.

4. 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 un adecuado control de acceso basado en roles del plano de control y una serie de prácticas del ciclo de vida de desarrollo de software basta para cifrar con TLS hasta el controlador de entrada y protegerlo con un 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 cumplimiento y carga de trabajo determinan dónde se realizará 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 se comunique a través de Azure Firewall. O bien, puede usar su propia aplicación virtual de red similar. No se recomienda usar 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, todo el tráfico de salida del clúster se mueve a través de Firewall. Puede implementar 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 debe bloquear o permitir el tráfico de salida. Esta decisión se basa en las reglas específicas definidas en Azure Firewall o en las reglas integradas de inteligencia sobre amenazas.

Una alternativa al uso de Azure Firewall es usar la característica 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.

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 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 es que Azure Firewall necesita tener más reglas para asegurarse de que solo se permite el tráfico de una subred específica. Tenga en cuenta esas direcciones al planificar varias direcciones IP para el tráfico de salida con Azure Firewall. De lo contrario, podría llegar al agotamiento del puerto. Para obtener más información sobre cómo planificar varias direcciones IP, consulte Creación de una instancia de Azure Firewall con varias direcciones IP.

Para obtener información sobre las consideraciones de salida específicas de Windows en la arquitectura de referencia de línea base de contenedores de Windows en AKS, consulte Contenedores de Windows en AKS.

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 con prudencia; de lo contrario, podría darse una situación en la que un flujo de red crítico se bloqueara. Permita solo 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 más información, consulte las directivas de red.

Habilite la directiva de red al aprovisionar el clúster porque no se puede agregar más tarde. Hay algunas opciones para las tecnologías que implementan NetworkPolicy. Se recomienda Azure Network Policy, que requiere Azure Container Networking Interface (CNI). Para obtener más información, consulte la siguiente nota. 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 el tráfico de los recursos que quieran realizar operaciones de administración en el clúster, como las solicitudes para crear recursos o la escala del 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, use la característica de intervalos IP autorizados de AKS para permitir solo el tráfico de intervalos IP autorizados al servidor de API.

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

Para otro nivel de control, a costa de complejidad adicional, puede aprovisionar un clúster de AKS privado. Mediante el uso de un clúster privado, puede ayudar a garantizar que el tráfico entre el servidor de la API y los grupos de nodos permanezca solo en la red privada y no se exponga a la red. Para obtener más información, consulte Clústeres privados de AKS.

Adición de administración de secretos

Almacene los secretos en un almacén de claves administrado, como Key Vault. La ventaja es que un almacén de claves administrado controla 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, un firewall de Key Vault está habilitado y configurado, y se utiliza Private Link al conectar desde los recursos de Azure que necesitan acceder 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 obtener más información, consulte Acceso a Key Vault mediante RBAC.

Acceso a los secretos del clúster

Deberá usar identidades de carga de trabajo para permitir que un pod acceda a los secretos de 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 carga de trabajo

La carga de trabajo en esta arquitectura no tiene estado. Si necesita almacenar el estado, se recomienda conservarlo 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.

Administración de directivas

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 para:

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

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

• ¿Desea establecer una colección de directivas, también llamadas 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úen con el clúster. Elija directivas en función de los requisitos de su organización.

• ¿Desea auditar o denegar la acción? En el modo de auditoría, la acción está permitida, 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 de denegación, la acción se bloquea porque infringe la directiva. Tenga cuidado cuando elija este modo porque puede ser demasiado restrictivo para que la carga de trabajo funcione.

• ¿Tiene áreas en la carga de trabajo que no deben ser compatibles por diseño? Azure Policy permite indicar espacios de nombres de Kubernetes que están exentos de la aplicación de directivas. Se recomienda seguir aplicando las directivas en el modo de auditoría para estar al tanto de esas instancias.

• ¿Debe cumplir requisitos que las directivas integradas no abarcan? 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.

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

• ¿Asigna directivas de Azure a ámbitos específicos? Asegúrese de que las directivas de producción también se comprueben en el entorno de preproducción. De lo contrario, al hacer una implementación en el entorno de producción, es posible que se encuentre con restricciones adicionales imprevistas que no se tuvieron en cuenta en preproducción.

Esta implementación de referencia habilita Azure Policy cuando se crea el clúster de AKS. La iniciativa restrictiva se asigna en el modo de 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 el modo de denegación. 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.

Para obtener más información sobre las consideraciones de Azure Policy específicas de Windows, consulte el artículo Administración de directivas de contenedores de Windows en AKS.

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 a través de la CLI de Azure o Azure Portal.

Se recomienda el enfoque de escalado automático porque algunos de estos 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. Para obtener más información sobre un escenario de ajuste del rendimiento con AKS, consulte Escenario de ajuste del rendimiento: transacciones empresariales distribuidas.

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. De forma preestablecida, solo se proporciona 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.

Podría haber una condición de carrera en la que HPA compruebe antes de que se complete una operación de escalado. El resultado puede 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). Tenga en cuenta KEDA si la carga de trabajo está controlada por un origen de eventos, como la cola de mensajes, en lugar de estar enlazada a la memoria o a la CPU. 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.

Cluster Autoscaler

El escalador automático de clústeres 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 las restricciones de recursos, el escalado automático aprovisiona 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 se está ejecutando con la capacidad esperada, los pods se mueven a otro nodo y se quita el nodo no utilizado.

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.

Para obtener información sobre las consideraciones de escalado específicas de Windows incluidas en esta arquitectura de referencia de línea base, consulte el artículo Contenedores de Windows en AKS.

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 último artículo SLA 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, aprovisione 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é contaminado con CriticalAddonsOnly.

El mantenimiento regular del clúster, como las actualizaciones puntuales, es crucial para la confiabilidad. También se recomienda supervisar el mantenimiento de los pods a través de sondeos.

Disponibilidad de pods

Especificar los requisitos de recursos de pod: se recomienda especificar los requisitos de recursos de pod en las implementaciones. Después, el programador puede programar correctamente el pod. La confiabilidad se reduce considerablemente si no se pueden programar los pods.

Establecer los presupuestos de interrupciones de pods: este valor determina cuántas réplicas de una implementación pueden desactivarse durante un evento de actualización. Para más información, consulte Presupuestos de interrupciones de pods.

Configure varias réplicas en la implementación para controlar las interrupciones, como los errores de hardware. En el caso de los eventos planificados, como las actualizaciones, un presupuesto de interrupciones puede ayudar a garantizar que exista el número necesario de réplicas de pods para controlar la carga esperada de la aplicación.

Establecer cuotas de recursos en los espacios de nombres de carga de trabajo: la cuota de recursos de un espacio de nombres ayuda a garantizar que las solicitudes y los límites de pod se establecen correctamente en una implementación. Para más información, consulte Aplicación de cuotas de recursos.

Establecer solicitudes y límites de pods: las solicitudes y límites de configuración permiten a Kubernetes asignar eficazmente recursos y memoria de la CPU a los pods, así como tener una mayor densidad de contenedor 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 los valores gradualmente hasta que haya establecido un umbral que pueda provocar 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 y compatibilidad con varias regiones

Para evitar algunos tipos de interrupciones, debe usar zonas de disponibilidad si la región las admite. Los componentes del plano de control y los nodos de los grupos de nodos se pueden distribuir entre las 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:

• Infraestructura completa: elija una ubicación que admita zonas de disponibilidad. Para obtener más información, consulta las limitaciones. Para tener un SLA de tiempo de actividad, debe elegir el nivel Estándar o Premium. El SLA de tiempo de actividad es mayor cuando se usan zonas de disponibilidad.

• Clúster: solo puede definir 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 compatibilidad con varias zonas 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 obtener una ventaja de zona completa, 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, un disco administrado está disponible en la zona en la que se aprovisiona. En caso de error, el nodo podría moverse a otra zona, pero el disco administrado no se moverá con el nodo a esa zona.

Para simplificar, en esta arquitectura, AKS se implementa en una sola región con grupos de nodos que abarcan las zonas de disponibilidad uno, dos y tres. Otros recursos de la infraestructura, como Azure Firewall y Application Gateway se implementan en la misma región tambié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. Ciertas herramientas 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.

Recuperación ante desastres

Si se produce un error en la región primaria, lo ideal es crear rápidamente una nueva instancia en otra región. Estas son algunas recomendaciones:

• 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 necesita almacenar el estado en el clúster (no recomendado), asegúrese de hacer una copia 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 de la canalización de DevOps para satisfacer su SLO.

• Aprovisione cada servicio de Azure con características que admitan 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 aprovisionar un nuevo clúster y devolverlo al estado operativo a través del arranque del clúster basado en operaciones de Git, seguido de la implementación de la aplicación. Sin embargo, si hay un estado crítico de los recursos, como ConfigMaps, trabajos y secretos que no se pueden capturar en el proceso de arranque, considere la posibilidad de usar 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 deba formar parte de la estrategia de recuperación, tendrá que 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.

Velero de VMware es un ejemplo de una solución común de copia de seguridad de Kubernetes 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, las operaciones de Git y la intención de ejecutar la carga de trabajo sin estado es la solución de recuperación.

Elija y valide una solución de copia de seguridad que cumpla el objetivo empresarial, incluido el objetivo de punto de recuperación y el objetivo de tiempo de recuperación definidos. 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 ofrece un SLA con respaldo financiero. 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 solo para los clústeres de preproducción y el nivel Premium solo para cargas de trabajo indispensables. 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.

Compensación

Existe un equilibrio entre costo y disponibilidad en la implementación de la arquitectura entre zonas y, especialmente, regiones. Algunas características de replicación, como la replicación geográfica en Container Registry, están disponibles en las SKU Premium, lo que resulta 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 latencia de red adicional en la comunicación de los nodos entre zonas o 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 métricas

Se recomienda Azure Monitor Container Insights para supervisar el rendimiento de las cargas de trabajo de contenedor, ya que puede ver eventos en tiempo real. Captura los registros de contenedor de los pods en ejecución y los agrega para su visualización. 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 Container Insights 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. Container Insights identifica tendencias y le permite configurar alertas para recibir notificaciones proactivas sobre problemas críticos.

La mayoría de las cargas de trabajo hospedadas en pods emiten métricas de Prometheus. Container Insights se puede integrar con Prometheus. Puede ver las métricas de aplicación y carga de trabajo recopiladas de nodos y Kubernetes.

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.

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. Se recomienda habilitar las siguientes opciones en la mayoría de los clústeres. Las opciones pueden ayudarle a solucionar problemas de clúster y tienen una densidad de registro relativamente baja.

• ClusterAutoscaler: obtiene observabilidad en las operaciones de escalado con el registro. Para más información, consulte Recuperación de registros y estado del escalador automático del clúster.
• KubeControllerManager: obtiene observabilidad en la interacción entre Kubernetes y el plano de control de Azure.
• kube-audit-admin: obtiene observabilidad de las actividades que modifican el clúster. No hay ninguna razón para tener kube-audit y kube-audit-admin habilitados. kube-audit es un superconjunto de kube-audit-admin que incluye también operaciones nomodify (lectura).
• guard: captura Microsoft Entra ID y las auditorías de RBAC de Azure.

Puede resultar útil habilitar otras categorías de registro, como KubeScheduler o kube-audit, durante el desarrollo inicial del clúster o del ciclo de vida 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.

Aunque Azure Monitor incluye un conjunto de consultas de registro existentes con las que empezar, 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 más observabilidad sobre el estado y el rendimiento de los clústeres de AKS. Admite la consecución de los SLO.

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

Para obtener más información sobre las consideraciones de supervisión específicas de Windows, consulte Contenedores de Windows en AKS.

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. El complemento Observabilidad de red se puede usar también para exponer las métricas de red para el nodo. La mayoría de clústeres deben usar el complemento Observabilidad de red para incluir funcionalidades adicionales de resolución de problemas de red y detectar problemas u operaciones de red inesperadas en el ámbito de los nodos.

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 encontrar ese nivel de detalle con la característica Observabilidad de red avanzada. La mayoría de las cargas de trabajo no requieren esta profundidad de observabilidad de red. No debe instalar el complemento Observabilidad de red avanzada a menos que sus pods exijan una red muy optimizada, con sensibilidad hasta el nivel de paquete.

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.

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 (por ejemplo, de Kubernetes 1.30.3 a 1.30.7 o de Kubernetes 1.30.7 a 1.31.1), que puede incluir cambios y retiradas de servicios de la API de Kubernetes. 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.
• Proceso de actualización nativa 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 u 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 deseada, debe probar la actualización en un entorno de preproducción y evaluar su compatibilidad en un nuevo clúster. Después, se implementa un sello de réplica de producción que incluye la versión actualizada de AKS y los VHD del grupo de nodos. Cuando el nuevo clúster de producción esté listo, el clúster anterior se purga y, finalmente, se retira.

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 locales

Las cargas de trabajo que no manejan clústeres de AKS como infraestructura inmutable deben actualizar periódicamente sus clústeres que se estén ejecutando, cubriendo 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 función de mantenimiento planificado de AKS para controlar las actualizaciones del 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 contextuales implementan nuevas instancias de nodos, conocidos 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 del 33 % es un buen punto de partida para la mayoría de cargas de trabajo.
• Pruebe la compatibilidad con herramientas, como mallas de servicio o agentes de seguridad que agregó al clúster. Y pruebe los componentes de carga de trabajo, como controladores de entrada, mallas de servicio y pods de carga de trabajo. Realice 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, estas actualizaciones se realizan aproximadamente una vez a la 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ézcala independientemente del sistema operativo de imagen de nodo que use para ayudar a garantizar la aplicación oportuna.
• 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 publicarse antes de la siguiente actualización de la imagen de nodo programada. Al usar el canal SecurityPatch, también obtendrá las actualizaciones que recibió el canal NodeImage. La opción de canal SecurityPatch sigue respetando los períodos de mantenimiento, por lo que debe asegurarse de que este período de mantenimiento tenga márgenes más frecuentes (cada día o en días alternos) 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 usar alguna de las dos versiones más recientes o 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 tener una mentalidad de "estar al día" aplicando un enfoque de compatibilidad a largo plazo.

Puede recibir notificaciones cuando haya disponible una nueva versión de AKS para el clúster; para ello consulte el tema del sistema de AKS para Azure Event Grid. La implementación de referencia implementa este tema del sistema de Event Grid para que pueda suscribirse al evento Microsoft.ContainerService.NewKubernetesVersionAvailable a través de la solución de notificaciones de secuencia de eventos. 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, sería poco frecuente plantearse algo más que patch. Además, con la actualización automática de la versión de AKS, compruebe también la versión de AKS de la infraestructura como código (IaC) del clúster para que no se desincronice. Configure la ventana de mantenimiento planificado para admitir la operación de actualización automática.

Supervisión de la seguridad

Supervise la infraestructura de contenedores tanto de las amenazas activas como de los potenciales riesgos de la seguridad. Estos son algunos recursos:

• Microsoft Defender para contenedores para identificar y corregir 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.
• Los conceptos de seguridad de AKS para aplicaciones y clústeres detallan la información sobre cómo la seguridad del contenedor protege toda la canalización de un extremo a otro de la compilación a las cargas de trabajo de la aplicación 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 realizar el aprovisionamiento, tiene un clúster de trabajo, pero es posible que aún tenga que realizar algunos pasos necesarios antes de poder implementar cargas de trabajo. El proceso de preparación del clúster se denomina arranque. El arranque puede constar de implementar imágenes de requisitos previos en nodos de clúster, crear espacios de nombres y realizar otras tareas que cumplan los requisitos del caso de uso de la organización.

Para reducir la brecha entre un clúster aprovisionado y uno configurado correctamente, los operadores de clústeres deben pensar en cómo es su proceso de arranque único. Deben preparar los activos pertinentes con antelación. Por ejemplo, si es importante tener Kured ejecutándose en cada nodo antes de implementar las cargas de trabajo de la aplicación, el operador del clúster debe verificar que ya exista una instancia de Container Registry que contenga la imagen Kured de destino antes de aprovisionar el clúster.

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

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 en el futuro y también admite la inclusión de ese arranque como plantillas de recursos para alinearse con la estrategia de IaC.

Por último, al usar la extensión, 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. Aprovisione las redes virtuales para el centro y los radios, y las subredes dentro de esas redes. Por ejemplo, un radio tiene subredes independientes para los grupos de nodos de usuario y del sistema, y los recursos de entrada. 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. Puede usar Bicep, plantillas de Azure Resource Manager (plantillas de ARM) o Terraform.

Asegúrese de que aprovisiona los recursos según las directivas de control. 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 tiene que 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. CLI de Azure para la compatibilidad con Windows y Linux 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.

Carga de trabajo de CI/CD

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, las Acciones de GitHub administran el flujo de trabajo y la implementación. Otras opciones populares son Azure DevOps y Jenkins.

Clúster de CI/CD

Descargue un archivo Visio de esta arquitectura.

En lugar de usar un enfoque imperativo como kubectl, use herramientas que sincronicen automáticamente los cambios del clúster y del repositorio. Para administrar el flujo de trabajo, como el lanzamiento de una nueva versión y la validación de esa versión antes de la implementación en producción, tome en consideración 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. Un agente de este tipo es Flux, que usa uno o varios operadores del clúster para desencadenar implementaciones dentro de Kubernetes. Flux realiza estas tareas:

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

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

Este es un ejemplo que muestra cómo automatizar la configuración del clúster con GitOps y Flux:

Descargue un archivo Visio de esta arquitectura.

1. Un desarrollador confirma los cambios en el código fuente, como los archivos de configuración YAML, que se almacenan en un repositorio de Git. Después, los cambios se insertan en un servidor de Git.

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

3. Flux reconoce los cambios en la configuración y los aplica mediante los comandos kubectl.

4. 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 GitOps y Flux se pueden configurar manualmente, se recomienda la extensión de clúster de GitOps con Flux v2 para AKS.

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

Implemente cualquier cambio, como componentes de arquitectura, carga de trabajo y configuración de clúster, en al menos un clúster AKS de preproducción. Al hacerlo, se simulará el cambio y es posible que se detecten problemas antes de que se implementen en producción.

Ejecute pruebas y validaciones en cada etapa antes de pasar a la siguiente. 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 de implementación avanzada, como la implementación azul-verde, pruebas A/B y versiones de valores controlados, requieren procesos y herramientas adicionales. Flagger es una conocida solución de código abierto que le ayudará a resolver sus escenarios de implementación avanzada.

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 conocer otros procedimientos recomendados, consulte Optimización de costes.

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.

Para obtener información sobre las consideraciones de administración de costes específicas de Windows, consulte Contenedores de Windows en AKS.

Aprovisionamiento

• 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 DS2_v2 es un tipo de máquina virtual típico para el grupo de nodos del sistema.

• No tenga la misma configuración para los entornos de desarrollo/pruebas y los de 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 es suficiente. Además, si la carga de trabajo lo admite, considere la posibilidad de usar grupos de nodos de acceso puntual dedicados que ejecuten VM de acceso puntual.

  En el caso de cargas de trabajo que no son de producción que incluyen Azure SQL Database o Azure App Service como parte de la arquitectura de la carga de trabajo de AKS, evalúe si puede usar suscripciones de desarrollo/pruebas de Azure para 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 solicitudes y los límites de pod para permitir que Kubernetes asigne recursos de nodo con mayor densidad, de modo que se utilice la capacidad del hardware.

• 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. Además, si el clúster se comparte entre equipos, cree informes de devolución por consumidor para identificar los costos medidos de 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 recibir notificaciones cuando se superen determinados umbrales. Para más información, consulte Creación de un presupuesto con 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 opciones para supervisar y analizar los costes:

• Azure Advisor

• Microsoft Cost Management

Lo ideal es supervisar los costes en tiempo real o al menos con una cadencia regular. Después, puede tomar medidas antes del final del mes cuando ya se calculen los costes. Supervise también 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.

Optimización

Actúe según las recomendaciones proporcionadas por Azure Advisor. Existen otras formas de optimización:

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

  Importante

  Cambiar agresivamente la configuración del escalador automático del clúster, como la configuración mínima/máxima de nodos para un grupo de nodos, por razones de coste podría tener resultados contraproducentes. Por ejemplo, si scale-down-unneeded-time se establece en 10 minutos y la configuración de nodo mínimo/máximo se modifica cada cinco minutos en función de las características de la carga de trabajo, el número de nodos nunca bajará. Esto se debe a que el cálculo del tiempo innecesario para cada nodo se restablecerá debido a la actualización de 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 la posibilidad de dimensionar el clúster con el tamaño correcto mediante el análisis de las métricas de rendimiento a lo largo del tiempo.

• Si la carga de trabajo lo admite, escale los grupos de nodos de usuario a 0 nodos cuando no se espera que se ejecuten. Además, si no hay cargas de trabajo programadas para ejecutarse en el clúster, considere la posibilidad de usar la característica para iniciar y detener AKS para cerrar todo tipo de proceso, lo que incluye el grupo de nodos del sistema y el plano de control de AKS.

Para obtener más información relacionada con los costos, consulte Precios de AKS.

Pasos siguientes

• Arquitectura de microservicios avanzada de Azure Kubernetes Service (AKS)
• Línea base de AKS para clústeres de varias regiones
• Clúster regulado de AKS para PCI-DSS 3.2.1
• Contenedores de Windows en la arquitectura de referencia de línea base de AKS

Recursos relacionados

• Hoja de ruta de AKS en GitHub
• Introducción a Kubernetes
• Desarrollo e implementación de aplicaciones en Kubernetes
• Revisión del marco de buena arquitectura para AKS
• Acelerador de zona de aterrizaje de AKS
• Guía de operaciones del día 2 de AKS
• Arquitectura de microservicios en AKS
• Uso de Azure Firewall para ayudar a proteger un clúster de AKS
• Operaciones de Git para AKS
• Streaming de datos con AKS