Panoramaanalyse der Datenverbindungen des Alibaba Cloud-Containernetzwerks (7): Terway DataPath V2 (Terway≥1.8.0)

Das Open-Source-Community-Team China machte seine erste Live-Übertragung und erzählte im Namen des Teilens die Geschichte hinter der Open-Source-Community China.“

Autor: Yu Kai

Vorwort

In den letzten Jahren ist der Trend zur Cloud-nativen Unternehmensinfrastruktur immer stärker geworden. Vom ersten IaaS bis hin zu den aktuellen Microservices sind die Anforderungen der Kunden an granulare Verfeinerung und Beobachtbarkeit gestiegen. Um der höheren Leistung und Dichte der Kunden gerecht zu werden, haben sich Containernetzwerke mit hoher Geschwindigkeit entwickelt und weiterentwickelt, was zwangsläufig extrem hohe Schwellenwerte und Herausforderungen für die Sichtbarkeit cloudnativer Netzwerke für Kunden mit sich bringt. Um die Beobachtbarkeit von Cloud-nativen Netzwerken zu verbessern und es Kunden und Studierenden an vorderster Front zu erleichtern, die Lesbarkeit von Geschäftsverbindungen zu verbessern, haben ACK Industrial Research und AES gemeinsam eine Reihe von Beobachtbarkeiten auf Datenebene für Cloud-native Netzwerke entwickelt, um Kunden und Studenten zu helfen In den vorderen und hinteren Linien verstehen wir das Cloud-Native-Netzwerkarchitektursystem, vereinfachen die Beobachtbarkeitsschwelle des Cloud-Native-Netzwerks, optimieren die Erfahrung von Kundenbetrieb und -wartung sowie After-Sales-Studenten bei der Bewältigung schwieriger Probleme und verbessern die Stabilität der Verbindungen von das cloudnative Netzwerk.

Aus der Vogelperspektive des Containernetzwerks lässt sich das gesamte Containernetzwerk in drei Teile unterteilen: Pod-Netzwerksegment, Service-Netzwerksegment und Knotennetzwerksegment. Diese drei Netzwerke müssen eine Verbindung und Zugangskontrolle erreichen. Was sind also die technischen Prinzipien für die Implementierung? Was ist der gesamte Link und welche Einschränkungen gibt es? Was ist der Unterschied zwischen Flannel und Terway? Wie hoch ist die Netzwerkleistung in verschiedenen Modi? Diese erfordern, dass Kunden vor dem Bau von Containern Entscheidungen auf der Grundlage ihrer eigenen Geschäftsszenarien treffen. Nach Abschluss der Konstruktion kann die relevante Architektur nicht geändert werden, sodass Kunden die Eigenschaften jeder Architektur vollständig verstehen müssen. Die folgende Abbildung ist beispielsweise ein vereinfachtes Diagramm. Das Pod-Netzwerk muss die Netzwerkinteroperabilität und -steuerung zwischen Pods im selben ECS realisieren und auch den Zugriff zwischen Pods in verschiedenen ECS realisieren. Das Backend von Pods, die auf SVC zugreifen, kann sich im selben ECS befinden Andere ECSs: In diesen verschiedenen Modi ist der Datenverbindungsweiterleitungsmodus unterschiedlich, und auch die Leistungsergebnisse auf der Geschäftsseite sind unterschiedlich.

Dieser Artikel ist der siebte Teil von [Panoramaanalyse von Container-Netzwerk-Datenverbindungen]. Er stellt hauptsächlich die Weiterleitungsverbindungen von Datenebenenverbindungen im Kubernetes Terway DataPath V2-Modus vor. Zunächst können wir die Weiterleitungsverbindungen der Datenebene in verschiedenen Szenarien identifizieren Kunden können die Datenoberflächenleistung der Zugriffsverbindung in verschiedenen Szenarien durch ein detailliertes Verständnis der Weiterleitungsverbindung, des Kundenbetriebs und der Alibaba Cloud weiter optimieren Die Schüler können erkennen, was passiert, und manuell beobachten, welche Verbindungspunkte bereitgestellt werden, um die Richtung und Ursache des Problems genauer zu ermitteln.

Serie 1: Panoramaanalyse der Datenverbindungen des Alibaba Cloud-Containernetzwerks (1) – Flannel

Serie 2: Panoramaanalyse der Datenverbindungen des Alibaba Cloud-Containernetzwerks (2) – Terway ENI

Serie Drei: Panoramaanalyse der Datenverbindungen des Alibaba Cloud Container Network (3) – Terway ENIIP

Serie 4: Panoramaanalyse der Datenverbindungen des Alibaba Cloud-Containernetzwerks (4) – Terway IPVLAN+EBPF

Serie 5: Panoramaanalyse der Datenverbindungen des Alibaba Cloud-Containernetzwerks (5) – Terway ENI-Trunking

Serie 6: Panoramaanalyse der Datenverbindungen des Alibaba Cloud-Containernetzwerks (6) – ASM Istio

Design der Terway DataPath V2-Musterarchitektur

