Casos de uso de redes entre clústeres para Azure Kubernetes Fleet Manager (versión preliminar)

Las redes entre clústeres para Azure Kubernetes Fleet Manager (Fleet) son una solución administrada basada en Cilium Cluster Mesh que permite establecer comunicación directa de pod a pod entre varios clústeres de Azure Kubernetes Service (AKS). Al crear una red entre clústeres, puede habilitar una conectividad este-oeste fluida sin necesidad de pasarelas, al tiempo que obtiene observabilidad multiclúster y una aplicación uniforme de las políticas de seguridad.

Arquitectura y funcionalidades

En una configuración de red entre clústeres, una red virtual plana permite a los pods de distintos clústeres enrutar el tráfico directamente a través de los límites de clúster. Normalmente, a cada clúster se le asignan dos subredes: una para nodos y otra para pods. Esta arquitectura coherente garantiza que la red de pods siga siendo plana en la red entre clústeres, sin utilizar redes de superposiciones o túneles.

Diagrama en el que se muestra la arquitectura de Azure Kubernetes Fleet Manager que administra la conectividad entre clústeres east-west. Los pods de diferentes clústeres se comunican directamente a través de agentes de Cilium en redes virtuales emparejadas.

Entre los componentes y funcionalidades clave de este escenario se incluyen:

  • Azure CNI con el plano de datos de Cilium: ambos clústeres de AKS deben usar Azure CNI con el plano de datos de Azure CNI basado en Cilium.
  • Advanced Container Networking Services (ACNS): ACNS debe estar habilitado en los clústeres para admitir este escenario.
  • Azure Kubernetes Fleet Manager: Fleet administra el ciclo de vida y la configuración de la red entre clústeres a través de recursos como el perfil de ClusterMesh.
  • Rendimiento nativo: el enrutamiento de IP de los pods se realiza entre clústeres con rendimiento nativo mediante enrutamiento directo, sin necesidad de puertas de enlace ni proxies.
  • Aplicación unificada de directivas de red: amplía la aplicación de directivas de red de nivel 3-7 de Cilium a todos los clústeres de la red entre clústeres, lo que garantiza un enfoque de seguridad coherente.
  • Observabilidad de varios clústeres: proporciona visibilidad integral de los flujos de tráfico entre clústeres. Esta visibilidad le ayuda a supervisar el estado de la aplicación, a solucionar problemas de conectividad y a analizar los patrones de tráfico en toda la red entre clústeres.

Casos de uso

Las redes entre clústeres permiten varios escenarios clave de varios clústeres. En las secciones siguientes se describen los casos de uso más comunes para las redes entre clústeres con Fleet.

Caso de uso: Detección de servicios transparente y equilibrio de carga

Cuando se usan servicios de Kubernetes estándar y se marcan como globales, Cilium detecta automáticamente los puntos de conexión de esos servicios en todos los clústeres de la red entre clústeres. Cualquier tráfico destinado a un servicio ClusterIP global se equilibra automáticamente la carga en todos los clústeres que contribuyen, lo que simplifica la comunicación entre clústeres.

Las aplicaciones pueden detectar e interactuar con servicios independientemente del clúster en el que residen, sin necesidad de cambios en el nivel de aplicación ni registros de servicios externos.

Caso de uso: alta disponibilidad y tolerancia a errores

La alta disponibilidad es el caso de uso más común para las redes entre clústeres. Este caso de uso incluye el funcionamiento de clústeres de Kubernetes en varias regiones o zonas de disponibilidad y la ejecución de réplicas de los mismos servicios en cada clúster. En caso de fallo, las solicitudes pueden redirigirse automáticamente a otros clústeres de la red multiclúster.

El escenario de error descrito en este caso de uso no es principalmente la falta de disponibilidad completa de toda una región o dominio de error. Un escenario más probable es la falta de disponibilidad temporal de los recursos o la configuración incorrecta en un clúster, lo que conduce a la incapacidad de ejecutar o escalar servicios concretos en ese clúster. Con las redes entre clústeres, el tráfico destinado al servicio afectado se enruta automáticamente a puntos de conexión correctos en otros clústeres, lo que mantiene la aplicación disponible.

Diagrama que muestra dos clústeres de AKS en distintas regiones. Los frontends de cada clúster enrutan a un servicio de órdenes local respaldado por pods de pedidos. Cuando los pods del clúster B dejan de estar en buen estado, el servicio de pedidos del clúster B realiza la conmutación por error al servicio de pedidos del clúster A.

Caso de uso: Servicios compartidos

Aunque la tendencia inicial de las plataformas basadas en Kubernetes era crear clústeres grandes y multiinquilino, es cada vez más común crear clústeres individuales por inquilino o crear clústeres para diferentes categorías de servicios, como distintos niveles de confidencialidad de seguridad.

Sin embargo, algunos servicios, como la administración de secretos, el registro, la supervisión o DNS, a menudo se comparten entre todos los clústeres. La centralización de estos servicios en un clúster compartido de "servicio" evita la sobrecarga operativa de mantenerlos en cada clúster de inquilinos.

La motivación principal de este modelo es el aislamiento entre clústeres de inquilinos. Para mantener ese objetivo, los clústeres de inquilinos solo están conectados al clúster de servicios compartidos y no están conectados a otros clústeres de inquilinos.

Diagrama que muestra dos clústeres AKS de tenant con aplicaciones que llaman al cliente de secretos. Ambos clústeres de tenant dirigen el tráfico a un clúster de servicios compartidos que aloja el servicio de secretos, respaldado por los pods vault-1 y vault-2. Los clústeres de tenant solo se conectan al clúster de servicios compartidos, no entre sí.

Caso de uso: separación con estado y sin estado

Puede aislar la complejidad operativa de los servicios con estado, como bases de datos y almacenamiento, en clústeres dedicados. Esta separación mantiene los clústeres de aplicaciones sin estado ágiles y fáciles de migrar. También mejora la seguridad, simplifica la administración del ciclo de vida del clúster y permite escalar cargas de trabajo sin estado de forma independiente de las cargas de trabajo con estado.

Diagrama que muestra dos clústeres de AKS sin estado, cada uno con enrutamiento de entrada a un cliente de front-end y almacén de datos. Ambos clústeres sin estado se conectan a un clúster con estado dedicado que hospeda el servicio de almacén de datos respaldado por los pods data-1, data-2 y data-n.

Caso de uso: Cumplimiento de directivas y seguridad de varios clústeres

Las redes entre clústeres amplían la aplicación de directivas de red de nivel 3-7 de Cilium en todos los clústeres de la red entre clústeres. Esta aplicación unificada garantiza una posición de seguridad coherente y simplifica la administración de directivas evitando la necesidad de replicar manualmente directivas en todos los entornos. Las directivas aplicadas en un clúster se aplican en el resto de clústeres, lo que proporciona una seguridad unificada y basada en identidades en toda su flota.

Caso de uso: Observabilidad de varios clústeres

Las redes entre clústeres proporcionan visibilidad integral del tráfico que fluye entre los servicios entre clústeres. Al agregar datos de flujo de todos los clústeres de la red entre clústeres, puede visualizar el tráfico este-oeste, supervisar el estado de la aplicación entre regiones, solucionar problemas de conectividad entre clústeres y analizar patrones de tráfico para planear la capacidad.

Con los registros de red de contenedor, los operadores obtienen una vista unificada de la comunicación de pod a pod independientemente del clúster en el que reside el origen o el destino, sin instrumentar aplicaciones.

Servicios globales

Para habilitar el flujo de tráfico entre clústeres, debe configurar los servicios de Kubernetes como servicios globales. En una red entre clústeres, un servicio global es un servicio estándar de Kubernetes que se comparte entre varios clústeres. Al marcar un servicio como global, Cilium detecta automáticamente los puntos de conexión de ese servicio en todos los clústeres de la red entre clústeres y realiza el equilibrio de carga entre ellos.

Una vez que un servicio se marca como global, se respetan las directivas aplicadas en un clúster en los demás clústeres de la red entre clústeres, lo que proporciona una posición de seguridad coherente. Esta configuración permite:

  • Detección de servicios transparente: las aplicaciones pueden detectar e interactuar con servicios independientemente del clúster en el que residen.
  • Alta disponibilidad: si un servicio de un clúster deja de estar disponible, el tráfico se desplaza automáticamente a una instancia correcta en otro clúster.

Cilium gestiona este descubrimiento observando los servicios con la anotación io.cilium/global-service: "true". Para estos servicios, todos los puntos de conexión con el mismo nombre y espacio de nombres entre clústeres se combinan en un único servicio global. La carga del tráfico destinado al ClusterIP de ese servicio se equilibra en todos los clústeres que contribuyen.

Limitaciones

  • Un clúster miembro solo puede participar en una red entre clústeres a la vez.
  • Una única red entre clústeres admite hasta 255 clústeres miembro.
  • Las configuraciones de varios clústeres de Cilium autoadministradas no se admiten junto con las redes entre clústeres administradas por Flota.
  • Los comandos de la CLI de Cilium que modifican la malla, como cilium clustermesh connect o cilium upgrade, no se admiten porque Fleet administra estas operaciones.
  • Las redes entre clústeres están restringidas a los clústeres dentro del mismo dominio de enrutamiento plano accesible. No admite la conectividad de malla entre redes virtuales no emparejadas.

Pasos siguientes

  • Last updated on