Récemment, j’ai travaillé sur du contenu PaaS, et je viens tout juste de découvrir Kubernetes, qui implique la couverture réseau, c’est-à-dire la communication entre conteneurs inter-hôtes. Ainsi, une série de composants open source ont émergé, tels que la flanelle, le calicot, le tissage, etc. Ici, on trouve principalement des Calico et des Fannel.
Principe de flanelle
Flannel, un projet développé par CoreOS, est probablement le plugin CNI le plus direct et populaire. C’est l’un des exemples les plus matures d’architecture réseau dans les systèmes d’orchestration de conteneurs et il est conçu pour permettre une meilleure gestion du réseau interconteneurs et inter-hôtes. Avec l’essor du concept CNI, le plugin CNI en Flanelle est une des premières introductions.
La flanelle est relativement facile à installer et à configurer comparée à d’autres options. Il est présenté sous forme d’un seul binaire FlannelD, et de nombreux outils de déploiement de cluster Kubernetes courants ainsi que de nombreuses distributions Kubernetes peuvent installer Flannel par défaut. Flannel peut utiliser le cluster etcd existant du cluster Kubernetes pour stocker ses informations d’état via l’API, il ne nécessite donc pas de stockage de données dédié.
Flannel configure un réseau de superposition IPv4 de couche 3. Cela crée un vaste réseau interne qui couvre chaque nœud du cluster. Dans ce réseau Superposé, chaque nœud possède un sous-réseau utilisé pour assigner des adresses IP en interne. Lors de la configuration d’un pod, l’interface pont Docker sur chaque nœud attribue une adresse à chaque nouveau conteneur. Les pods du même hôte peuvent communiquer via des ponts Docker, tandis que les pods sur différents hôtes utilisent du flanneld pour encapsuler leur trafic en paquets UDP afin qu’ils puissent être acheminés vers la destination appropriée.
La flanelle propose plusieurs types de backends qui peuvent être utilisés pour l’encapsulation et le routage. L’approche par défaut et recommandée est d’utiliser VXLAN car VXLAN fonctionne mieux et nécessite moins d’intervention manuelle.
Architecture en calicot
Le calicot comprend les composants importants suivants : Felix, etcd, BGP Client et BGP Route Reflector. Voici les explications de chacun de ces éléments.
Felix : Principalement responsable de la configuration du routage, de la configuration des règles ACLS et de la livraison, elle existe sur chaque nœud.
etcd : Le stockage clé-valeur distribué, principalement responsable de la cohérence des métadonnées réseau, assurant la précision de l’état réseau Calico, peut être partagé avec Kubernetes ;
BGPClient (BIRD) est principalement responsable de la distribution des informations de routage écrites par Felix vers le noyau vers le réseau Calico actuel afin d’assurer l’efficacité de la communication entre les charges de travail.
Le réflecteur BGPRoute (BIRD) est utilisé dans les déploiements à grande échelle, abandonnant le mode maillage d’interconnexion de tous les nœuds, et utilisant un ou plusieurs réflecteurs BGPRoute pour compléter le routage et la distribution centralisés.
Le principe du calicot
Comme montré dans le diagramme suivant, le processus est représenté depuis le conteneur source via l’hôte source, via le routage du centre de données, puis enfin vers l’hôte de destination, puis enfin assigné au conteneur de destination.
Contraste
D’après ce principe, on peut voir que la flanelle effectue des opérations de décomposition de paquets sur la base du routage, ce qui gaspille des ressources de calcul CPU. Le graphique ci-dessous compare les performances de divers composants réseau open source trouvés en ligne. On peut constater qu’en termes de bande passante et de latence réseau, les performances de Calico et de l’hôte sont similaires.
|
Publié sur 09/11/2020 11:23:01
|
|
|
|