Die elastische Netzwerkschnittstelle (ENI) unterstützt die Funktion der Konfiguration mehrerer Hilfs-IPs. Einer einzelnen elastischen Netzwerkschnittstelle (ENI) können gemäß den Instanzspezifikationen 6 bis 20 Hilfs-IPs zugewiesen werden zum Container, wodurch die Effizienz der Pod-Bereitstellung erheblich verbessert wird. In Bezug auf die Netzwerkkonnektivität unterstützt Terway derzeit zwei Lösungen: Veth-Pair-Policy-Routing und IPVLAN. Die Community hat die IPVLAN-Unterstützung jedoch nach Cilium v1.12 aufgegeben [ 1] , um die Konsistenz der Datenebene zu vereinheitlichen ACK Die Entwicklung steht im Einklang mit der Community, was die Integration von Cloud-nativen Funktionen erleichtert und die Differenzierung verringert. Ab v1.8.0 unterstützt Terway keine IPvlan-Tunnelbeschleunigung mehr, sondern verwendet DataPath V2, um die Datenebene zu vereinheitlichen.

Das vom Pod verwendete CIDR-Netzwerksegment ist dasselbe Netzwerksegment wie das CIDR des Knotens.

Es gibt eine Netzwerkkarte eth0 im Pod, und die IP von eth0 ist die IP des Pods. Die MAC-Adresse dieser Netzwerkkarte stimmt nicht mit der MAC-Adresse von ENI auf der Konsole überein Netzwerkkarten auf ECS, was bedeutet, dass die an ENI angeschlossene Netzwerkkarte nicht direkt mit dem Netzwerk-Namespace des Pods verbunden ist.

Im Pod gibt es nur eine Standardroute, die auf eth0 zeigt. Das bedeutet, dass eth0 der einheitliche Ein- und Ausgang ist, wenn der Pod auf ein beliebiges Adresssegment zugreift.

Gleichzeitig gibt es in ECS mehrere Ethx-Netzwerkkarten, was bedeutet, dass die an ENI angeschlossene Netzwerkkarte nicht direkt im Netzwerk-Namespace des Pods bereitgestellt wird.

Über OS Linux Routing kann erreicht werden, dass der gesamte für die Pod-IP bestimmte Datenverkehr an die dem Pod entsprechende virtuelle Calixx-Karte weitergeleitet wird. Daher hat der Netzwerk-Namespace von ECS OS und Pod eine vollständige Konfiguration für eingehende und ausgehende Links eingerichtet.

Für die Implementierung von ENI Multi-IP ähnelt dies dem Prinzip der ACK-Container-Netzwerkdatenverbindung (Terway ENIIP) [ 2] . Terway Pod wird auf jedem Knoten über Daemonset bereitgestellt. Mit dem Zuordnungsbefehl terway-cli können Sie die Anzahl der angeschlossenen ENIs auf dem Knoten, die MAC-Adresse und die IP auf jedem ENI abrufen.

Damit der Pod auf SVC zugreifen kann, verwendet der Container verschiedene Methoden, um die Anforderung an die ECS-Schicht weiterzuleiten, auf der sich der Pod befindet, und das Netfilter-Modul in ECS implementiert die Auflösung der SVC-IP. Da die Datenverbindung jedoch vom Netzwerk-Namespace des Pods auf den Netzwerk-Namespace des Betriebssystems des ECS umgestellt werden muss und den Kernel-Protokollstapel in der Mitte durchläuft, kommt es zwangsläufig zu Leistungseinbußen Streben Sie nach hoher Parallelität und hoher Leistung, ist es möglicherweise nicht möglich, die Kundenanforderungen vollständig zu erfüllen. Im Vergleich zum IPVLAN-Modus, bei dem eBPF innerhalb des Pods für die SVC-Adressübersetzung bereitgestellt wird, lauscht eBPF im DataPath V2-Modus auf der Calixxx-Netzwerkkarte jedes Pods, um den Pod- und Pod-Zugriff zu beschleunigen und die Adresse des Pod-Zugriffs an den zu übertragen Für die Verbindungsbeschleunigung kann sich der Modellvergleich auf die Verwendung des Terway-Netzwerk-Plugins [ 3] beziehen .

BPF-Routing

Nach dem 5.10-Kernel hat Cilium die eBPF-Host-Routing-Funktion und zwei neue Umleitungsmethoden hinzugefügt, bpf_redirect_peer und bpf_redirect_neigh.

bpf_redirect_peer

Das Datenpaket wird direkt an die Schnittstelle eth0 im Veth-Paar-Pod gesendet, ohne die lxc-Schnittstelle des Hosts zu durchlaufen, sodass das Datenpaket weniger einmal in die CPU-Backlog-Warteschlange gelangt und eine bessere Weiterleitungsleistung erzielt.
bpf_redirect_neigh

Wird verwendet, um die SRC- und DST-Mac-Adressen des Pod-Ausgangsdatenverkehrs einzugeben. Der Datenverkehr muss nicht die Routenprotokoll-Stack-Verarbeitung des Kernels durchlaufen.

