Criterios de decisión
La elección del mejor complemento de red para su caso de uso depende de sus criterios. Cada opción tiene ventajas y desventajas, y se deben tener en cuenta los compromisos al realizar una selección.
Criterios de decisión de alto nivel
Agotamiento de IPv4
Kubenet está diseñado pensando en la conservación del espacio de direcciones IP. Azure CNI proporciona pods con conectividad de red completa, pero requiere más espacio de direcciones IP y planificación. El agotamiento de IPv4 se produce cuando el número de direcciones alcanza el límite y detiene los nodos de una operación de escalado o actualización. Durante el agotamiento, la aplicación demanda demasiados recursos y no puede continuar.
Kubenet permite que los nodos reciban direcciones IP definidas, sin necesidad de reservar un gran número de direcciones IP por adelantado para todos los pods posibles que se podrían ejecutar en el clúster. Con kubenet, se preocupa menos por el agotamiento de IPv4 y controla un intervalo pequeño de direcciones IP para la compatibilidad de un clúster grande y las demandas de la aplicación.
Los siguientes cálculos básicos comparan el espacio de direcciones en los modelos de red:
- kubenet: un intervalo sencillo de direcciones IP de /24 puede admitir hasta 251 nodos en el clúster (cada subred de red virtual de Azure reserva las tres primeras direcciones IP para operaciones de administración). Este número de nodos podría admitir hasta 27 610 pods (con una capacidad máxima predeterminada de 110 pods por nodo con kubenet).
- Azure CNI: ese mismo intervalo de subred básico de /24 solo podría admitir un máximo de 8 nodos en el clúster. Este número de nodos podría admitir solo hasta 240 pods (con una capacidad máxima predeterminada de 30 pods por nodo con Azure CNI).
Tamaño del clúster
Kubenet tiene un máximo de 400 nodos por clúster, mientras que Azure CNI depende de cómo se configura el complemento.
Conectividad
En Kubenet debe administrar y mantener las rutas definidas por el usuario (UDR) de manera manual. Para alcanzar los pods desde fuera del clúster se debe usar un equilibrador de carga. Con 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.
Compatibilidad con varios clústeres
En Kubenet varios clústeres no pueden usar la misma subred de nodo. Con Azure CNI esta configuración sí es posible.
Latencia
En comparación con Azure CNI, Kubenet necesita un salto adicional, lo que puede introducir alguna latencia menor. Las cargas de trabajo sensibles a la latencia deberían implementarse en clústeres mediante Azure CNI.
Funcionalidades adicionales
Azure CNI admite topologías de red complejas con redes de Azure CNI, como nodos virtuales o directivas de red de Azure.
Estas funcionalidades adicionales son:
- Subred por grupo de nodos
- Asignación dinámica de direcciones IP
- Asignaciones de subred de nodo y de pod
Diferencias de comportamiento entre Kubenet y Azure CNI
Además de los criterios de alto nivel, hay muchas diferencias de comportamiento y discrepancias en la compatibilidad con características:
| 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 | |
| Acceso a los recursos expuestos por puntos de conexión privados | Compatible | 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 |
| Azure DNS y zonas privadas predeterminadas | Compatible | Admitido | Compatible | |
| Compatibilidad con grupos de nodos de Windows | No compatible | Compatible | Compatible | Solo disponible para Linux |
| Nodos virtuales | No compatible | Compatible | No compatible | |
| Varios clústeres que comparten una subred | No compatible | Compatible | Compatible | |
| Directivas de red admitidas | Calico | Directivas de red de Calico y Azure | Calico, Azure Network Policies, Cilium | Ciliuim |