Uso de Azure Firewall para ayudar a proteger un clúster de Azure Kubernetes Service (AKS)

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

En esta guía se explica cómo crear un clúster de AKS privado en una topología de red en estrella tipo hub-and-spoke mediante Terraform y Azure DevOps. Azure Firewall se usa para inspeccionar el tráfico hacia y desde el clúster de Azure Kubernetes Service (AKS). El clúster está hospedado en una o varias redes virtuales de radio (spoke) emparejadas con la red virtual de centro (hub).

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

Los módulos de Terraform se usan para implementar una nueva red virtual con cuatro subredes que hospedan:

El clúster de AKS (AksSubnet).
Una máquina virtual de Jumpbox y puntos de conexión privados (VmSubnet).
Application Gateway WAF2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

El clúster de AKS usa una identidad administrada definida por el usuario para crear recursos adicionales, como equilibradores de carga y discos administrados, en Azure. Los módulos de Terraform permiten implementar opcionalmente un clúster de AKS con estas características:

El clúster de AKS se compone de los siguientes grupos:

Un grupo de nodos del sistema que hospeda solo pods y servicios críticos del sistema
Un grupo de nodos de usuario que hospeda cargas de trabajo y artefactos de usuario

Una máquina virtual se implementa en la red virtual que hospeda el clúster de AKS. Al implementar AKS como un clúster privado, los administradores del sistema pueden usar esta máquina virtual para administrar el clúster por medio de la herramienta de línea de comandos de Kubernetes. Los registros de diagnósticos de arranque de la máquina virtual se almacenan en una cuenta de Azure Storage.

Un host de Azure Bastion proporciona conectividad SSH de seguridad mejorada a la máquina virtual de Jumpbox a través de SSL. Se usa Azure Container Registry para compilar, almacenar y administrar artefactos e imágenes de contenedor (como gráficos de Helm).

La arquitectura incluye Azure Firewall que se usa para controlar el tráfico entrante y saliente mediante reglas DNAT, reglas de red y reglas de aplicación. También ayuda a proteger cargas de trabajo mediante filtrado basado en inteligencia sobre amenazas. Azure Firewall y Bastion se implementan en una red virtual de centro emparejada con la red virtual que hospeda el clúster de AKS privado. Se usan una tabla de rutas y rutas definidas por el usuario para enrutar el tráfico saliente desde el clúster de AKS privado a Azure Firewall.

Nota

Se recomienda encarecidamente usar la SKU prémium de Azure Firewall, ya que proporciona protección contra amenazas avanzada.

Las cargas de trabajo que se ejecutan en AKS utilizan un Key Vault como almacén de secretos para recuperar claves, certificados y secretos a través de Microsoft Entra Workload ID, Secrets Store CSI Driver o Dapr. Azure Private Link permite que las cargas de trabajo de AKS accedan a los servicios de PaaS de Azure, como Azure Key Vault, a través de un punto de conexión privado de la red virtual.

La topología incluye puntos de conexión privados y zonas DNS privadas para estos servicios:

Cuenta de Azure Blob Storage
Container Registry
Key Vault
El servidor de API del clúster de Kubernetes

Hay un vínculo de red virtual entre las redes virtuales en estrella tipo hub-and-spoke que hospedan el clúster de AKS y las zonas DNS privadas descritas anteriormente.

Se usa un área de trabajo de Log Analytics para recopilar los registros de diagnóstico y las métricas de los servicios de Azure.

Componentes