Daher kann das Gesamtmodell von Terway DataPath V2 wie folgt zusammengefasst werden:

Derzeit unterstützen Kernel niedrigerer Versionen (niedriger als 4.2) keine eBPF-Beschleunigung. Aliyun2 kann teilweise Beschleunigungsfunktionen erhalten, und Aliyun3 kann vollständige Beschleunigungsfunktionen erhalten.
Knoten müssen den Protokollstapel des Hosts durchlaufen, um auf Pods zuzugreifen. Der Pod-zu-Pod-Zugriff und der Pod-Zugriff auf SVC erfolgen nicht über den Protokollstapel des Hosts.
Wenn im DataPath V2-Modus ein Pod auf die SVC-IP zugreift, wird die SVC-IP durch eBPF auf der Veth-Paar-Calixxx-Netzwerkkarte des Pods in die IP eines SVC-Backend-Pods konvertiert, und dann umgeht die Datenverbindung den Host-Protokollstapel. Mit anderen Worten: Die SVC-IP wird nur im Veth-Paar des Quell-Pods erfasst, aber weder der Ziel-Pod noch das ECS, in dem sich der Ziel-Pod befindet, werden erfasst.

Analyse der Containernetzwerk-Datenverbindung im Terway DataPath V2-Modus

Basierend auf den Eigenschaften des Containernetzwerks können die Netzwerkverbindungen im Terway-Datapathv2-Modus grob in zwei große SOP-Szenarien unterteilt werden: Bereitstellung externer Dienste mithilfe von Pod-IP und Bereitstellung externer Dienste mithilfe von SVC. Dies kann weiter in 11 verschiedene kleine SOP-Szenarien unterteilt werden . SOP-Szenario.

Nach dem Durchkämmen und Zusammenführen der Datenverbindungen dieser 15 Szenarien können diese Szenarien in die folgenden 8 typischen Szenarien zusammengefasst werden:

Greifen Sie über denselben Knoten auf die Pod-IP und den Pod zu
Zugriff auf Pod-IP, gegenseitiger Zugriff zwischen Pods auf demselben Knoten (Pods gehören zu derselben ENI)
Zugriff auf Pod-IP, gegenseitiger Zugriff zwischen Pods auf demselben Knoten (Pods gehören zu verschiedenen ENIs)
Zugriff auf Pod-IP, gegenseitiger Zugriff zwischen Pods zwischen verschiedenen Knoten
SVC-Cluster-IP/externe IP, auf die Pods im Cluster zugreifen, SVC-Backend-Pod und Client-Pod gehören zum gleichen ECS und ENI
SVC-Cluster-IP/externe IP, auf die Pods im Cluster zugreifen, SVC-Backend-Pod und Client-Pod gehören demselben ECS, aber unterschiedlichen ENI
Die SVC-Cluster-IP/externe IP, auf die die Pods im Cluster, der SVC-Backend-Pod und der Client-Pod zugreifen, gehören zu unterschiedlichen ECS
Greifen Sie von außerhalb des Clusters auf die externe SVC-IP zu

Szenario 1: Zugriff auf die Pod-IP, Zugriff auf den Pod vom selben Knoten (einschließlich Knotenzugriff auf die Backend-SVC-ClusterIP desselben Knotens)

Umfeld

nginx2-7ff4679659-xkpmm existiert auf dem Knoten xxx.10.0.1.219 mit der IP-Adresse 10.0.0.2.

Kernel-Routing

nginx2-7ff4679659-xkpmm, IP-Adresse 10.0.0.2, die PID des Containers auf dem Host ist 5630 und der Container-Netzwerk-Namespace verfügt über eine Standardroute, die auf den Container eth0 verweist.

Das entsprechende Veth-Paar des Containers eth0 in ECS OS ist cali10e985649a0. In ECS OS gibt es eine Route, die auf die Pod-IP zeigt, und der nächste Hop ist calixxx. Aus dem vorherigen Artikel können wir erkennen, dass die calixxx-Netzwerkkarte ein Paar ist veth1 in jedem Pod.

Mit dem folgenden Befehl können wir nginx2-7ff4679659-xkpmm erhalten. Die IP-Adresse 10.0.0.2 wird der eth2-Zubehörnetzwerkkarte von terway zugewiesen.

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- terway-cli-Zuordnung

Zusammenfassung

ECSs eth0 hat die von nginx2-7ff4679659-xkpmm zurückgegebenen Daten erfasst, die gesendeten Daten jedoch nicht.

ECSs eth1 hat auch die von nginx2-7ff4679659-xkpmm zurückgegebenen Daten erfasst, die gesendeten Daten jedoch nicht.

cali10e985649a0 kann gesendete und empfangene Pakete erfassen.

In der anschließenden Zusammenfassung werden keine Datenpaketbeobachtungen mehr angezeigt.

Datenverbindungsweiterleitungsdiagramm (Aliyun2 und Aliyun3):

Die gesamte Verbindung durchläuft den Netzwerkprotokollstapel von ECS und Pod.
Der gesamte Anforderungslink lautet: ECS OS -> calixxx -> ECS Pod eth0