En el siguiente artículo, os explicamos, según el marco de diseño de Azure, cual debería ser la arquitectura base de una solución de AKS. Los principios de diseño se basan en los procedimientos recomendados de arquitectura de nuestro marco de buena arquitectura de Azure para guiar a un equipo interdisciplinario o a varios equipos distintos.
Topología de red.
La topología de red más recomendada para nuestro clúster de Azure Kubernetes Service es la topología de red en estrella tipo hub-spoke. El centro y los radios se implementan en redes virtuales independientes conectadas a través del emparejamiento (vnet peering).
Algunas de las ventajas de esta topología son:
- Administración segregada. Permite 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.
- Minimiza la exposición directa a los recursos de Azure de la red pública de Internet.
- A menudo, las organizaciones operan con topologías en estrella tipo hub-and-spoke. Las topologías de red en estrella tipo hub-and-spoke se pueden expandir en el futuro y proporcionar aislamiento de la carga de trabajo.
- Todas las aplicaciones web requieren un servicio de firewall de aplicaciones web (WAF) para ayudar a controlar los flujos de tráfico HTTP.
- Una opción natural para las cargas de trabajo que abarcan varias suscripciones.
- Hace que la arquitectura sea extensible. Para acomodar nuevas características o cargas de trabajo, se pueden agregar nuevos radios en lugar de volver a diseñar la topología de red.
- Determinados recursos, como un firewall y DNS, pueden compartirse entre redes.
Hub
La red virtual de centro es el punto central de conectividad y observabilidad. El centro contiene una instancia de 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 y Azure Monitor para la observabilidad de red.
Dentro de la red, se implementan tres subredes.
– Subred para hospedar Azure Firewall
Azure Firewall es un firewall como servicio. La instancia de firewall protege el tráfico de red saliente. Sin este nivel de seguridad, el tráfico puede comunicarse con un servicio malintencionado de terceros que podría exfiltrar los datos confidenciales de la empresa. Azure Firewall Manager permite 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 de concentrador.
– Subred para hospedar una puerta de enlace
Esta subred es un marcador de posición de una puerta de enlace de ExpressRoute o VPN. 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 Bastion para acceder de forma segura a los recursos de Azure sin exponer los recursos a Internet. Esta subred solo se usa para la administración y las operaciones.
Radio
La red virtual de radios contiene el clúster de AKS y otros recursos relacionados. El radio tiene cuatro subredes:
Subred para hospedar Azure Application Gateway
Azure 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 el firewall de aplicaciones web (WAF). WAF 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 más información, consulte Uso de un equilibrador de carga interno con Azure Kubernetes Service (AKS).
Subred para hospedar los nodos de clúster
AKS mantiene dos grupos independientes de nodos (o grupos 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 Private Link
Las conexiones de Azure Private Link se crean para Azure Container Registry y Azure Key Vault, por lo que se puede acceder a estos servicios mediante puntos de conexión privados dentro de la red virtual de radio. Los puntos de conexión privados no requieren una subred dedicada y también se pueden colocar en la red virtual del concentrador. En la implementación de línea base, se implementan en una subred dedicada dentro de la red virtual de radio. Este enfoque reduce el tráfico que pasa la conexión de la red emparejada, mantiene los recursos que pertenecen al clúster en la misma red virtual y permite aplicar reglas de seguridad granulares en el nivel de subred mediante grupos de seguridad de red.
Plan de direccionamiento IP.
El espacio de direcciones de la red virtual debe ser lo suficientemente grande como para contener todas las subredes. Tenga en cuenta todas las entidades que reciben tráfico. Las direcciones IP de esas entidades se asignarán desde el espacio de direcciones de la subred.
Proceso de actualización
AKS actualiza los nodos con regularidad para asegurarse de que las características de seguridad de las máquinas virtuales subyacentes y otras revisiones del sistema estén actualizadas. 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.
En el caso de los pods, es posible que necesite direcciones adicionales, en función de la estrategia. En el caso de las actualizaciones graduales, necesitará direcciones para los pods temporales que ejecutan la carga de trabajo mientras se actualizan los pods reales. Si usa la estrategia de reemplazo, se quitan los pods y se crean los nuevos. Por lo que, se reutilizan las direcciones asociadas a los pods anteriores.
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.
En esta arquitectura, se puede establecer contacto con cada pod directamente. Por lo tanto, cada pod necesita una dirección individual. La escalabilidad del pod afecta al cálculo de la dirección. Esta decisión dependerá de su elección sobre el número de pods que desee aumentar.
Direcciones de Azure Private Link
Factorice las direcciones que son necesarias para la comunicación con otros servicios de Azure a través de Private Link. En esta arquitectura, hay dos direcciones asignadas para los vínculos a Azure Container Registry y Key Vault.
Esta arquitectura se ha diseñado para gestionar una única carga de trabajo. Para múltiples cargas de trabajo, podría ser conveniente aislar los grupos de nodos de usuarios entre ellos y del grupo de nodos del sistema. Tal enfoque resultaría en la creación de subredes más pequeñas. Además, los recursos de entrada podrían volverse más complejos, lo que podría requerir múltiples controladores de entrada con la necesidad de direcciones IP adicionales.
Os animamos a compartir con nosotros vuestras opiniones en X: @mundoazure
