Conceptos de redes de aplicaciones en Azure Kubernetes Service (AKS)
En un enfoque de microservicios basado en contenedores para desarrollar aplicaciones, los componentes de la aplicación funcionan juntos para procesar sus tareas. Kubernetes proporciona varios recursos que permiten esta cooperación:
- Puede conectarse a aplicaciones y exponer estas de forma interna o externa.
- Puede equilibrar la carga de sus aplicaciones para compilar aplicaciones de alta disponibilidad.
- Para mayor seguridad, puede restringir el flujo de tráfico entre los pods y los nodos.
- Para aplicaciones más complejas, puede configurar el tráfico de entrada para la terminación SSL/TLS o el enrutamiento de varios componentes.
En este artículo se presentan los conceptos básicos que proporcionan redes para sus aplicaciones en AKS:
Conceptos básicos de redes de Kubernetes
Kubernetes emplea una capa de red virtual para administrar el acceso dentro y entre las aplicaciones o sus componentes:
Nodos y red virtual de Kubernetes: los nodos de Kubernetes están conectados a una red virtual. Esta configuración permite que los pods (unidades básicas de implementación en Kubernetes) tengan conectividad entrante y saliente.
Componente kube-proxy: kube-proxy se ejecuta en cada nodo y es responsable de proporcionar las características de red necesarias.
Con respecto a las funcionalidades específicas de Kubernetes:
- Equilibrador de carga: puede usar un equilibrador de carga para distribuir el tráfico de red uniformemente entre varios recursos.
- Controladores de entrada: facilitan el enrutamiento de capa 7, que es esencial para dirigir el tráfico de la aplicación.
- Control del tráfico de salida: Kubernetes permite administrar y controlar el tráfico saliente de los nodos del clúster.
- Directivas de red: estas directivas permiten establecer medidas de seguridad y el filtrado del tráfico de red en los pods.
En el contexto de la plataforma Azure:
- Azure simplifica las redes virtuales para clústeres de AKS (Azure Kubernetes Service).
- La creación de un equilibrador de carga de Kubernetes en Azure configura simultáneamente el recurso del equilibrador de carga de Azure correspondiente.
- A medida que abre puertos de red a los pods, Azure configura automáticamente las reglas necesarias de grupo de seguridad de red.
- Azure también puede administrar configuraciones DNS externas para el enrutamiento de aplicaciones HTTP a medida que se establecen nuevas rutas de entrada.
Redes virtuales de Azure
En AKS, puede implementar un clúster que use uno de los siguientes modelos de red:
Redes de Kubenet
Los recursos de red normalmente se crean y configuran cuando se implementa el clúster de AKS.
Redes de Azure Container Networking Interface (CNI)
el clúster de AKS está conectado a configuraciones y recursos de red virtual existentes.
Red (básica) de kubenet
La opción de red de kubenet es la configuración predeterminada para la creación del clúster de AKS. Con kubenet:
- los nodos obtienen una dirección IP de una subred de la red virtual de Azure.
- Los pods reciben una dirección IP de un espacio de direcciones lógicamente distinto a la subred de red virtual de Azure de los nodos.
- A continuación, se configura la traducción de direcciones de red (NAT) para que los pods puedan acceder a los recursos en la red virtual de Azure.
- La dirección IP de origen del tráfico se traduce a la dirección IP principal del nodo.
Los nodos usan el complemento kubenet de Kubernetes. Puede dejar que la plataforma de Azure cree y configure las redes virtuales por usted o puede implementar el clúster de AKS en una subred de red virtual existente.
Solo los nodos reciben una dirección IP enrutable. Los pods usan NAT para comunicarse con otros recursos fuera del clúster de AKS. Este enfoque reduce el número de direcciones IP que se deben reservar en el espacio de red para su uso por parte de los pods.
Nota:
Aunque kubenet es la opción de red predeterminada para que un clúster de AKS cree una red virtual y una subred, no se recomienda para las implementaciones de producción. Para la mayoría de las implementaciones de producción, debe planear y usar las redes de Azure CNI debido a sus características de escalabilidad y rendimiento superiores.
Para más información, consulte el artículo de Configuración de la red de kubenet para un clúster de AKS.
Redes (avanzadas) de Azure CNI
Con Azure CNI, cada pod obtiene una dirección IP de la subred y se puede acceder a ella directamente. Estas direcciones IP deben planearse de antemano y deben ser únicas en el espacio de red. Cada nodo tiene un parámetro de configuración para el número máximo de pods que admite. Luego, el número equivalente de direcciones IP por nodo se reserva por adelantado. Este enfoque puede llevar al agotamiento de las direcciones IP o a la necesidad de volver a generar los clústeres en una subred de mayor tamaño, a medida que crecen las exigencias de la aplicación, por lo que es importante su planeamiento correcto. Para evitar estos desafíos de planificación, es posible habilitar la característica Redes Azure CNI para la asignación dinámica de direcciones IP y compatibilidad de subred mejorada.
Nota:
Debido a las limitaciones de Kubernetes, el nombre del grupo de recursos, el nombre de la red virtual y el nombre de la subred deben tener 63 caracteres o menos.
A diferencia de kubenet, el tráfico hacia los puntos de conexión de la misma red virtual no se traduce (NAT) a la dirección IP principal del nodo. La dirección de origen para el tráfico dentro de la red virtual es la dirección IP del pod. El tráfico externo a la red virtual sigue traduciendo las direcciones de red a la dirección IP principal del nodo.
Los nodos usan el complemento Azure CNI de Kubernetes.
Para más información, consulte el artículo de Configuración de Azure CNI para un clúster de AKS.
Redes Azure CNI Overlay
Superposición de Azure CNI representa una evolución de Azure CNI, que aborda los desafíos de escalabilidad y planificación que surgen de la asignación de direcciones IP de VNet a pods. La superposición de Azure CNI asigna direcciones IP de CIDR privadas a los pods. Las direcciones IP privadas son independientes de la red virtual y se pueden reutilizar en varios clústeres. La superposición de Azure CNI puede escalarse más allá del límite de 400 nodos aplicado en clústeres de Kubenet. La superposición de Azure CNI es la opción recomendada para la mayoría de los clústeres.
Uso de Azure CNI con tecnología de Cilium
Azure CNI Powered by Cilium usa Cilium para proporcionar redes de alto rendimiento, observabilidad y aplicación de directivas de red. Se integra de forma nativa con la superposición de Azure CNI para la administración escalable de direcciones IP (IPAM).
Además, Cilium aplica las directivas de red de forma predeterminada, sin necesidad de un motor de directivas de red independiente. Azure CNI Powered by Cilium puede escalarse más allá de los límites de 250 nodos o 20 000 pods de Azure Network Policy Manager con programas eBPF y una estructura de objetos de API más eficaz.
Azure CNI Powered by Cilium es la opción recomendada para los clústeres que requieren la aplicación de directivas de red.
Traiga su propia instancia de CNI
Es posible instalar en AKS una CNI que no sea de Microsoft mediante la característica Traiga su propia CNI.
Comparación de modelos de red
Kubenet y Azure CNI proporcionan conectividad de red para los clústeres de AKS. Sin embargo, cada uno tiene sus ventajas y sus desventajas. En general, se aplican las siguientes consideraciones:
kubenet
- Conserva el espacio de direcciones IP.
- Usa equilibradores de carga internos o externos de Kubernetes para llegar a los pods desde fuera del clúster.
- Administre y mantenga las rutas definidas por el usuario (UDR) de manera manual.
- 400 nodos por clúster como máximo.
Azure CNI
- Los pods obtienen conectividad de red virtual completa y se pueden alcanzar directamente a través de su dirección IP privada desde redes conectadas.
- Requiere más espacio de direcciones IP.
| Modelo de red | Cuándo se usa |
|---|---|
| Kubenet | • La conversación del espacio de direcciones IP es una prioridad. • Configuración simple. • Menos de 400 nodos por clúster. • Los equilibradores de carga internos o externos de Kubernetes son suficientes para llegar a los pods desde fuera del clúster. • La administración y el mantenimiento manual de las rutas definidas por el usuario son aceptables. |
| Azure CNI | • Se requiere conectividad de red virtual completa para pods. • Se necesitan características avanzadas de AKS (como nodos virtuales). • Hay suficiente espacio de direcciones IP disponible. • Se necesita la conectividad de pod a pod y de pod a máquina virtual. • Los recursos externos necesitan llegar directamente a los pods. • Se requieren directivas de red de AKS. |
| Superposición de Azure CNI | • La escasez de direcciones IP es un problema. • El escalado vertical hasta 1,000 nodos y 250 pods por nodo es suficiente. • El salto adicional para la conectividad de pods es aceptable. • Configuración de red más sencilla. • Se pueden cumplir los requisitos de salida de AKS. |
Existen las siguientes diferencias de comportamiento entre kubenet y Azure CNI:
| Capacidad | Kubenet | CNI de Azure | Superposición de Azure CNI | Uso de Azure CNI con tecnología de Cilium |
|---|---|---|---|---|
| Implementación del clúster en la red virtual existente o en una nueva | Se admite, las UDR se aplican manualmente | Compatible | Admitido | Compatible |
| Conectividad entre pods | Compatible | Admitido | Admitido | Compatible |
| Conectividad entre la máquina virtual y el pod; con la máquina virtual en la misma red virtual | Funciona cuando lo inicia el pod | Funciona en ambas direcciones | Funciona cuando lo inicia el pod | Funciona cuando lo inicia el pod |
| Conectividad entre la máquina virtual y el pod; con la máquina virtual en una red virtual del mismo nivel | Funciona cuando lo inicia el pod | Funciona en ambas direcciones | Funciona cuando lo inicia el pod | Funciona cuando lo inicia el pod |
| Acceso local mediante VPN o ExpressRoute | Funciona cuando lo inicia el pod | Funciona en ambas direcciones | Funciona cuando lo inicia el pod | Funciona cuando lo inicia el pod |
| Acceso a los recursos protegidos por puntos de conexión de servicio | Compatible | Admitido | Compatible | |
| Expone los servicios de Kubernetes mediante un servicio de equilibrador de carga, App Gateway o un controlador de entrada | Compatible | Admitido | Compatible | Mismas limitaciones al usar el modo superpuesto |
| Compatibilidad con grupos de nodos de Windows | No compatible | Compatible | Compatible | Solo está disponible para Linux y no para Windows. |
| Azure DNS y zonas privadas predeterminadas | Compatible | Admitido | Compatible |
Para más información sobre Azure CNI y kubenet y para ayudar a determinar qué opción es mejor para usted, consulte Configuración de redes de Azure CNI en AKS y Uso de redes kubenet en AKS.
Ámbito de compatibilidad entre los modelos de red
Sin importar qué modelo de red use, kubenet y Azure CNI pueden implementarse de una de las siguientes maneras:
- La plataforma Azure puede crear y configurar automáticamente los recursos de red virtual al crear un clúster de AKS.
- Puede crear y configurar los recursos de red virtual manualmente y conectarse a ellos al crear el clúster de AKS.
Aunque se admiten funcionalidades como puntos de conexión de servicio o UDR tanto con kubenet como con Azure CNI, las directivas de compatibilidad para AKS definen los cambios que se pueden realizar. Por ejemplo:
- Si crea manualmente los recursos de red virtual para un clúster de AKS, tendrá soporte técnico para configurar sus propios puntos de conexión de servicio o UDR.
- Si la plataforma de Azure crea automáticamente los recursos de red virtual para el clúster de AKS, no puede cambiar manualmente esos recursos administrados de AKS para configurar sus propios UDR o puntos de conexión de servicio.
Controladores de entrada
Cuando se crea un servicio del tipo LoadBalancer, también se crea un recurso subyacente de equilibrador de carga de Azure. El equilibrador de carga está configurado para distribuir el tráfico a los pods en su servicio en un puerto determinado.
LoadBalancer solo funciona en la capa 4. En la capa 4, el servicio no conoce las aplicaciones reales y no puede realizar ninguna otra consideración de enrutamiento.
Los controladores de entrada funcionan en la capa 7 y pueden usar reglas más inteligentes para distribuir el tráfico de las aplicaciones. Normalmente un controlador de entrada enruta el tráfico HTTP a diferentes aplicaciones según la URL de entrada.
Comparación de las opciones de entrada
En la tabla siguiente se enumeran las diferencias de características entre las distintas opciones del controlador de entrada:
| Característica | Complemento de enrutamiento de aplicaciones | Application Gateway para contenedores | Malla de servicio de Azure/malla de servicio basada en Istio |
|---|---|---|---|
| Controlador de entrada/puerta de enlace | Controlador de entrada NGINX | Azure Application Gateway for Containers | Puerta de enlace de entrada de Istio |
| API | API de entrada | API de entrada y API de puerta de enlace | API de puerta de enlace |
| Hospedar aplicaciones de WPF | En el clúster | Hospedado en Azure | En el clúster |
| Escalado | Escalado automático | Escalado automático | Escalado automático |
| Equilibrio de carga | Interno o externo | Externos | Interno o externo |
| Terminación de SSL | En el clúster | Sí: Descarga y SSL de E2E | En el clúster |
| mTLS | N/D | Sí al back-end | N/D |
| Dirección IP estática | N/D | FQDN | N/D |
| Certificados SSL almacenados de Azure Key Vault | Sí | Sí | N/D |
| Integración de Azure DNS para la administración de zonas DNS | Sí | Sí | N/D |
En la tabla siguiente se enumeran los distintos escenarios en los que puede usar cada controlador de entrada:
| Opción de entrada | Cuándo se deben usar |
|---|---|
| NGINX administrado: complemento de enrutamiento de aplicaciones | • Controladores de entrada NGINX hospedados en clústeres, personalizables y escalables. • Funcionalidades básicas de equilibrio de carga y enrutamiento. • Configuración del equilibrador de carga interno y externo. • Configuración de dirección IP pública. • Integración con Azure Key Vault para la administración de certificados. • Integración con zonas de Azure DNS para la administración de zonas públicas y privadas. • Admite la API de entrada. |
| Puerta de enlace de aplicaciones para contenedores | • Puerta de enlace de entrada hospedada en Azure. • Estrategias de implementación flexibles administradas por el controlador o traiga su propia puerta de enlace de aplicaciones para contenedores. • Características avanzadas de administración del tráfico, como reintentos automáticos, resistencia de zona de disponibilidad, autenticación mutua (mTLS) en el destino de back-end, división de tráfico/round robin ponderado y escalado automático. • Integración con Azure Key Vault para la administración de certificados. • Integración con zonas de Azure DNS para la administración de zonas públicas y privadas. • Admite las API de entrada y puerta de enlace. |
| Puerta de enlace de entrada de Istio | • Basado en Envoy, cuando se usa con Istio en una malla de servicio. • Características avanzadas de administración del tráfico, como la limitación de velocidad y la interrupción del circuito. • Compatibilidad con mTLS • Admite la API de puerta de enlace. |
Creación de un recurso de entrada
El complemento de enrutamiento de aplicaciones es la manera recomendada para configurar un controlador de entrada en AKS. El complemento de enrutamiento de aplicaciones es un controlador de entrada totalmente administrado para Azure Kubernetes Service (AKS) que proporciona las siguientes características:
Configuración sencilla de controladores de entrada NGINX administrados basados en controlador de entrada NGINX de Kubernetes.
Integración con Azure DNS para la administración de zonas públicas y privadas.
Terminación SSL con certificados almacenados en Azure Key Vault.
Para obtener más información sobre el complemento de enrutamiento de aplicaciones, consulte Entrada administrada de NGINX con el complemento de enrutamiento de aplicaciones.
Conservación de la dirección IP de origen de cliente
Configure el controlador de entrada para conservar la dirección IP de origen de cliente en las solicitudes a los contenedores en el clúster de AKS. Cuando el controlador de entrada enruta la solicitud de un cliente a un contenedor del clúster de AKS, la dirección IP de origen de la solicitud no está disponible para el contenedor de destino. Al habilitar la conservación de la dirección IP de origen de cliente, la dirección IP de origen para el cliente está disponible en el encabezado de solicitud en X-Forwarded-For.
Si usa la conservación de la dirección IP de origen de cliente en el controlador de entrada, no puede usar TLS de paso a través. La conservación de la dirección IP de origen de cliente y TLS de paso a través pueden usarse con otros servicios, como de tipo LoadBalancer.
Para más información sobre la conservación de la dirección IP de origen del cliente, consulte Funcionamiento de la conservación de la dirección IP de origen del cliente para los servicios LoadBalancer en AKS.
Control del tráfico de salida
Los clústeres de AKS se implementan en una red virtual y tienen dependencias de salida de los servicios fuera de esa red virtual. Estas dependencias de salida se definen casi en su totalidad con nombres de dominio completos (FQDN). De forma predeterminada, los clústeres de AKS tienen acceso de salida a Internet sin restricciones, lo que permite que los nodos y servicios que ejecute accedan a los recursos externos necesarios. Si lo desea, puede restringir el tráfico de salida.
Para obtener más información, vea Control del tráfico de salida de los nodos de clúster en AKS.
Grupos de seguridad de red
Un grupo de seguridad de red filtra el tráfico de las máquinas virtuales, como los nodos de AKS. Al crear servicios, como LoadBalancer, la plataforma Azure configura automáticamente las reglas de grupo de seguridad de red necesarias.
No necesita configurar manualmente las reglas del grupo de seguridad de red para filtrar el tráfico de los pods en un clúster de AKS. Puede definir los puertos necesarios y el reenvío como parte de los manifiestos de servicio de Kubernetes y permitir que la plataforma Azure cree o actualice las reglas correspondientes.
También puede usar directivas de red para aplicar automáticamente las reglas de filtro de tráfico a los pods.
Para más información, consulte Cómo filtran el tráfico de red los grupos de seguridad de red.
Directivas de red
De forma predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin limitaciones. Para mejorar la seguridad, defina reglas que controlen el flujo de tráfico, como:
- Las aplicaciones back-end solo se exponen a los servicios de front-end necesarios.
- Los componentes de base de datos solo son accesibles para las capas de aplicación que se conectan a ellos.
La directiva de red es una característica de Kubernetes disponible en AKS que permite controlar el flujo de tráfico entre pods. Según la configuración como las etiquetas asignadas, el espacio de nombres o el puerto de tráfico, puede permitir o denegar el tráfico al pod. Aunque los grupos de seguridad de red son mejores para los nodos de AKS, las directivas de red son una manera más adecuada y nativa de la nube para controlar el flujo de tráfico de los pods. Como los pods se crean dinámicamente en un clúster de AKS, se pueden aplicar automáticamente las directivas de red necesarias.
Para más información, consulte Protección del tráfico entre pods mediante directivas de red en Azure Kubernetes Service (AKS).
Pasos siguientes
Para empezar a trabajar con las redes de AKS, cree y configure un clúster de AKS con sus propios intervalos de direcciones IP mediante kubenet o CNI de Azure.
Para los procedimientos recomendados asociados, consulte Procedimientos recomendados con la conectividad de red y la seguridad en Azure Kubernetes Service (AKS).
Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte los artículos siguientes: