Kürzlich habe ich an PaaS-Inhalten gearbeitet und bin gerade mit Kubernetes in Kontakt gekommen, was Netzwerkabdeckung beinhaltet, also die Kommunikation zwischen Cross-Host-Containern. So sind eine Reihe von Open-Source-Komponenten entstanden, wie Flanell, Calico, Weave usw. Hier sind hauptsächlich Calico und Fannel.
Flanellprinzip
Flannel, ein von CoreOS entwickeltes Projekt, ist wahrscheinlich das direkteste und beliebteste CNI-Plugin. Es ist eines der reifsten Beispiele für Netzwerkarchitektur in Container-Orchestrierungssystemen und ist darauf ausgelegt, bessere Inter-Container- und Interhost-Netzwerke zu ermöglichen. Mit dem Aufstieg des CNI-Konzepts ist das Flannel CNI-Plugin eine frühe Einführung.
Flannel ist im Vergleich zu anderen Optionen relativ einfach zu installieren und zu konfigurieren. Es ist als einzelnes binäres FlannelD verpackt, und viele gängige Kubernetes-Cluster-Bereitstellungstools sowie viele Kubernetes-Distributionen können Flannel standardmäßig installieren. Flannel kann den bestehenden etcd-Cluster des Kubernetes-Clusters nutzen, um seine Zustandsinformationen über die API zu speichern, sodass kein dedizierter Datenspeicher erforderlich ist.
Flannel konfiguriert ein IPv4-Overlay-Netzwerk der Schicht 3. Es schafft ein großes internes Netzwerk, das jeden Knoten im Cluster abdeckt. In diesem Overlay-Netzwerk verfügt jeder Knoten über ein Subnetz, das zur internen Zuweisung von IP-Adressen verwendet wird. Beim Konfigurieren eines Pods weist die Docker-Bridge-Schnittstelle auf jedem Knoten jedem neuen Container eine Adresse zu. Pods im selben Host können über Docker-Bridges kommunizieren, während Pods auf verschiedenen Hosts Flanneld verwenden, um ihren Datenverkehr in UDP-Paketen zu kapseln und so zum entsprechenden Ziel weitergeleitet zu werden.
Flannel hat verschiedene Arten von Backends, die für Kapselung und Routing verwendet werden können. Der Standard- und empfohlene Ansatz ist VXLAN, da VXLAN besser funktioniert und weniger manuelle Eingriffe erfordert.
Calico-Architektur
Der Calico umfasst folgende wichtige Komponenten: Felix, etcd, BGP Client und BGP Route Reflector. Im Folgenden finden Sie die Erklärungen zu jeder dieser Komponenten.
Felix: Hauptsächlich verantwortlich für Routing-Konfiguration, ACLS-Regelkonfiguration und -Auslieferung, es existiert auf jedem Knoten.
etcd: Verteilter Key-Value-Speicher, der hauptsächlich für die Konsistenz der Netzwerkmetadaten verantwortlich ist und die Genauigkeit des Calico-Netzwerkzustands gewährleistet, kann mit Kubernetes geteilt werden;
BGPClient (BIRD) ist hauptsächlich dafür verantwortlich, die von Felix an den Kernel geschriebenen Routing-Informationen im aktuellen Calico-Netzwerk zu verteilen, um die Effektivität der Kommunikation zwischen den Arbeitslasten sicherzustellen.
BGPRoute Reflector (BIRD) wird in groß angelegten Implementierungen eingesetzt, wobei der Mesh-Modus zur Verbindung aller Knoten aufgegeben wird und ein oder mehrere BGPRoute-Reflektoren zur zentralen Routing und Verteilung verwendet werden.
Das Kalikoprinzip
Wie im folgenden Diagramm dargestellt, wird der Prozess vom Quellcontainer über den Quellhost, über das Routing des Rechenzentrums und schließlich zum Zielhost dargestellt und schließlich dem Zielcontainer zugewiesen.
Kontrast
Aus dem oben genannten Prinzip lässt sich erkennen, dass Flannel Paketentpackungsoperationen auf Basis von Routing-Weiterleitung durchführt, was CPU-Rechenressourcen verschwendet. Die folgende Grafik vergleicht die Leistung verschiedener Online-Open-Source-Netzwerkkomponenten. Man sieht, dass die Leistung von Calico und Host in Bezug auf Bandbreite und Netzwerklatenz ähnlich ist.
|
Veröffentlicht am 09.11.2020 11:23:01
|
|
|
|