Azure Firewall es un servicio de seguridad de firewall de red inteligente nativo de nube que proporciona protección contra amenazas para cargas de trabajo en la nube que se ejecutan en Azure. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Asimismo, proporciona la opción de realizar la inspección del tráfico de este a oeste y de norte a sur.
Azure Container Registry es un servicio de Docker Registry privado administrado que se basa en Docker Registry 2.0 de código abierto. Puede usar registros de contenedor de Azure con las canalizaciones de desarrollo e implementación de contenedores existentes, o bien usar Container Registry Tasks para compilar imágenes de contenedor en Azure.
Azure Kubernetes Service simplifica la implementación de clústeres de Kubernetes administrados en Azure al descargar la sobrecarga operativa en Azure. Al ser un servicio de Kubernetes hospedado, Azure controla tareas críticas como la supervisión del estado y el mantenimiento. Puesto que Azure administra los maestros de Kubernetes, el usuario solo administra y mantiene los nodos de agente.
Key Vault almacena y controla el acceso a secretos como claves de API, contraseñas, certificados y claves criptográficas con seguridad mejorada. Key Vault también permite aprovisionar, administrar e implementar fácilmente certificados públicos y privados de Seguridad de la capa de transporte y Capa de sockets seguros (TLS/SSL) para su uso con Azure y los recursos internos conectados.
Azure Bastion es una plataforma totalmente administrada como servicio (PaaS) que se aprovisiona en las redes virtuales. Azure Bastion proporciona conectividad de Protocolo de escritorio remoto (RDP) y Secure Shell (SSH) con seguridad mejorada a las máquinas virtuales de la red virtual directamente desde Azure Portal a través de TLS.
Azure Virtual Machines proporciona recursos informáticos escalables a petición que ofrecen la flexibilidad de la virtualización.
Azure Virtual Network es el bloque de creación fundamental para las redes privadas de Azure. Virtual Network permite que los recursos de Azure (como máquinas virtuales) se comuniquen entre ellos, con Internet y con redes locales con seguridad mejorada. Una instancia de Azure Virtual Network se parece a una red tradicional local, pero incluye las ventajas de la infraestructura de Azure, como la escalabilidad, la disponibilidad y el aislamiento.
Las interfaces de Virtual Network permiten que las máquinas virtuales de Azure se comuniquen con Internet, Azure y recursos locales. Puede agregar varias tarjetas de interfaz de red a una VM de Azure, de modo que las VM secundarias puedan tener sus propios dispositivos de interfaz de red y direcciones IP dedicados.
Los discos administrados de Azure proporcionan volúmenes de almacenamiento de nivel de bloque que Azure administra en máquinas virtuales de Azure. Hay disponibles discos Ultra, unidades de estado sólido (SSD) prémium, SSD estándar y unidades de disco duro estándar (HDD).
Blob Storage es una solución de almacenamiento de objetos para la nube. Blob Storage está optimizado para el almacenamiento de cantidades masivas de datos no estructurados.
Private Link permite acceder a servicios de PaaS de Azure (por ejemplo, Blob Storage y Key Vault) a través de un punto de conexión privado de la red virtual. También puede usarlo para acceder a servicios hospedados en Azure que posee o que proporciona un asociado de Microsoft.

Alternativas

Puede usar un firewall de terceros de Azure Marketplace en lugar de Azure Firewall. Si lo hace, es responsabilidad suya configurar correctamente el firewall para inspeccionar y permitir o denegar el tráfico entrante y saliente desde el clúster de AKS.

Detalles del escenario

En un entorno de producción, las comunicaciones con un clúster de Kubernetes deben protegerse mediante un firewall que supervise y controle el tráfico de red entrante y saliente en función de un conjunto de reglas de seguridad. Normalmente, un firewall establece una barrera entre una red de confianza y una red que no es de confianza, como Internet.

Puede crear un clúster de AKS en una topología de red en estrella tipo hub-and-spoke mediante Terraform y Azure DevOps. Azure Firewall se usa para inspeccionar el tráfico hacia y desde el clúster de Azure Kubernetes Service (AKS). El clúster está hospedado en una o varias redes virtuales de radio (spoke) emparejadas con la red virtual de centro (hub).

Azure Firewall admite tres SKU diferentes para satisfacer una amplia gama de casos de uso y preferencias del cliente:

Se recomienda Azure Firewall Premium para proteger aplicaciones altamente confidenciales, como el procesamiento de pagos. Admite funcionalidades avanzadas de protección contra amenazas, como malware e inspección de TLS.
Se recomienda Azure Firewall Estándar para los clientes que buscan un firewall de nivel 3 a nivel 7 y que necesitan escalado automático para administrar los períodos de tráfico máximo de hasta 30 Gbps. Admite características empresariales, como inteligencia sobre amenazas, proxy DNS, DNS personalizado y categorías web.
Se recomienda Azure Firewall Básico para los clientes con necesidades de rendimiento de menos de 250 Mbps.

En la tabla siguiente se muestran las características de las tres SKU de Azure Firewall. Para obtener más información, consulte Precios de Azure Firewall.

Screenshot that shows features of the three Azure Firewall SKUs

De manera predeterminada, los clústeres de AKS tienen acceso de salida a Internet ilimitado. Este nivel de acceso de red permite que los nodos y servicios que se ejecutan en el clúster de AKS accedan a recursos externos según sea necesario. Si quiere restringir el tráfico de salida, es necesario tener accesibles un número limitado de puertos y direcciones a fin de mantener tareas de mantenimiento del clúster en buen estado. La manera más fácil de proporcionar seguridad para el tráfico saliente desde un clúster de Kubernetes como AKS es usar un firewall de software que pueda controlar el tráfico saliente en función de los nombres de dominio. Azure Firewall puede restringir el tráfico saliente HTTP y HTTPS en función del nombre de dominio completo (FQDN) del destino. También puede configurar el firewall y las reglas de seguridad de modo que permitan estos puertos y direcciones necesarios. Para obtener más información, vea Control del tráfico de salida de los nodos de clúster en AKS.

Del mismo modo, puede controlar el tráfico de entrada y mejorar la seguridad si habilita el filtrado basado en inteligencia sobre amenazas en Azure Firewall implementado en una red perimetral compartida. Este filtrado puede proporcionar alertas y denegar el tráfico hacia y desde dominios y direcciones IP malintencionados conocidos.

Posibles casos de uso

Este escenario aborda la necesidad de mejorar la seguridad del tráfico entrante y saliente hacia y desde un clúster de Kubernetes.

Bloqueo del enrutamiento asimétrico

En esta solución, Azure Firewall se implementa en una red virtual de centro (hub) y el clúster de AKS privado en una red virtual de radio (spoke). Azure Firewall usa colecciones de reglas de aplicación y de red para controlar el tráfico de salida. En esta situación, debe configurar el tráfico de entrada a cualquier punto de conexión público expuesto por cualquier servicio que se ejecute en AKS de modo que entre en el sistema a través de una de las direcciones IP públicas usadas por Azure Firewall.

Los paquetes llegan a la dirección IP pública del firewall, pero vuelven al firewall a través de la dirección IP privada (mediante la ruta predeterminada). Esto es un problema. Para evitarlo, cree otra ruta definida por el usuario para la dirección IP pública del firewall, como se muestra en el diagrama siguiente. Los paquetes que van a la dirección IP pública del firewall se enrutan a través de Internet. Esta configuración evita la ruta predeterminada a la dirección IP privada del firewall.

Para enrutar el tráfico de las cargas de trabajo de AKS a Azure Firewall de la red virtual de centro, debe:

Crear una tabla de rutas y asociarla a cada subred que hospede los nodos de trabajo del clúster.
Crear una ruta definida por el usuario para reenviar el tráfico de 0.0.0.0/0 CIDR a la dirección IP privada de Azure Firewall. Especifique Dispositivo virtual en Tipo del próximo salto.

Para más información, consulte el Tutorial: Implementación y configuración de Azure Firewall mediante Azure Portal.

Para más información, consulte:

Implementación de cargas de trabajo en un clúster de AKS privado al usar Azure DevOps

Si usa Azure DevOps, tenga en cuenta que no puede emplear agentes hospedados por Microsoft de Azure DevOps para implementar las cargas de trabajo en un clúster de AKS privado. No tienen acceso a su servidor de API. Para implementar cargas de trabajo en el clúster de AKS privado, debe aprovisionar y usar un agente autohospedado de Azure DevOps en la misma red virtual que el clúster de AKS privado o en una red virtual emparejada. En el último caso, asegúrese de crear un vínculo de red virtual entre la zona DNS privada del clúster de AKS en el grupo de recursos de nodo y la red virtual que hospeda el agente autohospedado de Azure DevOps.

Puede implementar un único agente de Azure DevOps Windows o Linux en una máquina virtual, o bien puede usar un conjunto de escalado de máquinas virtuales. Para obtener más información, consulte Agentes del conjunto de escalado de máquinas virtuales de Azure. Como alternativa, puede configurar un agente autohospedado en Azure Pipelines para que se ejecute dentro de un contenedor de Windows Server Core (para hosts de Windows) o un contenedor de Ubuntu (para hosts de Linux) con Docker. Impleméntelo como un pod con una o varias réplicas en el clúster de AKS privado. Para obtener más información, consulte:

Si las subredes que hospedan los grupos de nodos del clúster de AKS privado están configuradas para enrutar el tráfico de salida a Azure Firewall a través de una tabla de rutas y una ruta definida por el usuario, asegúrese de crear las reglas de red y de aplicación adecuadas. Estas reglas deben permitir que el agente acceda a sitios externos para descargar e instalar herramientas como Docker, Kubectl, la CLI de Azure y Helm en la máquina virtual del agente. Para obtener más información, vea Ejecución de un agente autohospedado en Docker y Compilación e implementación de Azure DevOps Pipeline Agent en AKS.

Uso de Azure Firewall delante de una instancia pública de Standard Load Balancer

Las definiciones de recursos de los módulos de Terraform usan el meta-argumento lifecycle para personalizar acciones cuando los recursos de Azure se modifican fuera del control de Terraform. El argumento ignore_changes se usa para indicar a Terraform que pase por alto las actualizaciones de las propiedades del recurso en cuestión, como las etiquetas. La definición del recurso Directiva de Azure Firewall contiene un bloque lifecycle para evitar que Terraform actualice el recurso cuando se crea, se actualiza o se elimina una única regla o una colección de reglas. Del mismo modo, Tabla de rutas de Azure contiene un bloque lifecycle para evitar que Terraform actualice el recurso cuando se crea, se elimina o se actualiza una ruta definida por el usuario. Esto permite administrar DNAT, la aplicación y las reglas de red de una directiva de Azure Firewall y las rutas definidas por el usuario de una tabla de rutas de Azure fuera del control de Terraform.

El ejemplo asociado a este artículo contiene una canalización de CD de Azure DevOps que muestra cómo implementar una carga de trabajo en un clúster de AKS privado mediante una canalización de Azure DevOps que se ejecuta en un agente autohospedado. En el ejemplo se implementa la aplicación web de administración de proyectos redmine de Bitnami mediante un gráfico de Helm público. En este diagrama se muestra la topología de red del ejemplo:

Este es el flujo de mensajes:

Se envía una solicitud de la aplicación web hospedada en AKS a una dirección IP pública expuesta por Azure Firewall por medio de una configuración de IP pública. Tanto la dirección IP pública como la configuración de IP pública están dedicadas a esta carga de trabajo.
Una regla de DNAT de Azure Firewall traduce la dirección IP pública y el puerto de Azure Firewall a la dirección IP pública y el puerto que usa la carga de trabajo en la instancia pública de Standard Load Balancer de Kubernetes del clúster de AKS en el grupo de recursos de nodo.
El equilibrador de carga envía la solicitud a uno de los pods del servicio de Kubernetes que se ejecuta en uno de los nodos de agente del clúster de AKS.
El mensaje de respuesta se envía al autor de llamada original a través de una ruta definida por el usuario. La dirección IP pública de Azure Firewall es el prefijo de dirección, e Internet es el Tipo del próximo salto.
Cualquier llamada saliente iniciada por la carga de trabajo se enruta a la dirección IP privada de Azure Firewall mediante la ruta predeterminada definida por el usuario. 0.0.0.0/0 el prefijo de dirección, y Dispositivo virtual es el Tipo del próximo salto.

Para obtener más información, vea Uso de Azure Firewall delante de la instancia pública de Standard Load Balancer del clúster de AKS.

Uso de Azure Firewall delante de una instancia interna de Standard Load Balancer

En el ejemplo asociado a este artículo, se hospeda una aplicación ASP.NET Core como servicio en un clúster de AKS, delante de un controlador de entrada NGINX. El controlador de entrada NGINX se expone mediante un equilibrador de carga interno que tiene una dirección IP privada en la red virtual de radio (spoke) que hospeda el clúster de AKS. Para obtener más información, vea Creación de un controlador de entrada para una red virtual interna en AKS. Al implementar un controlador de entrada NGINX o, de manera más general, un servicio LoadBalancer o ClusterIP, con la anotación service.beta.kubernetes.io/azure-load-balancer-internal: "true" de la sección de metadatos, se crea un equilibrador de carga estándar interno de nombre kubernetes-internal en el grupo de recursos de nodo. Para obtener más información, vea Uso de un equilibrador de carga interno con AKS. Como se muestra en el diagrama siguiente, Azure Firewall expone la aplicación web de prueba mediante una dirección IP pública de Azure dedicada.

