CN2-Komponenten
Die CN2-Architektur besteht aus Pods, die die Funktionen der Netzwerkkonfigurationsebene und der Netzwerksteuerungsebene ausführen, und Pods, die die Funktionen der Netzwerkdatenebene ausführen.
-
Die Netzwerkkonfigurationsebene bezieht sich auf die Funktionen, mit denen CN2 seine Ressourcen verwalten und mit dem Rest der Kubernetes-Steuerungsebene interagieren kann.
-
Die Netzwerksteuerungsebene repräsentiert die SDN-Funktion von CN2 mit vollem Funktionsumfang. Es verwendet BGP zur Kommunikation mit anderen Controllern und XMPP zur Kommunikation mit den verteilten Data Plane-Komponenten auf den Worker-Knoten.
-
Die Datenebene des Netzwerks bezieht sich auf die Sende- und Empfangsfunktion des Pakets auf jedem Knoten, insbesondere auf den Arbeitsknoten, auf denen sich die Workloads befinden.
Die Pods, die die Funktionen der Konfiguration und Steuerungsebene ausführen, befinden sich auf Kubernetes-Steuerungsebenenknoten. Die Pods, die die Data Plane-Funktionen ausführen, befinden sich sowohl auf Kubernetes-Steuerebenenknoten als auch auf Kubernetes-Worker-Knoten.
Tabelle 1 beschreibt die wichtigsten CN2-Komponenten. Je nach Konfiguration kann es auch andere Komponenten (nicht angezeigt) geben, die Zusätzliche Funktionen wie Zertifikatsverwaltung und Statusüberwachung ausführen.
| Pod-Name | – Beschreibung | ||
|---|---|---|---|
| Konfigurationsebene1 | Contrail-k8s-apiserver | Steuerungsebenenknoten | Dieser Pod ist ein aggregierter API-Server, der der Einstiegspunkt für die Verwaltung aller Contrail-Ressourcen ist. Es ist beim regulären kube-apiserver als APIService registriert. Der normale kube-apiserver leitet alle netzwerkbezogenen Anfragen zur Bearbeitung an den contrail-k8s-apiserver weiter. Pro Kubernetes-Steuerungsebenenknoten gibt es einen Contrail-k8s-apiserver-Pod. |
| Contrail-k8s-Controller | Steuerungsebenenknoten | Dieser Pod führt die Steuerungsschleifenfunktion von Kubernetes aus, um Netzwerkressourcen zu versöhnen. Es überwacht ständig Netzwerkressourcen, um sicherzustellen, dass der tatsächliche Zustand einer Ressource dem beabsichtigten Zustand entspricht. Es gibt einen Contrail-k8s-Controller-Pod pro Kubernetes-Steuerungsebenenknoten. |
|
| Contrail-k8s-kubemanager | Steuerungsebenenknoten | Dieser Pod ist die Schnittstelle zwischen Kubernetes-Ressourcen und Contrail-Ressourcen. Es beobachtet den kube-apiserver auf Änderungen an regulären Kubernetes-Ressourcen wie Service und Namespace und handelt auf alle Änderungen, die sich auf die Netzwerkressourcen auswirken. In einer Einzelnen Cluster-Bereitstellung gibt es einen Contrail-k8s-kubemanager-Pod pro Kubernetes-Steuerungsebenenknoten. In einer Multi-Cluster-Bereitstellung gibt es zusätzlich einen Contrail-k8s-kubemanager-Pod für jeden verteilten Workload-Cluster. |
|
| Steuerungsebene1 | Contrail-Control | Steuerungsebenenknoten | Dieser Pod leitet die Konfiguration an die Worker-Knoten weiter und führt Routenlernen und -verteilung durch. Es beobachtet den kube-apiserver auf alles, was die Netzwerksteuerungsebene beeinflusst, und kommuniziert dann je nach Bedarf mit seinen BGP-Peers und/oder vRouter-Agenten (über XMPP). Pro Kubernetes-Steuerungsebenenknoten gibt es einen Contrail-Control-Pod. |
| Data Plane | Contrail-vrouter-Knoten | Mitarbeiterknoten | Dieser Pod enthält den vRouter-Agent und den vRouter selbst. Der vRouter-Agent handelt im Auftrag des lokalen vRouters, wenn er mit dem Contrail-Controller interagiert. Pro Knoten gibt es einen Agenten. Der Agent richtet XMPP-Sitzungen mit zwei Contrail-Controllern ein, um die folgenden Funktionen auszuführen:
Der vRouter bietet die Sende- und Empfangsfunktion von Paketen für die co-location Pods und Workloads. Es bietet die CNI-Plug-in-Funktionalität. |
| Contrail-vrouter-Masters | Steuerungsebenenknoten | Dieser Pod bietet die gleichen Funktionen wie der Contrail-vrouter-Knoten-Pod, befindet sich aber auf den Knoten der Steuerungsebene. | |
| 1 Die Komponenten der Netzwerkkonfigurationsebene und der Netzwerksteuerungsebene werden gemeinsam als Contrail-Controller bezeichnet. |
|||
Abbildung 1 zeigt diese Komponenten im Kontext eines Kubernetes-Clusters.
Zur Übersichtlichkeit und zur Reduzierung von Unordnungen zeigen die Abbildungen nicht die Data Plane-Pods auf dem Knoten mit dem Contrail-Controller.
Bei der Ausführung auf Upstream-Kubernetes speichert der Contrail-Controller standardmäßig alle CN2-Cluster-Daten in der Hauptdatenbank von Kubernetes etcd. Bei der Ausführung auf OpenShift speichert der Contrail-Controller alle CN2-Cluster-Daten in seiner eigenen Contrail etcd-Datenbank.
Der kube-apiserver ist der Einstiegspunkt für Kubernetes REST-API-Aufrufe für den Cluster. Sie leitet alle Netzwerkanfragen an den Contrail-k8s-apiserver, der den Einstiegspunkt für Contrail-API-Aufrufe darstellt. Der Contrail-k8s-apiserver übersetzt eingehende Netzwerkanfragen in REST-API-Aufrufe an die jeweiligen CN2-Objekte. In einigen Fällen können diese Aufrufe dazu führen, dass der Contrail-Controller auf einem oder mehreren Workerknoten XMPP-Nachrichten an den vRouter-Agent sendet oder BGP-Nachrichten (nicht angezeigt) an andere Control Plane Nodes oder externe Router sendet. Diese XMPP- und BGP-Nachrichten werden außerhalb der normalen Kubernetes Node-to-Node-Kommunikation gesendet.
Die Contrail-k8s-kubemanager -Komponenten (Cluster) sind nur in Multi-Cluster-Bereitstellungen vorhanden. Weitere Informationen zu den verschiedenen Bereitstellungstypen finden Sie unter Bereitstellungsmodelle.
Abbildung 2 zeigt einen Cluster mit mehreren Contrail-Controllern. Diese Controller befinden sich auf Den Knoten der Steuerungsebene. Die Kubernetes-Komponenten kommunizieren über REST miteinander. Die Contrail-Controller tauschen Routen unter Verwendung von iBGP untereinander aus, außerhalb der normalen Kubernetes REST-Schnittstelle. Aus Gründen der Redundanz stellen die vRouter-Agenten auf Worker-Knoten immer die XMPP-Kommunikation mit zwei Contrail-Controllern her.
