SUR CETTE PAGE
Modèles de déploiement
RÉSUMÉ
Cloud-Native Contrail Networking (CN2) est disponible à la fois en tant que plate-forme de mise en réseau intégrée dans un seul cluster Kubernetes et en tant que plate-forme de mise en réseau centralisée pour plusieurs clusters Kubernetes distribués en amont. Dans les deux cas, Contrail fonctionne comme un composant intégré de votre infrastructure en observant l’endroit où les charges de travail sont instanciées et en connectant ces charges de travail aux réseaux overlay appropriés.
Déploiement d’un seul cluster
Cloud-Native Contrail Networking (CN2) est disponible en tant que plate-forme de mise en réseau intégrée dans un seul cluster Kubernetes. Il surveille l’endroit où les charges de travail sont instanciées et connecte ces charges de travail aux réseaux overlay appropriés.
Dans un déploiement en cluster unique (Figure 1), le contrôleur Contrail se trouve dans le plan de contrôle Kubernetes et fournit la configuration du réseau et les plans de contrôle du réseau pour le cluster hôte. Les composants du plan de données Contrail sont installés dans tous les nœuds et fournissent la fonction d’envoi et de réception de paquets pour les charges de travail.
d’un seul cluster
Déploiement multi-cluster
Dans un déploiement multi-cluster (Figure 2), le contrôleur Contrail réside dans son propre cluster Kubernetes et fournit la mise en réseau à d’autres clusters. Le cluster Kubernetes dans lequel réside le contrôleur Contrail est appelé cluster central. Les clusters Kubernetes qui hébergent les charges de travail sont appelés clusters de charges de travail distribués.
multi-cluster
De cette manière, la centralisation de la fonction réseau facilite non seulement la configuration et la gestion, mais aussi l’application de politiques et de sécurité réseau cohérentes.
La figure 3 fournit plus de détails sur cette configuration. Le contrôleur Contrail se trouve dans le plan de contrôle Kubernetes du cluster central et contient un kubemanager pour chaque cluster de charges de travail qu’il dessert. Il n’y a généralement pas de nœuds de travail dans le cluster central. Au lieu de cela, les charges de travail résident dans les nœuds de travail des clusters de charges de travail distribués. Le plug-in Contrail CNI et le vRouter se trouvent dans les nœuds de travail des clusters de charge de travail. Le plan de contrôle Kubernetes des clusters de charges de travail ne contient pas de composants de contrôleur Contrail.
Le contrôleur Contrail multi-cluster se distingue du contrôleur Contrail en cluster unique de deux manières principales :
- Le contrôleur Contrail multi-cluster dispose d’un pod Contrail-k8s-kubemanager instancié pour chaque cluster de charges de travail distribué. Dans le cadre de la procédure de connexion d’un cluster de charges de travail distribué au cluster central, vous créez et attribuez explicitement un déploiement contrail-k8s-kubemanager qui surveille les modifications apportées aux ressources qui affectent le cluster de charges de travail assigné.
- Le contrôleur Contrail multi-cluster utilise la technologie de surveillance multi-cluster pour détecter les changements dans les clusters de charges de travail distribués.
La fonction du pod contrail-k8s-kubemanager multi-cluster est identique à son homologue à cluster unique. Il surveille les modifications apportées aux ressources Kubernetes régulières qui affectent le cluster assigné et agit en conséquence.
Tous les autres composants Contrail d’un déploiement multi-cluster se comportent de la même manière que dans un déploiement en cluster unique. Le plan de contrôle du réseau, par exemple, communique avec les composants du plan de données à l’aide de XMPP, en dehors des canaux REST standard de Kubernetes. De ce fait, le plan de contrôle du réseau est indifférent à la question de savoir si les composants du plan de données avec 10000 se trouvent dans le même cluster ou dans différents clusters. La seule exigence est que les composants du plan de données soient accessibles.