Este es el flujo de mensajes:

Se envía una solicitud de la aplicación web de prueba hospedada en AKS a una dirección IP pública expuesta por Azure Firewall mediante una configuración de IP pública. Tanto la dirección IP pública como la configuración de IP pública están dedicadas a esta carga de trabajo.
Una regla de DNAT de Azure Firewall traduce la dirección IP pública y el puerto de Azure Firewall a la dirección IP privada y el puerto que usa el controlador de entrada NGINX en la instancia interna de Standard Load Balancer del clúster de AKS en el grupo de recursos de nodo.
El equilibrador de carga interno envía la solicitud a uno de los pods del servicio de Kubernetes que se ejecuta en uno de los nodos de agente del clúster de AKS.
El mensaje de respuesta se envía al autor de llamada original a través de una ruta definida por el usuario. 0.0.0.0/0 el prefijo de dirección, y Dispositivo virtual es el Tipo del próximo salto.
Cualquier llamada saliente iniciada por la carga de trabajo se enruta a la dirección IP privada de la ruta definida por el usuario.

Para obtener más información, vea Uso de Azure Firewall delante de una instancia interna de Standard Load Balancer.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Algunas de las consideraciones siguientes son recomendaciones generales no específicas del uso de Azure Firewall para mejorar la protección de un clúster de AKS. Creemos que son requisitos esenciales de esta solución. Esto se aplica a las consideraciones sobre seguridad, rendimiento, disponibilidad y confiabilidad, almacenamiento, Service Mesh y supervisión.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

La plataforma Azure proporciona una protección mejorada frente a diversas amenazas, como los ataques de intrusión de red y de denegación de servicio distribuido (DDoS). Debe usar un firewall de aplicaciones web (WAF) para proporcionar protección a las aplicaciones web hospedadas en AKS y los servicios que exponen un punto de conexión HTTPS público. Debe proporcionar protección frente a amenazas comunes, como la inserción de SQL, el scripting entre sitios y otras vulnerabilidades de seguridad web. Para ello, use reglas de Open Web Application Security Project (OWASP) y reglas personalizadas. Azure Web Application Firewall ofrece una protección centralizada mejorada de las aplicaciones web frente a vulnerabilidades de seguridad habituales. Puede implementar Azure WAF con Azure Application Gateway, Azure Front Door y Azure Content Delivery Network.

Los ataques DDoS se encuentran entre los mayores problemas de disponibilidad y seguridad a los que se enfrentan las organizaciones que migran sus aplicaciones a la nube. Un ataque DDoS intenta agotar los recursos de una aplicación haciendo que esta no esté disponible para los usuarios legítimos. Los ataques DDoS pueden ir dirigidos a cualquier punto de conexión que sea públicamente accesible a través de Internet. Todas las propiedades de Azure incluyen protección mediante la protección de infraestructura de Azure DDoS sin costo adicional. La escala y la capacidad de la red de Azure implementada globalmente proporciona una defensa mejorada contra los ataques de nivel de red comunes mediante la supervisión constante del tráfico y la mitigación en tiempo real. La protección de la infraestructura contra DDoS no requiere ningún cambio en la configuración de usuarios o en la aplicación. Ayuda a proteger todos los servicios de Azure, incluidos servicios de PaaS como Azure DNS.

Azure DDoS Network Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona características mejoradas de mitigación de DDoS para ofrecer una mejor defensa frente a los ataques de DDoS. Debe habilitar Azure DDOS Network Protection en cualquier red virtual perimetral.

Estas son algunas consideraciones de seguridad adicionales:

Cree un punto de conexión privado para cualquier servicio de PaaS que usen cargas de trabajo de AKS, como Key Vault, Azure Service Bus y Azure SQL Database. El tráfico entre las aplicaciones y estos servicios no se expone a la red pública de Internet. El tráfico entre la red virtual del clúster de AKS y una instancia de un servicio de PaaS a través de un punto de conexión privado recorre la red troncal de Microsoft, pero la comunicación no pasa por Azure Firewall. Este mecanismo proporciona una mejor seguridad y una mejor protección frente a la pérdida de datos. Para obtener más información, consulte ¿Qué es Azure Private Link?.
Si tiene Application Gateway delante del clúster de AKS, use una directiva de Web Application Firewall para ayudar a proteger las cargas de trabajo expuestas al público que se ejecutan en AKS frente a ataques.
Use directivas de red para segregar y ayudar a proteger las comunicaciones entre servicios mediante el control de los componentes que pueden comunicarse entre sí. De manera predeterminada, todos los pods de un clúster de Kubernetes pueden enviar y recibir tráfico sin limitaciones. Para mejorar la seguridad, puede usar directivas de red de Azure o directivas de red de Calico para definir reglas que controlen el flujo de tráfico entre distintos microservicios. Para obtener más información, vea Directivas de red.
No exponga la conectividad remota a los nodos de AKS. Cree una pasarela de aplicaciones, o host jump, en una red virtual de administración. Use el host bastión para enrutar el tráfico al clúster de AKS.
Considere la posibilidad de usar un clúster de AKS privado en el entorno de producción o, al menos, proteja el acceso al servidor de API mediante intervalos de direcciones IP autorizados en AKS. Si usa intervalos de direcciones IP autorizados en un clúster público, permita todas las direcciones IP de salida en la colección de reglas de red de Azure Firewall. Las operaciones en el clúster usan el servidor de API de Kubernetes.
Si habilita el proxy DNS en Azure Firewall, este puede procesar y reenviar consultas de DNS de una o varias redes virtuales a un servidor DNS de su elección. Esta funcionalidad es fundamental y necesaria para un filtrado de FQDN confiable en las reglas de red. Puede habilitar el proxy DNS en la configuración de Azure Firewall y en la configuración de directiva de firewall. Para obtener más información sobre los registros de proxy DNS, vea Métricas y registros de Azure Firewall.
Si usa Azure Firewall delante de Application Gateway, puede configurar el recurso de entrada de Kubernetes para exponer cargas de trabajo a través de HTTPS, y usar un subdominio independiente y un certificado digital para cada inquilino. El controlador de entrada de Application Gateway (AGIC) configura automáticamente el cliente de escucha de Application Gateway para la terminación de Capa de sockets seguros (SSL).
Puede usar Azure Firewall delante de un proxy de servicio como el controlador de entrada NGINX. Este controlador proporciona proxy inverso, enrutamiento de tráfico configurable y terminación TLS para servicios de Kubernetes. Los recursos de entrada de Kubernetes se usan para configurar las reglas de entrada y las rutas de los distintos servicios de Kubernetes. Con un controlador de entrada y reglas de entrada se puede usar una sola dirección IP para enrutar el tráfico a varios servicios en un clúster de Kubernetes. Puede generar los certificados TLS mediante una entidad de certificación reconocida. También puede usar Let's Encrypt para generar certificados TLS de forma automática con una dirección IP pública dinámica o con una dirección IP pública estática. Para obtener más información, vea Creación de un controlador de entrada HTTPS y uso de sus propios certificados TLS en AKS.
Es necesaria una coordinación estricta entre el operador de Azure Firewall y los equipos de clúster y carga de trabajo tanto para la implementación inicial del clúster como de forma continuada a medida que evolucionan las necesidades de carga de trabajo y clúster. Esto es especialmente así cuando se configuran los mecanismos de autenticación, como OAuth 2.0 y OpenID Connect, que son usados por las cargas de trabajo para autenticar a sus clientes.
Use las siguientes directrices para ayudar a proteger el entorno descrito en este artículo:

Disponibilidad y confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Estas consideraciones sobre disponibilidad y confiabilidad no son específicas del uso de varios inquilinos en AKS. Creemos que son requisitos esenciales de esta solución. Tenga en cuenta los métodos siguientes para optimizar la disponibilidad del clúster de AKS y las cargas de trabajo.

Resistencia dentro de una región

Durante la implementación, puede configurar Azure Firewall de modo que abarque varias zonas de disponibilidad a fin de lograr una mayor disponibilidad. Para obtener los porcentajes de tiempo de actividad, vea el SLA de Azure Firewall. También puede asociar Azure Firewall a una zona específica por motivos de proximidad, aunque esta configuración afecta al Acuerdo de Nivel de Servicio. No hay ningún costo adicional por un firewall implementado en una zona de disponibilidad, aunque hay costos adicionales por las transferencias de datos entrantes y salientes asociadas a zonas de disponibilidad. Para más información, consulte Detalles de precios de ancho de banda.
Considere la posibilidad de implementar los grupos de nodos del clúster de AKS en todas las zonas de disponibilidad de una región. Use una instancia de Azure Standard Load Balancer o Application Gateway delante de los grupos de nodos. Esta topología proporciona una mayor resistencia en caso de una única interrupción del centro de datos. Los nodos de clúster se distribuyen entre varios centros de datos, en tres zonas de disponibilidad independientes dentro de una región.
Habilite la redundancia de zona en Container Registry para lograr resistencia dentro de una región y alta disponibilidad.
Use restricciones de propagación de topología de pod para controlar cómo se reparten los pods en el clúster de AKS entre dominios de error como regiones, zonas de disponibilidad y nodos.
Considere la posibilidad de usar el Acuerdo de Nivel de Servicio de tiempo de actividad para clústeres de AKS que hospedan cargas de trabajo críticas. El Acuerdo de Nivel de Servicio de tiempo de actividad es una característica opcional que habilita un mejor Acuerdo de Nivel de Servicio con respaldo financiero para un clúster. El Acuerdo de Nivel de Servicio de tiempo de actividad garantiza una alta disponibilidad del punto de conexión del servidor de API de Kubernetes para los clústeres que usan zonas de disponibilidad. También puede usarlo para clústeres que no usan zonas de disponibilidad, pero el Acuerdo de Nivel de Servicio es inferior. Para obtener detalles sobre el Acuerdo de Nivel de Servicio, vea Acuerdo de nivel de servicio de tiempo de actividad. AKS usa réplicas de nodo maestro en los dominios de actualización y de error para garantizar que se cumplan los requisitos del acuerdo de nivel de servicio.

Recuperación ante desastres y continuidad empresarial

Considere la posibilidad de implementar la solución en al menos dos regiones de Azure emparejadas dentro de una geografía. Use un equilibrador de carga global, como Azure Traffic Manager o Azure Front Door, con un método de enrutamiento activo/activo o activo/pasivo, con el fin de garantizar la continuidad empresarial y recuperación ante desastres (DR).
Azure Firewall es un servicio regional. Si implementa la solución en dos o más regiones, debe crear una instancia de Azure Firewall en cada región. Puede crear una directiva de Azure Firewall global para incluir reglas de la organización que se apliquen a todos los centros regionales. Puede usar esta directiva como directiva primaria de las directivas regionales de Azure. Las directivas creadas con directivas primarias no vacías heredan todas las colecciones de reglas de la directiva primaria. Las colecciones de reglas de red heredadas de una directiva primaria siempre tienen prioridad con respecto a las colecciones de reglas de red definidas como parte de una nueva directiva. La misma lógica se aplica a las colecciones de reglas de aplicación. Pero las colecciones de reglas de red siempre se procesan antes que las colecciones de reglas de aplicación independientemente de la herencia. Para obtener más información sobre las directivas estándar y prémium, vea Información general sobre la directiva de Azure Firewall Manager.
Asegúrese de crear scripts, documentar y probar periódicamente cualquier proceso de conmutación por error regional en un entorno de control de calidad. Esto ayuda a evitar problemas impredecibles si un servicio principal se ve afectado por una interrupción en la región primaria. Estas pruebas también comprueban si el enfoque de recuperación ante desastres cumple los objetivos de RPO/RTO, junto con los posibles procesos manuales y las intervenciones necesarias para una conmutación por error.
Asegúrese de probar los procedimientos de conmutación por recuperación para validar que funcionan según lo previsto.
Almacene las imágenes de contenedor en Container Registry. Replique geográficamente el registro en cada región de AKS. Para más información, consulte Replicación geográfica en Azure Container Registry.
Si es posible, evite almacenar el estado del servicio en el contenedor. En su lugar, use una plataforma como servicio de Azure que admita la replicación en varias regiones.
Si usa Azure Storage, prepare y pruebe un proceso para migrar el almacenamiento desde la región primaria a la región de copia de seguridad.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

