Ejecución de contenedores Windows en AKS

En este artículo se pretende ampliar la Arquitectura de línea de base de AKS, que proporciona una revisión exhaustiva de las configuraciones recomendadas para implementar un clúster AKS en un entorno de producción. En este artículo, el objetivo es proporcionar guía sobre la implementación de contenedores de Windows en AKS. Por lo tanto, este artículo se centra en las configuraciones específicas para la implementación de Windows en el AKS y debe consultar la documentación de la línea de base del AKS para las configuraciones que ya se describen allí.

Consulte el proyecto Proyecto GitHub de línea de base AKS Windows para revisar la implementación de referencia asociada con esta arquitectura de referencia, incluido el código de implementación de ejemplo.

Diseño de red

El diseño de red utilizado en esta arquitectura se basa en el diseño utilizado en la arquitectura de línea de base de AKS y, por lo tanto, comparte todos los componentes principales con ese diseño, excepto por los siguientes cambios.

• Se agregaron controladores de dominio de Active Directory para dar soporte a las cargas de trabajo basadas en Windows.
• La solución de entrada en esta arquitectura utiliza Azure Front Door (AFD) y Microsoft Entra Application Proxy en lugar de Azure App Gateway, que se utiliza en la arquitectura de línea de base AKS.

Diseño de la entrada

Componentes:

• Azure Front Door con WAF: AFD es el punto de entrada público para las aplicaciones hospedadas en el clúster AKS. AFD Premium se usa en este diseño porque permite el uso de Enlace privado, que bloquea el tráfico interno de las aplicaciones en redes privadas, lo que proporciona el máximo nivel de seguridad. Web Application Firewall (WAF) protege contra vulnerabilidades y vulnerabilidad de seguridad comunes de aplicaciones web.
• Microsoft Entra Application Proxy: este componente sirve como segundo punto de entrada ante el equilibrador de carga interno administrado por AKS. Tiene Microsoft Entra ID habilitado para la autenticación previa de usuarios y utiliza una directiva de acceso condicional para evitar que rangos de IP no autorizados (el proxy de aplicación ve la IP de origen del cliente, que compara con la directiva de acceso condicional) y usuarios accedan al sitio. Esta es la única manera de enrutar las solicitudes de autenticación Kerberos mientras se usa un servicio de Azure que admite WAF. Para obtener una descripción detallada de cómo proporcionar acceso de inicio de sesión único a Application Proxy aplicaciones protegidas, consulte Delegación restringida de Kerberos para el inicio de sesión único (SSO) en las aplicaciones con Application Proxy
• Equilibrador de carga interno: administrado por AKS. Este equilibrador de carga expone el controlador de entrada a través de una dirección IP estática privada. Sirve como único punto de contacto que recibe las solicitudes HTTP entrantes.
• En esta arquitectura no se utilizan controladores de entrada en el clúster (como Nginx).

Para implementar este diseño, AFD debe configurarse para utilizar la URL del proxy de aplicación que se crea cuando la aplicación se publica en ese servicio. Esta configuración enruta el tráfico entrante al proxy y permite la autenticación previa.

Topología de red

El siguiente diagrama muestra el diseño de red hub-spoke utilizado en esta arquitectura.

Descargue un archivo Visio de esta arquitectura.

Topología de grupos de nodos

Esta arquitectura utiliza tres grupos de nodos: un grupo de nodos de sistema que ejecuta Linux, un grupo de nodos de usuario que ejecuta Linux y un grupo de nodos de usuario que ejecuta Windows. Los grupos de nodos de usuario Windows y Linux se utilizan para las cargas de trabajo, mientras que el grupo de nodos del sistema se utiliza para todas las configuraciones a nivel de sistema, como CoreDNS.

Flujo de tráfico de entrada

1. El cliente envía una solicitud HTTPS al nombre de dominio: bicycle.contoso.com. Ese nombre está asociado al registro DNS A de la dirección IP pública de Azure Front Door. Este tráfico se cifra para asegurarse de que no se puede inspeccionar o cambiar el tráfico entre el explorador cliente y la puerta de enlace.
2. Azure Front Door cuenta con un firewall de aplicaciones web (WAF) integrado, negocia el protocolo de enlace TLS para bicycle.contoso.com y solo permite cifrados seguros. Azure Front Door Gateway es un punto de terminación TLS, ya que es necesario para procesar las reglas de inspección del WAF y ejecutar las reglas de enrutamiento que reenvían el tráfico al backend configurado. El certificado TLS se almacena en Azure Key Vault.
3. AFD enruta la petición del usuario al Azure Application Proxy. AFD está configurado para permitir únicamente tráfico HTTPS. El usuario debe autenticarse con Microsoft Entra ID si la autenticación previa está habilitada.
4. El proxy de aplicaciones enruta al usuario al contenedor de aplicaciones backend a través del equilibrador de carga AKS.

Flujo de tráfico de salida

Todas las guías que se encuentran en el artículo de la línea de base de AKS se aplican aquí con una recomendación adicional para las cargas de trabajo de Windows: para aprovechar las actualizaciones automáticas de Windows Server, no debe bloquear los Nombres de dominio requeridos en su conjunto de reglas de Azure Firewall.

Planeación de direcciones IP

A diferencia de los clústeres AKS con grupos de nodos Linux, los clústeres AKS con grupos de nodos Windows requieren Azure CNI. El uso de Azure CNI permite asignar a un pod una dirección IP de una red virtual Azure. El pod puede entonces comunicarse a través de la Red Virtual Azure como cualquier otro dispositivo. Puede conectarse a otros pods, a redes emparejadas o a redes locales mediante ExpressRoute o una VPN, o bien a otros servicios de Azure mediante Private Link.

Toda la guía relativa a la planificación de las direcciones IP proporcionada en el artículo sobre la arquitectura de línea de base AKS se aplica aquí, con una recomendación adicional: considere el aprovisionamiento de una subred dedicada para sus controladores de dominio. Con respecto al grupo de nodos Windows, se recomienda separarlo de los demás grupos de nodos mediante subredes independientes.

Actualización de grupos de nodos

El proceso de actualización de los nodos Windows no ha cambiado con respecto a la guía proporcionada en la documentación de actualización de imágenes de nodos Azure Kubernetes Service (AKS), pero debe tener en cuenta las siguientes diferencias de programación para planificar su cadencia de actualización.

Microsoft proporciona nuevas imágenes de Windows Server, incluidos parches actualizados, para los nodos mensualmente y no realiza ninguna actualización o aplicación de parches automática. Por lo tanto, debe actualizar sus nodos manualmente o mediante programación de acuerdo con este calendario. El uso de Acciones de GitHub para crear una tarea cron que se ejecute según un calendario le permite programar actualizaciones mensuales. La guía proporcionada en la documentación enlazada anteriormente refleja los procesos de los nodos Linux, pero puede actualizar el archivo YAML para configurar su cron para que se ejecute mensualmente en lugar de quincenalmente. También deberá cambiar el parámetro "runs-on" del archivo YAML a "windows-latest" para asegurarse de que está actualizando a la imagen más reciente de Windows Server.

Consulte la guía del operador de AKS sobre parcheado y actualización de nodos de trabajo para más información.

Consideraciones de proceso

Los tamaños de imagen más grandes asociados a las imágenes basadas en servidores Windows requieren la implementación de discos de sistema operativo del tamaño adecuado en su agrupación de nodos. Se sigue recomendando el uso de discos de SO efímeros para todos los nodos, incluido Windows, así que asegúrese de comprender los requisitos de tamaño que debe cumplir al planificar la implementación.

Administración de identidades

Los contenedores Windows no pueden unirse a un dominio, por lo que si necesita autenticación y autorización de Active Directory, puede utilizar Cuentas de servicio administradas por grupo (gMSA). Para utilizar gMSA, debe habilitar el perfil gMSA en su clúster AKS que ejecuta nodos Windows. Consulte la documentación gMSA AKS para obtener una revisión completa de la arquitectura y una guía sobre cómo habilitar el perfil.

Escalado de nodos y pods

La guía de escalabilidad automática del clúster no cambia para los contenedores Windows. Consulte la documentación de escalabilidad automática de clúster para obtener más información.

La documentación del clúster de línea de base describe los enfoques de escalado manual y automático disponibles para el escalado de pods. Ambos enfoques están disponibles para los clústeres que ejecutan contenedores Windows y la guía proporcionada en ese artículo generalmente se aplica aquí también.

Lo que difiere entre los contenedores Linux y Windows con respecto a las operaciones de escalado de pods es el tamaño de la imagen en la mayoría de los casos. Los mayores tamaños de imagen de los contenedores Windows probablemente aumentarán la cantidad de tiempo para que las operaciones de escalado se completen y, por lo tanto, se deben tomar algunas consideraciones sobre el enfoque de escalado. Este escenario es común con aplicaciones .NET heredadas debido al tamaño del tiempo de ejecución .NET. Para mitigar los retrasos en la bajada de la imagen durante los tiempos de escalado, puede utilizar un DaemonSet para bajar la imagen desde ACR a la caché en cada nodo Windows y, por tanto, arrancar los pods con la imagen precargada. A partir de ese momento, los pods solo tendrían que ejecutar los procesos de configuración de aplicaciones definidos para su carga de trabajo antes de ponerse en línea.

Se deben realizar ejercicios de evaluación comparativa para comprender el impacto en el tiempo de la realización de operaciones de escalado, y estos datos deben sopesarse con los requisitos empresariales. Si la carga de trabajo necesita escalarse más rápido de lo que es posible mediante el escalado automático, se recomienda considerar la siguiente solución alternativa de "reserva activa":

En primer lugar, tendrá que llevar a cabo pruebas de referencia para identificar cuántos pods necesitará ejecutar en momentos de carga máxima y en momentos de carga mínima. Una vez establecida esta línea de base, puede planificar el recuento de nodos para tener en cuenta el número total de nodos que necesitará tener disponibles en un momento dado. Esta solución consiste en escalar manualmente el clúster y ajustar el número inicial de nodos al número de nodos necesarios fuera de horas pico. Cuando se acerque un periodo de pico, tendrá que escalar preventivamente al número de nodos de pico. A medida que pase el tiempo, tendrá que restablecer su línea de base con regularidad para tener en cuenta los cambios en el uso de aplicaciones u otros requisitos empresariales.

Supervisión

Los contenedores que ejecutan Windows pueden supervisarse con Azure Monitor y Container Insights, al igual que los contenedores Linux. Como tal, la guía encontrada en el artículo de la línea de base AKS se aplica aquí también en su mayor parte. Sin embargo, la supervisión de Container Insights para un clúster de Windows Server tiene las siguientes limitaciones:

• Windows no tiene una métrica RSS de memoria. Por lo tanto, no está disponible para los nodos y contenedores de Windows. La métrica de espacio de trabajo está disponible
• La información sobre la capacidad de almacenamiento del disco no está disponible para los nodos de Windows.

También puede complementar Container Insights mediante el uso de reglas de recopilación de datos para recopilar eventos y contadores de rendimiento de sus sistemas Windows Server.

Administración de directivas

Todas las políticas orientaciones que se encuentran en el artículo de referencia de AKS se aplican a las cargas de trabajo de Windows. Las directivas adicionales específicas de Windows que se encuentran en las definiciones integradas de Azure Policy para Azure Kubernetes Service artículo de referencia que se deben tener en cuenta son:

• Los contenedores Windows del clúster Kubernetes no deben sobrecomprometer CPU y memoria
• Los contenedores de Windows del clúster de Kubernetes no deben ejecutarse como ContainerAdministrator
• Los contenedores de Windows del clúster de Kubernetes solo deben ejecutarse con un grupo de usuarios de dominio y usuario aprobado

Arranque del clúster

Al igual que con la guía de arranque del clúster proporcionada en el artículo de la línea de base de AKS, los operadores de clúster también deben considerar su enfoque de arranque para las cargas de trabajo basadas en Windows. En este caso también se aplican las mismas directrices que en el artículo sobre la línea de base del AKS.

Administración de costes

Toda la guía de optimización de costos que se encuentra en el artículo de la línea de base del AKS se aplica a las cargas de trabajo de Windows. Otras consideraciones de costos que deben tenerse en cuenta son:

• Los costos de licencia para Windows Server aumentan el costo de los nodos para su clúster AKS. Las recomendaciones de optimización de costos para este factor incluyen la reserva de capacidad o el uso de licencias existentes si ya las tiene para otros usos empresariales.
  • Consulte la documentación Ventaja híbrida de Azure para Windows Server(AHUB) para obtener información sobre los descuentos para sus licencias de Windows Server aplicables de Software Assurance (SA).
  • Consulte las Preguntas frecuentes sobre contenedores de Windows Server para obtener instrucciones sobre cómo aplicar la ventaja a clústeres nuevos y existentes.
• El tamaño de las imágenes de contenedores de Windows puede incurrir en costes adicionales de Azure Container Registry (ACR) debido a la cantidad de almacenamiento necesario para varias imágenes, el número de nodos simultáneos que se extraen del ACR y los requisitos de replicación geográfica.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Isabelle Bersano | Arquitecta de soluciones en la nube
• Akshay Nimbalkar | Arquitecto principal de soluciones en la nube
• Clayton Siemens | Desarrollador principal de contenidos

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Más información sobre Contenedores de Windows

Recursos relacionados

• Aprenda a implementar grupos de nodos Windows en un clúster AKS