Share via

Consideraciones de topología de red y conectividad para AKS

  • Artículo

Consideraciones de diseño

Azure Kubernetes Service (AKS) proporciona tres modelos de red diferentes para redes de contenedor: Kubenet, la superposición de CNI y CNI. Cada uno de estos modelos tiene su conjunto único de características y ventajas, lo que ofrece flexibilidad y opciones de escalabilidad para las redes de contenedores en AKS.

Kubenet

Kubenet es una solución de red básica que conserva el espacio de direcciones IP y ofrece una configuración sencilla. Es ideal para clústeres de AKS pequeños con menos de 400 nodos, en los que es aceptable administrar y mantener manualmente las rutas definidas por el usuario. Es adecuado para escenarios en los que los equilibradores de carga internos o externos son suficientes para llegar a pods desde el exterior del clúster.

CNI de Azure

Azure CNI es un modelo de red diseñado para redes avanzadas. Proporciona conectividad de red virtual completa para pods, lo que permite la conectividad pod a pod y pod a máquina virtual. Es ideal para escenarios en los que se requieren características avanzadas de AKS, como nodos virtuales. Es adecuado para escenarios en los que hay suficiente espacio de direcciones IP disponible y los recursos externos necesitan llegar directamente a los pods. Las directivas de red de AKS también se admiten con Azure CNI.

Superposición de Azure CNI

La superposición de Azure CNI está diseñada para abordar la escasez de direcciones IP y simplificar la configuración de red. Es adecuado para escenarios en los que el escalado vertical de hasta 1000 nodos y 250 pods por nodo es suficiente y un salto adicional para la conectividad de pods es aceptable. Los requisitos de salida de AKS también se pueden cumplir con la superposición de Azure CNI.

Para obtener un resumen de los casos de uso recomendados por modelo de red, consulte Comparación de modelos de red en AKS.

Además, al diseñar el clúster de AKS, es importante planear cuidadosamente el direccionamiento IP y el tamaño de la subred de red virtual para admitir el escalado. Los nodos virtuales se pueden usar para el escalado rápido de clústeres, pero hay algunas limitaciones conocidas.

Los clústeres de AKS admiten SKU de Azure Load Balancer estándar y básico, y los servicios se pueden exponer con equilibradores de carga públicos o internos. AKS usa CoreDNS para proporcionar resolución de nombres a pods que se ejecutan en el clúster y el tráfico de red saliente (salida) se puede enviar a través de un clúster de aplicaciones virtuales de red o Azure Firewall.

De forma predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin limitaciones. Sin embargo, las directivas de red de Kubernetes se pueden usar para mejorar la seguridad y filtrar el tráfico de red entre pods en un clúster de AKS. Hay dos modelos de directivas de red disponibles para AKS: directivas de red de Azure y Calico.

Finalmente, AKS configura un grupo de seguridad de red (NSG) en la subred en la que se implementa el clúster. Se recomienda no editar manualmente este NSG, pero los servicios implementados en AKS pueden influir en él.

En general, seleccionar el modelo de red adecuado y planear cuidadosamente los recursos de red puede ayudar a optimizar el rendimiento, la seguridad y el costo del clúster de AKS.

Clústeres privados

La visibilidad de IP del clúster de AKS puede ser pública o privada. Los clústeres privados exponen la API de Kubernetes mediante una dirección IP privada, pero no una pública. Esta dirección IP privada se representa en la red virtual de AKS mediante un punto de conexión privado. No se debe tener acceso a la API de Kubernetes mediante su dirección IP, sino mediante su nombre de dominio completo (FQDN). Normalmente, la resolución del FQDN de la API de Kubernetes en su dirección IP se realiza mediante una zona de DNS privado de Azure. Azure puede crear esta zona DNS en el grupo de recursos del nodo de AKS o bien puede especificar una zona DNS existente.

Después de las prácticas probadas a escala empresarial, la resolución de DNS para cargas de trabajo de Azure se ofrece mediante servidores DNS centralizados implementados en la suscripción de conectividad, ya sea en una red virtual de concentrador o en una red virtual de servicios compartidos conectada a Azure Virtual WAN. Estos servidores resolverán condicionalmente los nombres específicos de Azure y públicos con Azure DNS (dirección IP 168.63.129.16) y los nombres privados con servidores DNS corporativos. Sin embargo, estos servidores DNS centralizados no podrán resolver el FQDN de la API de AKS hasta que estén conectados con la zona privada de DNS creada para el clúster de AKS. Cada AKS tiene una zona privada de DNS única, ya que se antepone un GUID aleatorio al nombre de la zona. Por lo tanto, para cada nuevo clúster de AKS, su zona DNS privada correspondiente debe estar conectada a la red virtual en la que se encuentran los servidores DNS centrales.

