Die Verkehrsverwaltung auf Kernel-Ebene von Kmesh verbessert die Leistung der Dienstweiterleitung um mehr als 50 %

[Live-Übertragungsvorschau] Wie weit müssen wir gehen, um Oracle zu ersetzen?

Dieser Artikel wurde von der Huawei Cloud Community geteilt „ DTSE Tech Talk | Ausgabe 49: Verkehrsmanagement auf Kmesh-Kernel-Ebene, Service-Weiterleitungsleistung um mehr als 50 % verbessert!“ ", Autor: Huawei Cloud Community Selection.

Der Latenz-Overhead der Datenebene kann die SLA-Anforderungen der Anwendung nicht erfüllen? Das Verkehrsmanagement-Framework Kmesh auf Kernel-Ebene bringt architektonische Innovation und neue Erfahrungen in das Service-Grid! In der Live-Übertragung mit dem Thema „Kmesh: Architectural Innovation Brings New Performance Experience to Service Grids“ diskutierten Huawei Cloud Native DTSE Technology Evangelist und Huawei Operating System Senior Engineer Wu Changye die Entwicklung der Service Governance, die Herausforderungen, mit denen Service Grids konfrontiert sind, und Das Kmesh-Projekt: Analyse und technische Fähigkeiten, Einführung und Demo-Demonstration sowie andere Aspekte der Analyse. Kmesh verlagert L4- und L7-Verkehrsverwaltungsfunktionen auf den Kernel. Kmesh implementiert ein Cloud-natives Verkehrsverwaltungs-Framework auf Kernel-Ebene, das die Leistung der Dienstweiterleitung um 50 % verbessert. bzw. 60 % und reduziert das Grundrauschen . Reduzieren Sie den Overhead um 70 % und bauen Sie eine leistungsstarke Service-Grid-Architekturlösung für Benutzer auf!

Die Service-Governance wird schrittweise vom Geschäft entkoppelt und auf die Infrastruktur verlagert

Die Entwicklung der Service-Governance hat drei Generationen durchlaufen. In der frühen Form der ersten Generation sind „Service-Governance-Funktionen in den Geschäftscode eingebettet“. Typische Technologien sind SOA und ESB. In der zweiten Generation sind „Service-Governance-Funktionen in abstrahiert“. einheitliche SDK-Implementierung". Zu den typischen Technologien gehören: Spring Cloud und Dubbo. Bisher verfügt die dritte Generation über einheitliche Service-Governance-Funktionen im Service Grid. Als nächste Generation der Cloud-nativen Technologie ist das Service Grid zur Standardkonfiguration von geworden Cloud-Infrastruktur .

Weiterentwicklung der Service-Governance

serviceMesh ist die Infrastrukturschicht, die die Kommunikation zwischen Diensten abwickelt. Sie gleicht die Mängel von Kubernetes bei der Verbindung, Verwaltung und Überwachung von Mikrodiensten aus und bietet Kubernetes eine bessere Anwendungs- und Dienstverwaltung.

Das Kernkonzept des Service Mesh:

Die nicht-intrusive Sidecar-Injection-Technologie injiziert Datenebenenkomponenten in den Container, in dem sich die Anwendung befindet, und implementiert Funktionen, indem sie den Anwendungsverkehr kapert, ohne dass die Anwendung davon Kenntnis hat.
Die Northbound-API ist auf Basis von K8s CRD implementiert , vollständig deklarativ und standardisiert.
Die Datenebene und die Steuerungsebene kommunizieren über das standardisierte xDS-gRPC-Protokoll und unterstützen den Abonnementmodus.

Kernfunktionen des Service Mesh:

Service- und Verkehrsmanagement: Leistungsschalter, Fehlerinjektion, umfassender Lastausgleichsalgorithmus, Strombegrenzung, Gesundheitsprüfung, Graustufenfreigabe, Blau-Grün-Bereitstellung usw.
Verkehrs- und Zugriffsvisualisierung: Bietet Überwachung auf Anwendungsebene, verteilte Anrufketten, Zugriffsprotokolle usw.
Sichere Verbindung: Helfen Sie Unternehmen, Anwendungen in Zero-Trust-Netzwerken durch Sicherheitsmaßnahmen wie mTLS, Authentifizierung und Authentifizierung auszuführen.

Derzeit erfreut sich das von Istio repräsentierte Service Mesh zunehmender Beliebtheit, steht jedoch immer noch vor gewissen Herausforderungen. Am Beispiel von Istio beträgt der tatsächliche Speicherbedarf eines Envoy in einem Service-Grid mit 325 Clustern und 175 Listenern etwa 100 Millionen; es gibt insgesamt 466 Instanzen im Grid und der von allen Envoys belegte Speicher erreicht 466 * 100 Millionen = 46,6 G, jeder Gesandte verfügt standardmäßig über 2 Kerne, insgesamt 466 * 2 Kerne = 932 Kerne.

Zusammenfassend besteht das Hauptproblem und die größte Herausforderung der Service Governance der dritten Generation, die Service Governance-Funktionen in das Service Grid integriert, darin, die Leistung und den Ressourcenaufwand des Agenten zu optimieren.

Die Proxy-Schicht führt zu zusätzlichem Verzögerungsaufwand: Ein einzelner Hop für den Dienstzugriff erhöht sich um 2 bis 3 ms, was den Anforderungen verzögerungsempfindlicher Anwendungen nicht gerecht werden kann.
Hohe Ressourcennutzung: Agent-Knoten beanspruchen zusätzlichen CPU-/MEM-Overhead und die Bereitstellungsdichte von Geschäftscontainern ist gering.

Grid-Data-Plane-Software floriert in der Branche und es existieren mehrere technische Wege nebeneinander

Die Branche ist sich über das Problem der Verzögerung und des Grundrauschens in der vorhandenen Gitterdatenebene einig. Um dieses Problem zu lösen, wurden verschiedene technische Routen entwickelt, darunter Cilium Mesh, Linker2-Proxy, gRPC Proxyless Service Mesh und Istio New Mode UmgebungsnetzDie oben genannten Probleme können jedoch in der tatsächlichen Bewertung und Bewertung immer noch nicht gut gelöst werden. Zurück zum Ursprung der Cloud-nativen Anforderungen: Wie kann eine transparente, effiziente und rauscharme Service-Grid-Infrastruktur implementiert und eine Grid-Datenebene mit der besten Leistung in der Branche bereitgestellt werden?

Dies ist aus der zeitaufwändigen Verteilung des Sidecar-Grids ersichtlich: Die Sidecar-Architektur führt zu viel Verzögerungs-Overhead, und die Verkehrsorchestrierung macht nur 10 % des Grid-Overheads aus. Der größte Teil des Overheads liegt in der Datenkopie, zwei weitere Links Einrichtungskommunikation und Kontextwechselplanung. Warten. Können wir also ein seitenwagenloses Versorgungsnetz ohne Netzrauschen erreichen?

Kmesh: Das Verkehrsmanagement versinkt im Betriebssystem und baut ein Sidecarless-Service-Grid auf

Aus der obigen Analyse können wir ersehen, dass unter dem zusätzlichen Overhead, der durch das Netz entsteht, der Anteil der eigentlichen Verkehrsmanagementarbeit nicht hoch ist und die meiste Zeit damit verschwendet wird, den Verkehr an die Proxy-Komponente zu leiten. Dann kann das Verkehrsmanagement sein auf dem Weg des Sendens und Empfangens von Datenverkehr abgeschlossen, ohne diese Proxy-Komponente zu durchlaufen? Die Netzwerkkommunikation läuft natürlich über den Kernel-Protokollstapel. Was wäre, wenn der Protokollstapel die Fähigkeit hätte, den Datenverkehr zu verwalten?

Zu diesem Zweck haben wir das leistungsstarke Kmesh-Service-Management-Framework entwickelt , das auf dem programmierbaren Kernel basiert und die Verkehrsverwaltung auf das Betriebssystem verlagert. Die Grid-Datenebene durchläuft nicht mehr die Proxy-Komponente und die Service-Interoperabilität ändert sich von 3 Hops auf 1 Hop, wodurch kein Online-Zugriff erreicht wird. Textwechsel, kein Datenkopieren und Service-Management-Effekte der agentenlosen Kommunikation. Der Verkehrspfad sieht folgendermaßen aus:

Im Folgenden stellen wir vor, wie Kmesh Service-Governance-Funktionen aus der Perspektive des Betriebssystems implementiert:

Hohe Leistung: Das Betriebssystem unterstützt nativ die Verkehrsorchestrierung L4–L7

Während der Traffic-Orchestrierungslaufzeit implementiert Kmesh die L4~L7-Orchestrierungsbasis im Betriebssystem basierend auf Technologien wie Pseudo-Link-Building und Delayed-Link-Building; basierend auf ebpf erstellt es eine programmierbare Full-Stack-Traffic-Orchestrierungs-Laufzeit im Kernel-Protokollstapel.

