Compartir a través de

Introducción a las redes de CNI de Azure Kubernetes Service (AKS)

  • Artículo

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.

Diagrama que muestra dos nodos con tres pods cada uno que ejecutan una red de superposición. El tráfico de los pods a los puntos de conexión fuera del clúster se enruta mediante NAT.

Azure Kubernetes Service proporciona los siguientes complementos de CNI para las redes superpuestas:

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.

Diagrama que muestra dos nodos con tres pods cada uno que se ejecutan en un modelo de red plana.

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:

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/16 ni 192.0.2.0/24 para 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/action
    • Microsoft.Authorization/roleAssignments/write
    • Microsoft.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