Todas las redes virtuales deben configurarse para usar estos servidores DNS centrales para la resolución de nombres. Sin embargo, si la red virtual de AKS está configurada para usar servidores DNS centrales y estos no están conectados todavía a la zona DNS privada, los nodos de AKS no podrán resolver el FQDN de la API de Kubernetes y se producirá un error en la creación del clúster de AKS. La red virtual de AKS debe estar configurada para usar los servidores DNS centrales solo después de la creación del clúster.

Una vez creado el clúster, se crea la conexión entre la zona privada de DNS y la red virtual donde se implementan los servidores DNS centrales. La red virtual de AKS también se ha configurado para usar los servidores DNS centrales en la suscripción de conectividad y el acceso de administrador a la API de Kubernetes de AKS seguirá este flujo:

Diagrama que muestra una red para un clúster privado.

Nota:

En las imágenes de este artículo se refleja el diseño con el modelo tradicional de conectividad en estrella tipo hub-and-spoke. Las zonas de aterrizaje de escala empresarial pueden optar por el modelo de conectividad de Virtual WAN, en el que los servidores DNS centrales estarán en una red virtual de servicios compartidos conectada a un concentrador de Virtual WAN.

  1. El administrador resuelve el FQDN de la API de Kubernetes. Los servidores DNS locales reenvían la solicitud a los servidores autoritativos: las resoluciones DNS en Azure. Estos servidores reenvían la solicitud al servidor de Azure DNS (168.63.129.16), que obtendrá la dirección IP de la zona DNS privada de Azure.
  2. Después de resolver la dirección IP, el tráfico a la API de Kubernetes se redirige desde el entorno local a la puerta de enlace de ExpressRoute o VPN en Azure, en función del modelo de conectividad.
  3. El punto de conexión privado habrá introducido una ruta /32 en la red virtual del centro de conectividad. Las puertas de enlace de ExpressRoute y VPN envían el tráfico directamente al punto de conexión privado de la API de Kubernetes implementado en la red virtual de AKS.

Tráfico de los usuarios de la aplicación al clúster

Los controladores de entrada se pueden usar para exponer las aplicaciones que se ejecutan en los clústeres de AKS.

  • Los controladores de entrada proporcionan enrutamiento en el nivel de la aplicación a costa de un ligero aumento de la complejidad.
  • Los controladores de entrada pueden incorporar la funcionalidad de Web Application Firewall (WAF).
  • Los controladores de entrada pueden ejecutarse fuera del clúster y dentro de este:
    • Un controlador de entrada fuera del clúster descarga el proceso (como el enrutamiento de tráfico HTTP o la terminación TLS) a otro servicio fuera de AKS, como el complemento de controlador de entrada de Azure Application Gateway (AGIC).
    • Una solución en clúster consume recursos de clúster de AKS para proceso (como el enrutamiento de tráfico HTTP o la terminación TLS). Los controladores de entrada en clúster pueden ofrecer un costo más bajo, pero requieren una cuidadosa planeación y mantenimiento de recursos.
  • El complemento básico de enrutamiento de aplicaciones HTTP es fácil de usar, pero tiene algunas restricciones, como se documenta en Enrutamiento de aplicación HTTP.

Los controladores de entrada pueden exponer aplicaciones y API con una dirección IP pública o privada.

  • La configuración debe alinearse con el diseño de filtrado de salida para evitar el enrutamiento asimétrico. Los UDR pueden provocar enrutamiento asimétrico (potencialmente), pero no necesariamente. Application Gateway puede aplicar SNAT en el tráfico, lo que significa que el tráfico devuelto vuelve al nodo de Application Gateway y no a la ruta UDR si UDR solo está configurado para el tráfico de Internet.
  • Si se requiere terminación TLS, se debe tener en cuenta la administración de los certificados TLS.

