Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Importante
Las características en versión preliminar de AKS están disponibles a elección del usuario y en régimen de autoservicio. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y garantía limitada. Las versiones preliminares de AKS cuentan con soporte parcial por parte del servicio al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:
La arquitectura de azure Kubernetes Application Network se organiza en tres capas: un plano de administración, un plano de control y un plano de datos. Cada capa tiene responsabilidades distintas que proporcionan una solución de red de servicio totalmente administrada basada en ambiente para Azure Kubernetes Service (AKS). Esta arquitectura permite la comunicación segura y controlada por directivas entre servicios sin necesidad de ningún sidecar ni de realizar cambios en las aplicaciones.
En este artículo se proporciona información general sobre las capas arquitectónicas de Azure Kubernetes Application Network, cómo interactúan y el modelo de detección de servicios de varios clústeres que permite la comunicación entre clústeres escalable. Para más información sobre Azure Kubernetes Application Network, consulte Introducción a Azure Kubernetes Application Network for AKS.
Información general sobre las capas de arquitectura de Application Network
Las capas arquitectónicas administran las siguientes responsabilidades:
- Plano de administración: controla las operaciones de recursos de Azure, como crear, actualizar y eliminar recursos de Application Network y administrar la pertenencia al clúster.
- Plano de control: administra la configuración de malla, el ciclo de vida de los certificados y la detección de servicios para cada clúster miembro.
- Plano de datos: protege el tráfico de servicio a servicio directamente en el clúster miembro mediante el modo ambiente, que no requiere ningún sidecar ni realizar cambios en las aplicaciones.
En el caso de las implementaciones de varios clústeres, Application Network sincroniza la información de detección de servicios entre clústeres miembros para que los servicios puedan comunicarse de forma transparente a través de los límites del clúster.
En el diagrama siguiente se muestran las capas arquitectónicas de Azure Kubernetes Application Network y cómo interactúan entre sí y con los clústeres de AKS:
Plano de administración
El plano de administración es el proveedor de recursos de Azure que controla todas las operaciones de recursos de Application Network. Cuando se crea un recurso de Application Network o se une a un clúster miembro, el plano de administración valida la solicitud, aprovisiona recursos de Azure como Azure Key Vault para el almacenamiento de certificados y organiza la creación de un plano de control regional para el miembro.
Interactúe con el plano de administración mediante la CLI de Azure (az appnet) o la API de ARM. El plano de administración coordina todo el aprovisionamiento descendente para que los componentes del plano de control y del plano de datos se implementen sin intervención manual.
Plano de control
El plano de control es una infraestructura totalmente administrada que se ejecuta fuera del clúster de AKS. Cuando un clúster miembro se une a una red de aplicaciones, se aprovisiona un plano de control dedicado en la misma región de Azure que el clúster miembro, lo que mantiene baja la latencia entre los componentes del plano de datos y el control.
Nota:
Los miembros de diferentes regiones de Azure tienen planos de control implementados en sus respectivas regiones.
El plano de control incluye los siguientes componentes:
- Istiod: se conecta al servidor de API de Kubernetes del clúster miembro para detectar servicios y observar los cambios de configuración. Inserta la configuración de xDS en ztunnel y los servidores proxy de punto de acceso en el plano de datos. En las implementaciones de varios clústeres, Istiod también se conecta a los servidores de API de Kubernetes de otros clústeres miembros para obtener información de detección de servicios, lo que permite la detección de servicios entre clústeres.
- Administración de certificados: Aprovisiona y rota los certificados de entidad de certificación respaldados por Azure Key Vault. Una Autoridad de Certificación raíz establece un límite de confianza compartido entre todos los clústeres miembros y cada miembro recibe una Autoridad de Certificación intermedia que emite certificados de carga de trabajo de corta duración. Para más información, consulte Introducción a la seguridad de azure Kubernetes Application Network.
- Administración del ciclo de vida: implementa y actualiza todos los componentes del plano de datos del clúster miembro, incluidos ztunnel, Istio CNI, servidores proxy de waypoint y definiciones de recursos personalizados (CRD). Para más información, consulte Configuración de actualizaciones para los miembros de Application Network de Azure Kubernetes.
Plano de datos
El plano de datos consta de componentes implementados en el espacio de nombres del applink-system clúster miembro. La Red de Aplicaciones usa el modo ambiental de Istio, por lo que no se inyecta ningún sidecar en las cargas de trabajo.
El plano de datos incluye los siguientes componentes:
- Ztunnel: proxy L4 de nivel de nodo implementado como daemonSet. Ztunnel intercepta el tráfico de servicio a servicio en el nodo, establece las conexiones mTLS de forma transparente y aplica las directivas de autorización L4.
- Servidores proxy de Waypoint: servidores proxy L7 opcionales por espacio de nombres que proporcionan enrutamiento HTTP, gestión del tráfico, inyección de errores y autorización L7. Los servidores proxy de Waypoint solo se implementan cuando las directivas L7 están configuradas para un espacio de nombres.
- Puerta de enlace este-oeste: controla el tráfico entre clústeres en implementaciones de varios clústeres. Es responsable de proporcionar conectividad de red entre puertas de enlace este-oeste en cada clúster miembro. Para más información, consulte Detección de servicios de varios clústeres.
- Istio CNI: daemonSet que configura las redes de pod para la interceptación del tráfico de malla ambiental.
- CRDs: definiciones de recursos personalizados de Kubernetes para configurar directivas de seguridad y administración del tráfico.
Cuando se realiza una solicitud entre servicios, ztunnel intercepta el tráfico, establece una conexión mTLS con el ztunnel del destino y entrega la solicitud a la carga de trabajo de destino. Si se configuran directivas L7, el tráfico se enruta a través de un proxy intermedio antes de llegar a su destino. Para el tráfico entre clústeres, ztunnel enruta a través de la puerta de enlace este-oeste para llegar a las cargas de trabajo de los clústeres de miembros remotos.
Detección de servicios de varios clústeres
Application Network admite la conexión de varios clústeres de AKS a una malla de servicio unificada. Los servicios de un clúster miembro pueden comunicarse con los servicios de otros clústeres miembro, con mTLS aplicado de un extremo a otro a través de los límites del clúster.
En las implementaciones de varios clústeres de Istio de código abierto, los planos de control normalmente se conectan a los servidores de API de Kubernetes de otros clústeres para detectar los servicios y los cambios de configuración. Application Network sigue un modelo de detección de servicios similar, donde los planos de control obtienen información de servicio de los clústeres miembros para que los servicios se puedan detectar a través de los límites del clúster. Este enfoque permite que las cargas de trabajo de un clúster miembro resuelvan y se comuniquen con los servicios que se ejecutan en otros clústeres sin necesidad de cambios en la aplicación. Al agregar un nuevo clúster de miembros, se expande la pertenencia a la malla para que otros miembros puedan detectar los servicios del nuevo clúster.
El tráfico entre clústeres fluye a través de puertas de enlace este-oeste implementadas en cada clúster miembro. Es responsable de proporcionar accesibilidad de red entre las puertas de enlace este-oeste de los clústeres miembros, por ejemplo, mediante el emparejamiento de VNet, VPN u otras soluciones de conectividad. Todo el tráfico entre clústeres se cifra con mTLS.
Cómo interactúan los componentes
El plano de control se conecta al servidor de API de Kubernetes del clúster miembro, busca cambios en el servicio y la configuración, e inserta actualizaciones xDS en servidores proxy ztunnel y waypoint. Cuando existen varios miembros, cada plano de control también intercambia información de servicio a través de la mensajería administrada para que cada miembro tenga una vista coherente de todos los servicios en la malla.
La administración de certificados aprovisiona una ENTIDAD de certificación raíz cuando se crea el recurso de Application Network y emite entidades de certificación intermedias para cada clúster miembro. Los certificados de carga de trabajo se emiten con un período de validez de 24 horas y se rotan automáticamente cada 12 horas. Todo el ciclo de vida del certificado, desde la entidad de certificación raíz hasta los certificados intermedios y de carga de trabajo, se administra sin intervención manual.
Para obtener la jerarquía de certificados completa y la programación de rotación, consulte La información general sobre la seguridad de Azure Kubernetes Application Network.
Contenido relacionado
Para más información sobre Azure Kubernetes Application Network, consulte los artículos siguientes: