Ursprünglicher Autor: Tao Hui – Hangzhou Zhilianda Data Co., Ltd., Mitbegründer und CTO

Ursprünglicher Link: Kursbericht | Funktionsprinzip des Ingress Controllers (Teil 2)

Nachdruckquelle: NGINX Open Source Community

Die einzige offizielle chinesische Community von NGINX, alle unter nginx.org.cn

Anmerkung des Herausgebers: Dieser Artikel ist das Kursprotokoll des ersten Abschnitts der Kursreihe „Diskussion über die technischen Details des K8S-Ingress-Controllers“ und „Das Funktionsprinzip des Ingress-Controllers“. Da der Artikel lang ist, wird er in zwei Teilen veröffentlicht. Klicken Sie hier , um die Wiederholung des Kurses anzusehen.

In diesem Kurs stellte Lehrer Tao Hui die Funktionsweise des NGINX-Clusters vor und verglich die Laufzeiteigenschaften und Leistungsunterschiede der beiden offiziellen Ingress-Controller von NGINX und Kubernetes.

Zu den Kursinhalten gehören Kubernetes-Netzwerkverkehrsszenarien, die Verwaltung von NGINX-Clustern und die Lösung häufiger Probleme wie Hochverfügbarkeit, Notfallwiederherstellung und Kapazitätserweiterung in verteilten Clustern.

Hohe Datenverfügbarkeit

Im zweiten Aspekt spiegelt sich die Hochverfügbarkeit in der Managementebene des Kubernetes-Clusters selbst wider.

Wenn wir 100 physische Maschinen in den Kubernetes-Pool aufnehmen und ein neues NGINX erstellen müssen, müssen Sie nur einen neuen Pod erstellen. Erstellen Sie einen neuen Pod im Pod-Pool und schon kann alles sofort erledigt werden.

Was kann erreicht werden? Erstens können Sie eine IP-Adresse beliebig zuweisen, z. B. die ursprüngliche 10.1.2.3, ersetzt durch 10.1.100.100. Dies geschieht durch Networking, also durch das CNI-Plugin (Bridge). Das Netzwerk wird von Kubelet verwaltet und Speicher und Protokolle wie Protobuf, gRPC und JSON sind alle enthalten.

Mit anderen Worten: Der Scheduler von Kubernetes verwaltet dies automatisch und APIServer übernimmt die Kommunikation. Daher kann die Anzahl des Betriebs- und Wartungspersonals erheblich reduziert werden. Sie müssen nur einige Vorgänge am Bedienfeld über APIServer ausführen, um die verwalteten Container-Pods automatisch aufzulösen.

Auf dieser Basis ist auch unser NGINX Ingress Controller automatisch hochverfügbar. Wenn die NGINX-Clusterverwaltung nicht auf Kubernetes basiert, wird daher mehr Aufwand betrieben, um die hohe Verfügbarkeit von NGINX selbst sicherzustellen.

NGINX verwaltet Pods in Kubernetes mit hoher Verfügbarkeit

Sehen wir uns als Nächstes an, wie NGINX Pods in Kubernetes mit hoher Verfügbarkeit verwaltet.

Für relevante spannende Inhalte können Sie hier auf den Artikel „Kursaufzeichnung | Arbeitsprinzip des Ingress Controllers (Teil 2)“ klicken , um ihn anzuzeigen.

nginx.conf-Vorlage

Hier finden Sie eine kurze Einführung in die Vorlage nginx.conf.

Die offizielle Kubernetes-Vorlage ist eine Vorlage in der Go-Sprache. Wenn die Anweisungen in ETCD in JSON geschrieben werden, wird daraus eine neue nginx.conf, indem die Zeichenfolgen in der Vorlage ersetzt werden.

Die offizielle Version von NGINX ist einfacher. Sie ist in zwei Konfigurationen unterteilt, eine mit dem Namen nginx.tmpl und die andere mit dem Namen nginx.ingress.tmpl. Der Unterschied zwischen diesen beiden Vorlagen besteht darin, dass der Server über den Ingress separat platziert wird Include-Funktion von nginx.conf Fertigstellen.

Neuladevorgang

Der Neuladevorgang in NGINX ist wie unten dargestellt.

Wenn eine neue Konfiguration basierend auf der neuen nginx.conf erstellt wird, sind die alte und die neue Konfiguration gleichzeitig vorhanden. Theoretisch werden Benutzer den Neustart beim erneuten Laden nicht bemerken, jedoch bei hoher Parallelität, hoher Leistung und hoher -Durchsatz-Szenarien, es kommt immer noch zu einem Neuladen. Einige Auswirkungen haben Langzeiteffekte und können einige Zehntelprozent der Anfragen betreffen.

Dies ist einer der Gründe, warum Kubernetes offiziell OpenResty zur Implementierung des Ingress-Controllers verwendet.

Offizielle Kubernetes-Ingress-Controller-Architektur

Im Folgenden wird die offizielle Ingress-Controller-Architektur von Kubernetes vorgestellt.

Kubernetes APIServer kann fünf Arten von ETCD-Daten abrufen (Ingress, Service, Endpoint, Secret, ConfigMap, ConfigMap). Danach benötigen wir einen in der Go-Sprache geschriebenen Prozess, um nginx.conf zu verwalten und Aktualisierungsanfragen an Lua Server zu senden. ——Das ist die Änderung des gemeinsamen Speichers.

Wie werden diese beiden Dinge erreicht?

Es gibt viele Coroutinen in der Go-Sprache. In einem in der Go-Sprache geschriebenen Prozess werden viele Coroutinen gleichzeitig ausgeführt. Wenn Sie mit Coroutinen nicht vertraut sind, können Sie sie als Thread verstehen. Die Store-Coroutine im obigen Bild kommuniziert mit dem APIServer, um Ressourcenänderungen über den Informer-Modus zu überwachen.

Mit anderen Worten: Sobald sich die fünf Datentypen in ETCD ändern, überträgt APIServer sie an die Store-Coroutine. Wenn eine Maschine auflegt, ändert sich der Endpunkt; wenn jemand den Schlüssel aktualisiert, ändert sich das Geheimnis; wenn sich die Anzahl der Arbeitsprozesse von zwei auf vier ändert, ändert sich die ConfigMap; wenn ein neuer Domänenname hinzugefügt wird, ändert sich der Eingang Änderung. Okay... nachdem die Änderung erfolgt ist, wird die Store-Coroutine davon erfahren.

Danach schreibt die Store-Coroutine die vom APIServer übergebenen Änderungs-/Aktualisierungsereignisse in den Kanal (eine Art der Kommunikation zwischen zwei Coroutinen in der Go-Sprache) und der Hauptprozess des NGINX Ingress Controllers wird aus dem Kanal entfernt. Daten wird in eine Synchronisationswarteschlange gestellt. Es gibt auch eine Coroutine (SyncQueue), die die Daten liest und mit der Verarbeitung beginnt.

Bei der Verarbeitung werden einige einfache Beurteilungen vorgenommen. Erstens, ob die Datei nginx.conf geändert wurde. Wenn sie geändert wurde, wird ein Neuladen ausgeführt. Es gibt eine Situation, die nicht geändert werden muss, nämlich die, in der sich der Endpunkt ändert. Dies ist ein Hochfrequenzereignis für große Cluster. Bei 10.000 Maschinen können jede Minute mehrere ausfallen. Dies kommt sehr häufig vor.

Wenn Sie NGINX reload jede Minute ausführen, ist die Leistung sehr schlecht. Angesichts dieses Problems speichert der auf OpenResty basierende Lua-Ausgleich Endpunktinformationen in gemeinsam genutztem DICT (einer Lua-Datenstruktur, die durch Abstraktion des gemeinsam genutzten Speichers in eine auf Rot-Schwarz-Bäumen und LRU basierende Eliminierungsliste implementiert wird).

Daher werden die Beurteilungsbedingungen in zwei Kategorien unterteilt: Eine besteht darin, dass nur die Daten im gemeinsam genutzten Speicher geändert werden und dann nur eine HTTP-Anfrage gesendet werden muss (dies ist eine REST-API, ihre Methode ist eine POST-Anfrage) und der Inhalt ist ein JSON). Senden Sie die Informationen einfach an NGINX. Der zweite Typ besteht darin, die Konfiguration von nginx.conf zu ändern und dann „Reload“ auszuführen, und NGINX kann die neue Konfiguration zum Bereitstellen verwenden.

Prozess im offiziellen Ingress-Controller von Kubernetes

Im Folgenden finden Sie eine kurze Einführung in den Prozess im offiziellen Ingress-Controller von Kubernetes. Es gibt einen gemeinsamen Speicher, in dem Backend (d. h. Back-End-Upstream-Informationen), Zertifikate usw. gespeichert werden, der über Lua-Code verwaltet wird.

Dann werden auf der Go-Sprache geschriebene Prozesse über viele Ports bereitgestellt. Wenn wir beispielsweise den gemeinsam genutzten Speicher ändern, ändern wir ihn über den 10246-Port des lokalen Computers. Dieser Prozess kommuniziert auch mit APIServer über das Client-Go-SDK – über das Store-Paket (es gibt ein Paket in der Go-Sprache).

Kubelet ist ein Prozess auf jeder Maschine und jedem Knoten auf dieser Maschine. Es verwaltet den Gesundheitsstatus über 10254/healthz.

Was Prometheus betrifft, ist es das zweite Projekt in CNCF (das erste ist Kubernetes). Es dient der Überwachung. Es ist ein Open-Source- und inzwischen weit verbreitetes visuelles Überwachungssystem, das über 10254/Metriken verwaltet wird.

Dies ist eine grobe Idee, dieser Prozess wird in zukünftigen Lektionen ausführlich behandelt.

Leistungsvergleich von Ingress-Controllern

Abschließend zeige ich Ihnen zwei vergleichende Testergebnisse: Es gibt drei Ingress-Controller, die alle auf Basis von NGINX implementiert sind.

Der erste ist der offizielle NGINX OSS Ingress Controller von NGINX (OSS steht für Open Source, Open Source); der zweite ist der NGINX Plus Ingress Controller (NGINX Plus, die kommerzielle Version von NGINX), der Closed Source ist; der dritte ist der Ingress Controller Die von der offiziellen Kubernetes-Community bereitgestellte Version basiert auf OpenResty – ebenfalls implementiert von NGINX, jedoch mit der Hinzufügung der Lua-Sprache. (Da es sich bei NGINX Plus um eine Closed-Source-Lösung handelt, wird es in den folgenden Testergebnissen nicht analysiert.)

Die folgenden zwei Leistungstestdiagramme sind: statischer Bereitstellungstest und dynamischer Bereitstellungstest. In Kubernetes gibt es viele Ingress-Controller, die auf vielen Pods bereitgestellt werden. Was bedeutet es, wenn sich diese Pods ständig ändern?

Für das offizielle NGINX bedeutet dies, dass sich nginx.conf geändert hat. Für Kubernetes bedeutet dies, dass sich die Daten im gemeinsam genutzten Speicher geändert haben, weil sie durch Lua geändert wurden. Dies ist eine dynamische Bereitstellung. Statische Bereitstellung bedeutet, dass nginx.conf grundsätzlich unverändert bleibt.

Schauen wir uns zunächst das statische Testdiagramm an. Die x-Achse ist der Prozentsatz und die y-Achse die Latenz.

Wenn 30.000 Anfragen pro Sekunde (30.000 RPS) gesendet werden, betragen 99 % der Anfrageverzögerungen weniger als 50 Millisekunden. In 99,9 % der Fälle wird die OpenResty-Latenz hoch, nahe bei 100 Millisekunden – der Grund ist Lua, denn jedes Mal Wenn eine Anfrage verarbeitet wird, muss der Ausgleich durch Lua einmal ausgeführt werden, wenn von der C-Sprache zur Lua-Sprache gesprungen wird, sodass er langsamer wird.

In 99,99 % der Fälle ist das Open-Source-NGINX die beste Leistung, da es am einfachsten ist, reine C-Sprache verwendet und keine dynamische Änderung unterstützt. Dynamische Änderung erfordert ein Neuladen und es gibt kein Neuladen. Daher schneidet Open-Source-NGINX am besten und Lua am schlechtesten ab.

Während des dynamischen Tests wurde die Anzahl der Pods alle 10 bis 12 Sekunden wiederholt von 5 auf 7 angepasst.

Wenn NGINX bei 30.000 RPS ständig gestartet und gestoppt wird, wird das Neuladen überhaupt nicht ausgeführt, da Lua das Gleichgewicht von Lua verwendet, sodass es sehr stabil ist.

Das Open-Source-NGINX schneidet am schlechtesten ab, da das ständige Neuladen dazu führt, dass die Latenz einzelner Anforderungen hoch wird, da in der Mitte viele Informationen vorhanden sind, z. B. Paketverluste, die dazu führen, dass der alte Worker ständig hängt Bei der endgültigen Anfrage werden einige Probleme auftreten. Und solange der NGINX-Worker nicht neu startet, ist die Leistung sehr gut.

Für genauere Details können Sie sich auf den Quellcode beziehen, einschließlich der Vorlage nginx.conf, Kenntnisse in Bezug auf die Go-Sprache usw. Das Obige ist das Prinzip des Ingress-Controllers. Ich hoffe, es wird für alle hilfreich sein.