DevOps

Implemente las cargas de trabajo en AKS mediante un gráfico de Helm en una canalización de integración continua y entrega continua (CI/CD). Use un sistema de DevOps como Acciones de GitHub o Azure DevOps. Para obtener más información, consulte Compilación e implementación de Azure Kubernetes Service.
Para probar correctamente una aplicación antes de ponerla a disposición de los usuarios, use pruebas A/B e implementaciones de valor controlado en la administración del ciclo de vida de la aplicación. Hay varias técnicas que puede usar para dividir el tráfico entre distintas versiones del mismo servicio. Como alternativa, puede usar las funcionalidades de división de tráfico proporcionadas por una implementación de malla de servicio. Para obtener más información, vea División de tráfico de Linkerd y Administración de tráfico de Istio.
Use Azure Container Registry u otro registro de contenedor, como Docker Hub, para almacenar las imágenes de Docker privadas que se implementan en el clúster. AKS se puede autenticar con Azure Container Registry mediante su identidad de Microsoft Entra.
Pruebe la entrada y salida en las cargas de trabajo en un entorno de preproducción independiente que refleje la topología de red y las reglas de firewall del entorno de producción. Una estrategia de implementación por fases le ayudará a detectar cualquier problema de red o seguridad antes de publicar una nueva característica o regla de red en producción.

Supervisión

Azure Firewall está totalmente integrado con Azure Monitor para el registro del tráfico entrante y saliente procesado por el firewall. Para más información, consulte Filtrado basado en inteligencia sobre amenazas de Azure Firewall.

Las siguientes consideraciones sobre supervisión no son específicas del uso de varios inquilinos en AKS, pero creemos que son requisitos esenciales de esta solución.

Use Container Insights para supervisar el estado de mantenimiento del clúster y las cargas de trabajo de AKS.
Configure todos los servicios de PaaS (como Container Registry y Key Vault) para recopilar registros de diagnóstico y métricas.

Optimización de costos

El costo de la arquitectura resultante depende de los siguientes detalles de configuración:

Niveles de servicio
Escalabilidad (el número de instancias asignadas dinámicamente por los servicios para admitir una demanda determinada)
Scripts de automatización
El nivel de recuperación ante desastres.

Después de evaluar estos detalles de configuración, use la Calculadora de precios de Azure para calcular los costos. Para obtener más opciones de optimización de precios, vea los principios de optimización de costos en el Marco de buena arquitectura de Microsoft Azure.

Implementación de este escenario

El código fuente de este escenario está disponible en GitHub. Esta solución es de código abierto y se proporciona con una licencia MIT.

Requisitos previos

En las implementaciones en línea necesita una cuenta de Azure. Si no la tiene, cree una cuenta gratuita de Azure antes de empezar. Debe cumplir estos requisitos para poder implementar módulos de Terraform mediante Azure DevOps:

Almacene el archivo de estado de Terraform en una cuenta de almacenamiento de Azure. Para obtener más información sobre el uso de una cuenta de almacenamiento para almacenar el estado remoto de Terraform, el bloqueo de estado y el cifrado en reposo, vea Almacenamiento del estado de Terraform en Azure Storage.
Cree un proyecto de Azure DevOps. Para obtener más información, vea Creación de un proyecto en Azure DevOps.
Cree una conexión del servicio Azure DevOps a la suscripción de Azure. Puede usar la autenticación de entidad de servicio (SPA) o una identidad de servicio administrada de Azure al crear la conexión del servicio. En cualquier caso, asegúrese de que la entidad de servicio o la identidad administrada que usa Azure DevOps para conectarse a la suscripción de Azure tenga asignado el rol de propietario en toda la suscripción.

Implementación en Azure

Tenga a mano la información de la suscripción de Azure.

Clone el repositorio de GitHub de workbench:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Siga las instrucciones proporcionadas en el archivo README.md.

Colaboradores

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

Autor principal:

Paolo Salvatori | Ingeniero de servicio principal

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

Pasos siguientes

Revise las recomendaciones y los procedimientos recomendados de AKS en el Marco de buena arquitectura de Microsoft Azure:

Uso de Azure Firewall para ayudar a proteger un clúster de Azure Kubernetes Service (AKS)