Terway vs. Flannel - Container Service for Kubernetes - Centre de documentation Alibaba Cloud

ACK propose Terway pour une mise en réseau haute performance basée sur les ENI, et Flannel pour des clusters plus simples acheminés via le VPC.

Développé par Alibaba Cloud, Terway utilise des interfaces réseau élastiques (ENI) pour la mise en réseau des pods. Il offre des fonctionnalités telles que l'accélération réseau basée sur eBPF, NetworkPolicy, ainsi que des vSwitches et des groupes de sécurité au niveau des pods. Cette solution convient aux scénarios nécessitant un grand nombre de nœuds, des performances réseau élevées et une sécurité robuste, comme le calcul haute performance (HPC), le jeu vidéo et les microservices.
Flannel est un plug-in CNI open source. Dans ACK, il utilise le mode réseau VPC d'Alibaba Cloud et transfère les paquets directement via la table de routage du VPC. Cette option convient aux clusters de petite taille qui ont besoin d'une mise en réseau simplifiée sans contrôle granulaire du réseau des conteneurs.

Important

Installez un plug-in CNI lors de la création du cluster. Vous ne pourrez pas le modifier ultérieurement.
Avec Flannel, ALB Ingress ne peut transmettre les requêtes qu'aux services NodePort et LoadBalancer. Les services ClusterIP ne sont pas pris en charge.

Élément	Terway	Flannel
Performances réseau	Terway surpasse la version communautaire de Flannel en termes de TCP RR, UDP PPS, bande passante et latence. Remarque Les données de test sont des valeurs théoriques basées sur les instances ecs.ebmg5s.24xlarge et peuvent varier selon l'environnement. Consultez la communauté native Alibaba Cloud. Terway prend en charge le mode ENI exclusif, où chaque pod dispose d'une ENI dédiée pour des performances réseau supérieures. Adapté aux scénarios tels que le HPC, le jeu vidéo et les microservices. Terway prend en charge le mode ENI partagé avec l'accélération DataPath V2, une évolution de la solution IPVLAN. Pour le trafic intra-cluster, DataPath V2 utilise eBPF pour contourner la pile réseau du nœud et accélérer l'accès. Remarque En mode DataPath V2, les données conntrack des conteneurs sont stockées dans une carte eBPF. Comme conntrack sous Linux, il utilise un algorithme LRU et évince les enregistrements les plus anciens lorsque la capacité est atteinte. Optimisez les configurations conntrack pour éviter de dépasser les limites de connexion.
Quota de nœuds	Le nombre maximal de nœuds dans un cluster Terway dépend de la limite de capacité du cluster. Cluster ACK Pro : prend en charge 5 000 nœuds par défaut et jusqu'à 50 000 nœuds au maximum. Cluster ACK Basic : 10 nœuds.	Le nombre maximal de nœuds dans un cluster Flannel dépend des entrées de la table de routage du VPC et de la limite de capacité du cluster. La table de routage du VPC prend en charge 200 entrées par défaut, et jusqu'à 1 000 après augmentation du quota. Chaque nœud utilisant une entrée, un cluster Flannel prend en charge jusqu'à 1 000 nœuds. Cluster ACK Pro : prend en charge 200 nœuds par défaut et jusqu'à 1 000 nœuds au maximum. Cluster ACK Basic : 10 nœuds.
Pods par nœud	Les pods utilisent les ENI du nœud. Le nombre maximal de pods par nœud dépend du type d'instance et de métriques telles que le nombre d'ENIs et le nombre d'adresses IPv4 privées par ENI. Par exemple, pour une instance Compute-optimized c7 (ecs.c7.4xlarge, 16 vCPU, 32 Go) : En mode ENI partagé, un nœud peut exécuter un maximum de 210 pods. En mode ENI exclusif, un nœud peut exécuter un maximum de 7 pods. Bien que les instances Compute-optimized c6 et Compute-optimized c7 disposent du même nombre d'ENI, une instance Compute-optimized c6 peut exécuter jusqu'à 140 pods en mode ENI partagé car elle possède moins d'adresses IPv4 privées par ENI. Consultez la rubrique Calcul du quota de pods par nœud.	Le nombre maximal de pods par nœud dépend du paramètre Number of Pods per Node et du masque de sous-réseau du Container CIDR Block. Par exemple, si le bloc CIDR des pods d'un cluster ACK Pro est 172.16.0.0/20, chaque nœud peut exécuter jusqu'à 256 pods et le cluster prend en charge jusqu'à 16 nœuds. Important Vous ne pouvez pas modifier le nombre maximal de nœuds dans un cluster Flannel après sa création.
Bloc CIDR des pods	Le bloc CIDR des pods est alloué à partir du bloc CIDR du VPC, ce qui consomme de nombreuses adresses IP du VPC. Prévoyez un VPC disposant d'adresses IP suffisantes. Le bloc CIDR des pods et le CIDR de service doivent être indépendants et ne pas se chevaucher. Vous ne pouvez pas modifier les blocs CIDR. Vous pouvez étendre le bloc CIDR des pods en ajoutant des vSwitches.	Le bloc CIDR des pods est indépendant du bloc CIDR du VPC. Flannel attribue à chaque nœud un sous-réseau issu de ce bloc pour l'allocation des IP des pods. Le bloc CIDR des pods, le CIDR des nœuds (bloc CIDR du VPC) et le CIDR de service doivent être indépendants et ne pas se chevaucher. Vous ne pouvez pas modifier les blocs CIDR. Vous ne pouvez pas étendre le bloc CIDR des pods.
Sécurité réseau	Configurez des vSwitches et des groupes de sécurité indépendants pour les pods. Prend en charge Kubernetes NetworkPolicy pour le contrôle d'accès au niveau des conteneurs.	Vous ne pouvez pas configurer de vSwitches et de groupes de sécurité indépendants pour les pods. Ne prend pas en charge NetworkPolicy.
Double pile IPv4/IPv6	Prend en charge la mise en réseau à double pile.	Ne prend pas en charge la mise en réseau à double pile. Remarque ACK utilise un plug-in Flannel modifié, qui n'est pas toujours synchronisé avec la communauté open source. Consultez les notes de version de Flannel.
IP de pod statique	Prend en charge les adresses IP statiques pour les pods.	Ne prend pas en charge les adresses IP statiques pour les pods.
Persistance de session	Les backends d'équilibrage de charge se connectant directement aux pods, la persistance de session garantit la disponibilité du service même si les pods backend changent.	Les backends d'équilibrage de charge utilisent NodePort pour se connecter aux pods. Si un pod backend est remplacé, le trafic est interrompu, ce qui peut entraîner des nouvelles tentatives de service.
Communication multi-clusters	Les pods de différents clusters peuvent communiquer si les ports requis sont ouverts dans les groupes de sécurité.	Non pris en charge.
Conservation de l'IP source du pod	Lorsqu'un pod accède à d'autres endpoints VPC, son IP d'origine est conservée comme adresse IP source, ce qui simplifie l'audit.	Lorsqu'un pod accède à d'autres endpoints VPC, son adresse IP source est remplacée par l'IP du nœud.

Étapes suivantes

Vous ne pouvez pas modifier les blocs CIDR des pods, des services et des nœuds après la création du cluster. Leur taille détermine les limites de ressources et affecte la capacité de déploiement. Des blocs CIDR distincts permettent l'isolation des ressources au niveau du réseau pour le contrôle d'accès et le routage personnalisé. Planifiez les réseaux pour les clusters gérés ACK avant de créer un cluster.
Après la planification du réseau :
- Pour utiliser Terway, installez le plug-in CNI Terway lors de la création du cluster.
- Pour utiliser Flannel, installez le plug-in CNI Flannel lors de la création du cluster.

Références

Pour les limites de nœuds de cluster et les augmentations de quota, consultez la rubrique Quotas et limites.
Consultez la rubrique FAQ sur le réseau des conteneurs.