El tráfico de la aplicación puede proceder de un entorno local o de la red pública de Internet. En la imagen siguiente se describe un ejemplo en el que se configura una instancia de Azure Application Gateway para invertir las conexiones de proxy a los clústeres tanto desde el entorno local como desde la red pública de Internet.

Diagrama que muestra el tráfico de red relacionado con las aplicaciones.

El tráfico desde el entorno local sigue el flujo de las llamadas azules numeradas en el diagrama anterior.

  1. El cliente resuelve el FQDN asignado a la aplicación, ya sea mediante los servidores DNS implementados en la suscripción de conectividad o los servidores DNS locales.
  2. Después de resolver el FQDN de la aplicación en una dirección IP (la dirección IP privada de la puerta de enlace de aplicación), el tráfico se redirige mediante una puerta de enlace de ExpressRoute o VPN.
  3. El enrutamiento de la subred de puerta de enlace está configurado para enviar la solicitud al firewall de aplicaciones web.
  4. El firewall de aplicaciones web envía solicitudes válidas a la carga de trabajo que se ejecuta en el clúster de AKS.

La instancia de Azure Application Gateway de este ejemplo se puede implementar en la misma suscripción que el clúster de AKS, ya que su configuración está estrechamente relacionada con las cargas de trabajo implementadas en AKS y, por tanto, la administra el mismo equipo de aplicaciones. El acceso desde Internet sigue el flujo de las llamadas verdes numeradas en el diagrama anterior.

  1. Los clientes de la red pública de Internet resuelven el nombre DNS de la aplicación mediante Azure Traffic Manager. Como alternativa, se pueden usar otras tecnologías globales de equilibrio de carga como Azure Front Door.
  2. El FQDN público de la aplicación se resolverá mediante Traffic Manager en la dirección IP pública de la puerta de enlace de aplicaciones, a la que los clientes acceden a través de la red pública de Internet.
  3. La puerta de enlace de aplicación tiene acceso a la carga de trabajo implementada en AKS.

Nota:

Estos flujos solo son válidos para las aplicaciones web. Las aplicaciones que no son web están fuera del ámbito de este artículo y se pueden exponer mediante Azure Firewall en la red virtual del concentrador o el concentrador virtual seguro si se usa el modelo de conectividad de Virtual WAN.

Como alternativa, se puede hacer que los flujos de tráfico para aplicaciones basadas en web pasen tanto por Azure Firewall en la suscripción de conectividad como en WAF en la red virtual de AKS. Este enfoque tiene la ventaja de ofrecer más protección, como el uso del Filtrado basado en inteligencia sobre amenazas de Azure Firewall para anular el tráfico de direcciones IP malintencionadas conocidas de Internet. Sin embargo, también tiene algunas desventajas. Por ejemplo, la pérdida de la dirección IP del cliente original y la coordinación adicional necesaria entre el firewall y los equipos de la aplicación cuando se exponen las aplicaciones. Esto se debe a que se necesitarán reglas de traducción de direcciones de red de destino (DNAT) en Azure Firewall.

Tráfico de los pods de AKS a los servicios de back-end

Es posible que los pods que se ejecutan dentro del clúster de AKS necesiten tener acceso a servicios de back-end, como Azure Storage, Azure SQL Database o Azure Cosmos DB NoSQL. Se pueden usar puntos de conexión de servicio de red virtual y Private Link para proteger la conectividad con estos servicios administrados de Azure.

Si usa puntos de conexión privados de Azure para el tráfico de back-end, la resolución DNS de los servicios de Azure se puede realizar mediante zonas de DNS privado de Azure. Puesto que los solucionadores de DNS para todo el entorno se encuentran en la red virtual del concentrador (o en la red virtual de servicios compartidos si se usa el modelo de conectividad de Virtual WAN), estas zonas privadas deben crearse en la suscripción de conectividad. Para crear el registro A necesario para resolver el FQDN del servicio privado, puede asociar la zona DNS privada (en la suscripción de conectividad) con el punto de conexión privado (en la suscripción de la aplicación). Esta operación requiere determinados privilegios en esas suscripciones.

Es posible crear los registros A manualmente, pero la asociación de la zona DNS privada con el punto de conexión privado genera una configuración menos propensa a errores.

La conectividad de back-end de los pods de AKS con los servicios de PaaS de Azure expuestos mediante puntos de conexión privados sigue esta secuencia:

Tráfico de back-end

  1. Los pods de AKS resuelven el FQDN de la plataforma como servicio (PaaS) de Azure mediante los servidores DNS centrales de la suscripción de conectividad, que se definen como servidores DNS personalizados en la red virtual de AKS.
  2. La dirección IP resuelta es la dirección IP privada de los puntos de conexión privados, a los que se accede directamente desde los pods de AKS.

El tráfico entre los pods de AKS y los puntos de conexión privados de forma predeterminada no pasará por Azure Firewall en la red virtual del concentrador (o el concentrador virtual seguro si se usa Virtual WAN), incluso si el clúster de AKS está configurado para el filtrado de salida con Azure Firewall. La razón es que el punto de conexión privado crea una ruta /32 en las subredes de la red virtual de la aplicación donde se implementa AKS.

Recomendaciones de diseño

  • Si la directiva de seguridad especifica que se debe tener una API de Kubernetes con una dirección IP privada (en lugar de una pública), implemente un clúster de AKS privado.
    • Use zonas DNS privadas personalizadas al crear un clúster privado, en lugar de permitir que el proceso de creación use una zona DNS privada del sistema.
  • Use Azure Container Networking Interface (CNI) como modelo de red, a menos que tenga un intervalo limitado de direcciones IP que se pueden asignar al clúster de AKS.
  • Use Azure DDoS Protection para proteger la red virtual usada para el clúster de AKS, a menos que use Azure Firewall o WAF en una suscripción centralizada.
  • Use la configuración de DNS vinculada a la configuración de red general con Azure Virtual WAN o la arquitectura en estrella tipo hub-and-spoke, zonas de Azure DNS y su propia infraestructura de DNS.
  • Use Private Link para proteger las conexiones de red y use la conectividad basada en IP privada con otros servicios de Azure administrados que admitan Private Link, como Azure Storage, Azure Container Registry, Azure SQL Database y Azure Key Vault.
  • Use un controlador de entrada para proporcionar seguridad y enrutamiento HTTP avanzado y ofrecer un único punto de conexión para las aplicaciones.
  • Todas las aplicaciones web configuradas para usar una entrada deben usar el cifrado TLS y no permitir el acceso a través de HTTP sin cifrar. Esta directiva ya se aplica si la suscripción incluye las directivas recomendadas en las Directivas incluidas en las implementaciones de referencia de aterrizaje de escala empresarial.
  • De forma opcional, para conservar los recursos de proceso y almacenamiento del clúster de AKS, use un controlador de entrada fuera del clúster.
    • Use el complemento de controlador de entrada de Azure Application Gateway (AGIC), que es un servicio de Azure administrado por este.
    • Con AGIC, puede implementar una instancia dedicada de Azure Application Gateway para cada clúster de AKS y no compartir la misma en varios clústeres de AKS.
    • Si no hay restricciones operativas o de recursos, o bien AGIC no proporciona las características necesarias, use una solución de controlador de entrada en clúster como NGINX, Traefik o cualquier otra solución compatible con Kubernetes.
  • En el caso de las aplicaciones web orientadas a Internet y las internas críticas para la seguridad, use el firewall de aplicaciones web con el controlador de entrada.
  • Si la directiva de seguridad obliga a inspeccionar todo el tráfico de salida de Internet generado en el clúster de AKS, proteja el tráfico de red de salida mediante Azure Firewall o una aplicación virtual de red de terceros (NVA) implementada en la red virtual del concentrador (administrada). Para obtener más información, consulte Limitar el tráfico de salida. El UDR de tipo de salida de AKS requiere asociar una tabla de rutas a la subred del nodo de AKS, por lo que no se puede usar actualmente con la inserción de rutas dinámicas compatible con Azure Virtual WAN o Azure Route Server.
  • En el caso de los clústeres no privados, use intervalos IP autorizados.
  • Use el nivel estándar en lugar del nivel básico de Azure Load Balancer.
  • Al diseñar un clúster de Kubernetes en Azure, una de las consideraciones clave es seleccionar el modelo de red adecuado para sus requisitos específicos. Azure Kubernetes Service (AKS) ofrece tres modelos de red diferentes: Kubenet, Azure CNI y la superposición de Azure CNI. Para tomar una decisión informada, es esencial comprender las funcionalidades y características de cada modelo.

Para una comparación de características entre los tres modelos de red en AKS; Kubenet, Azure CNI y Azure CNI Overlay, consulte Comparación de modelos de red en AKS.