Critères de décision
Le choix du plug-in réseau le mieux adapté à votre cas d’usage dépend de vos critères de décision. Chaque option présente ses propres avantages, inconvénients et compromis à prendre en compte lors du choix.
Critères de décision généraux
Épuisement des adresses IPv4
kubenet est conçu dans un esprit de conservation de l’espace d’adressage IP. Azure CNI fournit des pods avec une connectivité réseau complète, mais nécessite davantage d’espace d’adressage IP et de planification. L’épuisement IPv4 est le moment où le nombre d’adresses atteint la limite et arrête les opérations de mise à l’échelle ou de mise à niveau au niveau des nœuds. Pendant l’épuisement, votre application exige trop de ressources et ne peut pas continuer.
kubenet permet aux nœuds de recevoir des adresses IP définies sans qu’il soit nécessaire de réserver un grand nombre d’adresses IP à l’avance pour tous les pods potentiels qui pourraient s’exécuter dans le cluster. Avec kubenet, vous vous inquiétez moins de l’épuisement IPv4 et gérez une petite plage d’adresses IP pour la prise en charge des clusters volumineux et les demandes d’application.
Les calculs de base suivants comparent l’espace d’adressage dans les modèles réseau :
- kubenet : une simple plage d’adresses IP /24 peut prendre en charge jusqu’à 251 nœuds dans le cluster (chaque sous-réseau de réseau virtuel Azure réserve les trois premières adresses IP pour les opérations de gestion). Ce nombre de nœuds peut prendre en charge jusqu’à 27 610 pods (avec un maximum par défaut de 110 pods par nœud avec kubenet).
- Azure CNI : cette même plage de sous-réseau /24 de base peut prendre en charge un maximum de 8 nœuds seulement dans le cluster. Ce nombre de nœuds peut prendre en charge jusqu’à 240 pods seulement (avec un maximum par défaut de 30 pods par nœud avec Azure CNI).
Taille du cluster
Kubenet a un maximum de 400 nœuds par cluster, tandis qu’Azure CNI dépend de la configuration du plug-in.
Connectivité
Dans kubenet, vous devez gérer et mettre à jour manuellement les routes définies par l’utilisateur (UDR). Pour atteindre les pods depuis l’extérieur du cluster, vous devez utiliser un équilibreur de charge. Avec Azure CNI, les pods bénéficient de la connectivité complète du réseau virtuel et sont directement accessibles via leur adresse IP privée depuis des réseaux connectés.
Prise en charge de plusieurs clusters
Dans kubenet, plusieurs clusters ne peuvent pas utiliser le même sous-réseau de nœuds. Avec Azure CNI, cette configuration est possible.
Latence
Par rapport à Azure CNI, kubenet a besoin d’un tronçon supplémentaire, ce qui peut entraîner une latence mineure. Les charges de travail sensibles à la latence doivent être déployées sur des clusters utilisant Azure CNI.
Fonctionnalités supplémentaires
Azure CNI prend en charge des topologies réseau complexes avec la mise en réseau Azure CNI, comme les nœuds virtuels ou les stratégies réseau Azure.
Ces fonctionnalités supplémentaires sont les suivantes :
- Sous-réseau par pool de nœuds
- Allocation dynamique des IP
- Allocations de sous-réseaux de nœuds et de pods
Différences de comportement entre kubenet et Azure CNI
En plus des critères généraux, il existe de nombreuses différences de comportement et des divergences dans la prise en charge des fonctionnalités :
| Fonctionnalité | Kubenet | Azure CNI | Superposition Azure CNI | Azure CNI avec Cilium |
|---|---|---|---|---|
| Déployer un cluster dans un réseau virtuel nouveau ou existant | Pris en charge : UDR appliqués manuellement | Prise en charge | Prise en charge | Prise en charge |
| Connectivité pod-pod | Prise en charge | Prise en charge | Prise en charge | Prise en charge |
| Connectivité pod-machine virtuelle ; la machine virtuelle se trouve dans le même réseau virtuel | S’applique si initié par le pod | S’applique dans les deux sens | S’applique si initié par le pod | S’applique si initié par le pod |
| Connectivité pod-machine virtuelle ; la machine virtuelle se trouve dans un réseau virtuel homologué | S’applique si initié par le pod | S’applique dans les deux sens | S’applique si initié par le pod | S’applique si initié par le pod |
| Accès local à l’aide de VPN ou d’Express Route | S’applique si initié par le pod | S’applique dans les deux sens | S’applique si initié par le pod | S’applique si initié par le pod |
| Accès à des ressources sécurisées par des points de terminaison de service | Prise en charge | Prise en charge | Prise en charge | |
| Accès aux ressources exposées par des points de terminaison privés | Prise en charge | Prise en charge | ||
| Exposer des services Kubernetes à l’aide d’un service d’équilibreur de charge, App Gateway ou d’un contrôleur d’entrée | Prise en charge | Prise en charge | Prise en charge | Les limitations sont identiques lors de l’utilisation du mode Superposition |
| Azure DNS et zones privées par défaut | Prise en charge | Prise en charge | Prise en charge | |
| Prise en charge des pools de nœuds Windows | Non pris en charge | Prise en charge | Prise en charge | Uniquement disponible pour Linux |
| Nœuds virtuels | Non pris en charge | Prise en charge | Non pris en charge | |
| Plusieurs clusters partageant un même sous-réseau | Non pris en charge | Prise en charge | Prise en charge | |
| Stratégies réseau prises en charge | Calico | Stratégies réseau Calico et Azure | Calico, stratégies réseau Azure, Cilium | Cilium |