Introducción a las redes de CNI de Azure Kubernetes Service (AKS)
Kubernetes usa complementos de Contenedor de interfaz de red (CNI) para administrar redes en clústeres de Kubernetes. Los CNI son responsables de asignar direcciones IP a pods, enrutamiento de red entre pods, enrutamiento de Kubernetes Service, etc.
AKS proporciona varios complementos de CNI que puede usar en los clústeres en función de los requisitos de red.
Modelos de redes en AKS
Elegir un complemento de CNI para el clúster de AKS depende en gran medida del modelo de red que mejor se adapte a sus necesidades. Cada modelo tiene sus propias ventajas y desventajas que debe tener en cuenta al planear el clúster de AKS.
AKS usa dos modelos de red principales: red superpuesta y red plana.
Ambos modelos de red tienen varias opciones de complemento de CNI compatibles. Las principales diferencias entre los modelos son cómo se asignan las direcciones IP del pod y cómo sale el tráfico del clúster.
Redes superpuestas
Las redes superpuestas son el modelo de red más común que se usa en Kubernetes. En las redes superpuestas, los pods reciben una dirección IP de un CIDR privado y separado lógicamente de la subred de red virtual de Azure donde están implementados los nodos de AKS. Esto permite una escalabilidad más sencilla y a menudo mejor que el modelo de red plana.
En las redes superpuestas, los pods pueden comunicarse entre sí directamente. El tráfico que sale del clúster es la Dirección de red de origen traducida (SNAT'd) a la dirección IP del nodo y el tráfico IP del pod entrante se enruta a través de algún servicio, como un equilibrador de carga. Esto significa que la dirección IP del pod está "oculta" detrás de la dirección IP del nodo. Este enfoque reduce el número de direcciones IP de red virtual necesarias para los clústeres.
Azure Kubernetes Service proporciona los siguientes complementos de CNI para las redes superpuestas:
- Superposición de Azure CNI, el complemento de CNI recomendado para la mayoría de los escenarios.
- kubenet, el modelo de superposición heredado de CNI.
Redes planas
A diferencia de una red superpuesta, un modelo de red plana en AKS asigna direcciones IP a pods desde una subred desde la misma red virtual de Azure que los nodos de AKS. Esto significa que el tráfico que sale de los clústeres no es SNAT'd y la dirección IP del pod se expone directamente al destino. Esto puede ser útil para algunos escenarios, como cuando necesite exponer direcciones IP de pod a servicios externos.
Azure Kubernetes Service proporciona dos complementos de CNI para redes planas. Este artículo no profundiza en cada opción de complemento. Para obtener más información, consulte la documentación vinculada:
- Subred de pod de CNI de Azure, el complemento de CNI recomendado para escenarios de redes planas.
- Subred de nodo de Azure CNI, solo recomienda usar normalmente un modelo de red plana heredado de CNI si necesita una red virtual administrada para el clúster.
Elección de un CNI
Al elegir un CNI, hay varios factores que se deben tener en cuenta. Cada modelo de red tiene sus propias ventajas y desventajas, y la mejor opción para el clúster dependerá de sus requisitos específicos.
Elección de un modelo de red
Los dos modelos de red principales de AKS son redes superpuestas y redes planas.
Redes superpuestas:
- Conserve el espacio de direcciones IP de red virtual mediante intervalos de CIDR separados lógicamente para pods.
- Compatibilidad máxima con la escala de clústeres.
- Administración sencilla de direcciones IP.
Redes planas:
- Los pods obtienen conectividad completa de red virtual y se pueden alcanzar directamente a través de su dirección IP privada desde redes conectadas.
- Requerir un espacio de direcciones IP de red virtual grande y no fragmentado.
Comparación de casos de uso
Al elegir un modelo de red, tenga en cuenta los casos de uso de cada complemento de CNI y el tipo de modelo de red que usa:
| Complemento de CNI | Modelo de redes | Resaltados de casos de uso |
|---|---|---|
| Superposición de Azure CNI | Overlay | - Mejor para la conservación de IP de red virtual - Número máximo de nodos admitidos por el servidor de API + 250 pods por nodo - Configuración más sencilla -Sin acceso directo al IP de pod externo |
| Subred de pod de Azure CNI | Plano | - Acceso directo a pods externos - Modos de uso eficaz de IP de red virtual o compatibilidad a gran escala de clústeres (versión preliminar) |
| Kubenet (heredado) | Overlay | - Prioriza la conservación de IP - Escala limitada - Administración manual de rutas |
| Subred de nodo de Azure CNI (heredado) | Plano | - Acceso directo a pods externos - Configuración más sencilla - Escala limitada - Uso ineficaz de direcciones IP de red virtual |
Comparación de características
También puede comparar las características de cada complemento de CNI. En la tabla siguiente se proporciona una comparación de alto nivel de las características admitidas por cada complemento de CNI:
| Característica | Superposición de Azure CNI | Subred de pod de Azure CNI | Subred de nodo de Azure CNI (heredado) | Kubenet |
|---|---|---|---|---|
| Implementación de un clúster en una red virtual existente o nueva | Compatible | Admitido | Compatible | Compatible: UDR manuales |
| Conectividad de pod-VM con máquina virtual en la misma red virtual o emparejada | Pod iniciado | Ambas maneras | Ambas maneras | Pod iniciado |
| Acceso local a través de VPN/ExpressRoute | Pod iniciado | Ambas maneras | Ambas maneras | Pod iniciado |
| Acceso a los puntos de conexión de servicio | Compatible | Admitido | Admitido | Compatible |
| Exposición de servicios mediante el equilibrador de carga | Compatible | Admitido | Admitido | Compatible |
| Exposición de servicios mediante App Gateway | Actualmente no se admite | Compatible | Admitido | Compatible |
| Exposición de servicios mediante el controlador de entrada | Compatible | Admitido | Admitido | Compatible |
| Grupos de nodos de Windows | Compatible | Admitido | Admitido | No compatible |
| Azure DNS y zonas privadas predeterminadas | Compatible | Admitido | Admitido | Compatible |
| Uso compartido de subred de red virtual entre varios clústeres | Compatible | Admitido | Admitido | No compatible |
Ámbito de compatibilidad entre los modelos de red
Según el CNI que use, los recursos de red virtual del clúster se pueden implementar de una de las maneras siguientes:
- La plataforma Azure puede crear y configurar automáticamente los recursos de red virtual al crear un clúster de AKS. como en Superposición de Azure CNI, subred de nodo de CNI de Azure y Kubenet.
- 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, las directivas de soporte técnico para AKS definen qué cambios puede 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.
Requisitos previos
Hay varios requisitos y consideraciones que debe tener en cuenta al planear la configuración de red para AKS:
- La red virtual del clúster AKS debe permitir la conectividad saliente de Internet.
- Los clústeres de AKS no pueden usar
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16ni192.0.2.0/24para el intervalo de direcciones del servicio de Kubernetes, el intervalo de direcciones de pod, o el intervalo de direcciones de la red virtual del clúster. - En escenarios de red virtual BYO, la identidad del clúster que usa el clúster de AKS debe tener al menos permisos de Colaborador de red en la subred de la red virtual. Si quiere definir un rol personalizado en lugar de usar el rol integrado de colaborador de red, se requieren los permisos siguientes:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(solo es necesario si va a definir sus propias subredes y CIDR)
- La subred asignada al grupo de nodos AKS no puede ser una subred delegada.
- AKS no aplica grupos de seguridad de red (NSG) a su subred y no modificará ninguno de los grupos de seguridad de red asociados a esa subred. Si proporciona su propia subred y agrega grupos de seguridad de red asociados a ella, debe asegurarse de que las reglas de seguridad de los NSG permiten el tráfico entre dentro del rango CIDR del nodo. Para más información, consulteGrupo de seguridad de red.
Pasos siguientes
Azure Kubernetes Service