Kmesh-Laufzeit für die Verkehrsorchestrierung

Geringer Grundrauschen: Es besteht keine Notwendigkeit, Proxy-Komponenten im Pod bereitzustellen, und der Ressourcenaufwand für die Grid-Datenebene wird um 70 % reduziert.

Da Kmesh die Verwaltungsfunktion zusammen mit dem Verkehrspfad ausführt, ist es in dieser Form nicht erforderlich, Sidecar-Software in der APP bereitzustellen. Es muss lediglich das Kmesh-Programm auf dem Knoten eingerichtet werden. Im Vergleich zum herkömmlichen Sidecar ist dieser Vorgang möglich Der Ressourcenaufwand wird um etwa 70 % reduziert.

Reibungslose Kompatibilität: automatisches Andocken von Verwaltungs- und Steuerungsebenen, beschleunigte kollaborative Governance mit vorhandenen Datenebenen

Kmesh ist reibungslos kompatibel, unterstützt die Kompatibilität mit vorhandenen Service-Grids, stellt automatisch eine Verbindung zur Grid-Steuerungsebene (Istiod) her und unterstützt das XDS-Verkehrskoordinierungsprotokoll. Wenn der Benutzer derzeit den Sidecar-Typ verwendet, kann er nach der Verwendung von Kmesh Sockmap anstelle von Iptables verwenden, um die Weiterleitungsleistung des vorhandenen Grids zu beschleunigen.

Full-Stack-Visualisierung: Full-Stack-Visualisierung des Verkehrsmanagements

Kmesh bietet Benutzern außerdem eine vollständige Visualisierung des Verkehrsmanagements. Wir wissen, dass die Beobachtung des Sidecar-Grid-Verkehrs hauptsächlich in der Sidecar-Verkehrskomponente abgeschlossen wird. Wenn wir Kmesh zur Implementierung dieser Funktion verwenden, erreichen wir durch die Perspektive des Betriebssystems einen Full-Stack-End-to-End-Indikator von App zu App. Gleichzeitig Gleichzeitig werden Niedriglast-Beobachtungssonden basierend auf ebpf implementiert, um die Auswirkungen der Beobachtung auf das Grundrauschen des Systems zu reduzieren, und die OS-Perspektive ermöglicht es der Beobachtung, eine Feinkörnigkeit auf niedrigem Niveau zu erreichen. Kmesh kann auch mit gängigen Beobachtungsplattformen verbunden werden, um umfassendere Beobachtungseffekte zu erzielen.

Die Leistung der HTTP-Weiterleitung ist im Vergleich zu Branchenlösungen um das Fünffache verbessert

Kmesh implementiert die Verkehrsorchestrierungslaufzeit auf Kernelebene durch verzögerten Verbindungsaufbau und Anwendungsprotokollerkennung und verwendet ebpf auch, um die Verkehrsorchestrierung und Beobachtungsprüfungen abzuschließen. Durch die Orchestrierung des kmesh-Controller-Programms kann Kmesh einerseits eine Verbindung zur externen Netzsteuerungsebene wie Istiod herstellen und andererseits die Beobachtungsdaten mit der Service-Grid-Beobachtungsplattform verbinden und das ebpf-Programm innerhalb verwalten Betriebssystem und bietet somit reibungslose Kompatibilität und hohe Effizienz. Leistung, geringer Overhead, Sicherheitsisolation, Full-Stack-Visualisierung und offene ökologische Funktionen verbessern die Service-Weiterleitungsleistung um 50 % bzw. 60 %, verbessern die Service-Startleistung um 40 % und reduzieren das Rauschen Bodenhöhe um 70 %.

Tatsächliche Messung des Kmesh-Verkehrsmanagementeffekts

Tatsächliche Messung der Kmesh-Verkehrsmanagementleistung

Aus technischer Sicht ist die HTTP-Weiterleitungsleistung von Kmesh im Vergleich zum bestehenden Branchen-Sidecar-Grid im Vergleich zur Branchenlösung um das Fünffache verbessert, wodurch eine leistungsstarke Service-Grid-Architekturlösung für Benutzer entsteht! Willkommen beim Kmesh-Open-Source-Projekt https://github.com/kmesh-net/kmesh , um es zu erleben!

Weitere spannende Live-Übertragungsinhalte und aktuelle Demotests finden Sie auf der offiziellen Website der Cloud-Community: https://bbs.huaweicloud.com/live/DTT_live/202311221700.html

Klicken Sie hier, um zu folgen und so schnell wie möglich mehr über die neuen Technologien von Huawei Cloud zu erfahren~