In der k8s-Welt wird jede Ressource über einen Controller erstellt. So gibt es eingebaute Controller für Pods, Bereitstellungen, Replikatsätze usw. Controller sind also im Grunde nichts anderes als ein Regelkreis, der kontinuierlich den Zustand des Clusters überwacht und Maßnahmen ergreift, um den Cluster in den gewünschten Zustand zu bringen. Die Ressourcen verfügen über eine Spezifikation, die den gewünschten Zustand bereitstellt. Die Steuerung prüft die aktuellen Zustände. Wenn es nicht dem gewünschten Zustand entspricht, werden die entsprechenden Änderungen oder Modifikationen vorgenommen, um es näher an den gewünschten Zustand zu bringen.
ReplicaSet Controller: Dieser Controller ist für die Aufrechterhaltung eines stabilen Satzes von Replikat-Pods verantwortlich, die jederzeit ausgeführt werden. Es wird häufig in Verbindung mit Bereitstellungen verwendet, um sicherzustellen, dass jederzeit eine bestimmte Anzahl von Pod-Replikaten ausgeführt wird, selbst im Falle eines Knotenausfalls oder einer Pod-Beendigung.
Deployment Controller: Dieser Controller stellt deklarative Updates für Pods und ReplicaSets bereit. Es ermöglicht eine einfache Skalierung, fortlaufende Updates und Rollbacks von Anwendungen. Der Deployment Controller verwaltet die Erstellung und Löschung von ReplicaSets, um sicherzustellen, dass immer die gewünschte Anzahl von Pods ausgeführt wird.
StatefulSet Controller: Dieser Controller wird zur Verwaltung zustandsbehafteter Anwendungen wie Datenbanken verwendet. Es verleiht jedem Pod im Satz eine eindeutige Identität (einen stabilen Hostnamen) und behält die Reihenfolge und Einzigartigkeit dieser Pods bei. Dies ist besonders nützlich, wenn Sie stabile Netzwerkkennungen, stabilen dauerhaften Speicher und eine geordnete, ordnungsgemäße Bereitstellung und Skalierung benötigen.
Service Controller: Dieser Controller ist für die Aufrechterhaltung einer stabilen IP-Adresse und eines DNS-Namens für eine Reihe von Pods verantwortlich. Es fungiert als Load Balancer und leitet den Datenverkehr basierend auf dem Selektor des Dienstes an die entsprechenden Pods weiter. Dadurch wird sichergestellt, dass Dienste über einen stabilen Endpunkt für den Zugriff auf die laufenden Pods verfügen, selbst wenn diese erstellt, zerstört oder im Cluster verschoben werden.
Bevor wir uns also mit dem Testen befassen, müssen wir die grundlegende Architektur eines Standard-Controllers verstehen. In der Client-Server-Architektur von Kubernetes spielen Controller eine entscheidende Rolle als Clients, die API-Aufrufe, hauptsächlich HTTP, an den Kubernetes-API-Server durchführen. Ihr Hauptziel besteht darin, Kubernetes-API-Objekte mit den tatsächlichen Systemressourcen abzugleichen. Ein wesentlicher Bestandteil dieser Architektur ist der Einsatz von Informern. Informanten sind für die Überwachung aller Änderungen im Cluster verantwortlich, was von entscheidender Bedeutung ist, da kontinuierliche Abfragen zum Abrufen von Informationen zu Ressourcen die Leistung des API-Servers erheblich beeinträchtigen können.
Informer arbeiten, indem sie die Ressourcendaten abfragen und in einem lokalen Cache speichern. Sobald die Daten gespeichert sind, wird nur dann ein Ereignis generiert, wenn sich der Zustand eines Objekts (oder einer Ressource) ändert. Dieser Ansatz stellt sicher, dass das System nicht durch unnötige Ereignisse überlastet wird und der Controller nur dann benachrichtigt wird, wenn eine relevante Änderung eintritt.
Ein weiteres wichtiges Konzept in dieser Architektur ist die Ressourcenversion. Diese Version ändert sich bei jedem Schreibvorgang und dient der optimistischen Parallelitätskontrolle. Dadurch wird sichergestellt, dass Aktualisierungen von Ressourcen so verwaltet werden, dass Konflikte vermieden werden und die Konsistenz im gesamten System gewahrt bleibt. Durch das Verständnis und die Nutzung dieser Mechanismen können Kubernetes-Controller den Zustand der Ressourcen in einem Cluster effizient verwalten und abgleichen.
Kubernetes ermöglicht die Erstellung von Custom Resource Definitions (CRDs), bei denen es sich um Erweiterungen der Kubernetes-API handelt, die es Benutzern ermöglichen, benutzerdefinierte Ressourcen zu definieren. Diese benutzerdefinierten Ressourcen sind in einer Standard-Kubernetes-Installation nicht verfügbar und werden verwendet, um domänenspezifische Anwendungsfälle und komplexe Anwendungsanforderungen zu erfüllen.
Um diese benutzerdefinierten Ressourcen zu verwalten, ist ein benutzerdefinierter Controller erforderlich. Der benutzerdefinierte Controller, CRD und der Kubernetes-API-Server bilden eine zusammenhängende Beziehung, wobei:
Das CRD definiert die benutzerdefinierten Ressourcen.
Der API-Server verwaltet den Lebenszyklus dieser Ressourcen.
Der benutzerdefinierte Controller stellt sicher, dass der Zustand dieser Ressourcen gemäß der gewünschten Konfiguration beibehalten wird.
Diese Architektur ermöglicht die Erweiterbarkeit von Kubernetes und ermöglicht es Benutzern, die Plattform an ihre spezifischen Bedürfnisse anzupassen.
Vor der Bereitstellung in der Produktion muss unbedingt sichergestellt werden, dass ein Kubernetes-Controller bereit ist, Anfragen an den Kubernetes-API-Server zu verarbeiten. Es gibt verschiedene Ansätze zum Testen von Kubernetes-Controllern. Einige davon, die ich erwähnt habe, stammen aus dem Artikel:
Verwendung von Client-Go-Fakes oder Abstraktionen auf höherer Ebene: Dieser Ansatz vermeidet die Ausführung einer unterstützenden API und eignet sich daher zum isolierten Unit-Testen einzelner Komponenten.
Verwendung des envtest-Pakets von Controller-Runtime: Dieses Paket arbeitet mit einem abgespeckten API-Server, um echte Interaktionen mit der API, einschließlich Timing und Cache-Synchronisierungen, ohne Beeinträchtigung durch andere Controller zu validieren . Es unterstützt sowohl lokale Tests mit einer reduzierten Instanz als auch Tests mit einem voll funktionsfähigen Cluster.
Ausführen eines echten API-Servers: Dieser Ansatz eignet sich zum Staging von Umgebungen oder Instanzen wie ephemeral kind oder microk8s zum Testen realer Ergebnisse. Es ermöglicht das Testen von Interaktionen mit einem echten API-Server.
Der Vorteil der Verwendung eines externen Prozesses wie envtest oder eines echten API-Servers besteht darin, dass er die einem verteilten System inhärente Latenz berücksichtigt. Bibliotheken wie Gomega können verwendet werden, um auf bestimmte Bedingungen zu warten, nachdem eine Aktion ausgeführt wurde. Die oben genannten Ansätze eignen sich häufig am besten für Unit-Tests und Tests auf Integrationsebene, bei denen wir eine bestimmte Komponente isoliert testen. entweder durch Fälschung der Daten durch das Schreiben von Tests
Während die oben genannten Techniken für Unit- und Integrationstests effektiv sind, decken sie möglicherweise nicht End-to-End-Tests (E2E) ab, die für die Gewährleistung der Gesamtfunktionalität des Controllers von entscheidender Bedeutung sind. Ein Ansatz für E2E-Tests besteht darin, Ressourcenaktualisierungen und andere Vorgänge durchzuführen, um den gesamten Ablauf des Controllers in einer kontrollierten Umgebung zu testen und den Prozess bei Bedarf zu replizieren. Dies hilft, das Verhalten des Controllers in realen Szenarien zu validieren und sicherzustellen, dass er für den Produktionseinsatz bereit ist.
Zusammenfassend lässt sich sagen, dass eine Kombination aus Unit-, Integrations- und End-to-End-Tests unerlässlich ist, um die Zuverlässigkeit und Effektivität von Kubernetes-Controllern sicherzustellen, bevor sie in die Produktion gehen.
Das lokale Erstellen und Testen von Kubernetes-Controllern kann eine Herausforderung sein, insbesondere wenn es um ausgehende API-Aufrufe geht. Keploy bietet jedoch als Tool, das Testfälle und Datenmocks aus API-Aufrufen, DB-Abfragen usw. erstellt, eine Lösung. Mit Keploy können Sie ausgehende Anrufe Ihres Kubernetes-Controllers aufzeichnen und wiedergeben, was beim Testen und Sicherstellen, dass sich Ihr Controller wie erwartet verhält, äußerst nützlich sein kann.
Sie fragen sich vielleicht, wie dies ohne Codeänderungen möglich ist. Keploy verwendet eBPF, um Sonden zum Kernelraum hinzuzufügen und Netzwerkpufferdaten zu sammeln. Diese Daten werden dann an den Proxy von Keploy gesendet, der als Benutzerbereich fungiert, in dem die gesamte Verarbeitung des Puffers durch verschiedene Protokollparser erfolgt. Keploy kann den ausgehenden Datenverkehr des Controllers erfassen und die Anfrage und Antwort für dieses bestimmte Ereignis in einer YAML-Datei speichern. Im Wiedergabemodus sendet Keploy nicht den API-Aufruf an den echten API-Server, sondern gibt die Antwort aus der gespeicherten YAML-Datei für diese bestimmte Anfrage zurück. Dies macht den Prozess unabhängig vom Cluster oder der Umgebung und bietet eine bequeme und effiziente Möglichkeit, Kubernetes-Controller lokal zu testen.
Um die Tests Ihrer Controller lokal oder aus einer beliebigen Live-Umgebung zu erfassen, müssen Sie also zunächst den Kubernetes-Cluster starten und Ihren benutzerdefinierten Controller erstellen, um eine gewisse Interaktion mit dem Server durchzuführen.
Um Ihren Controller mit Keploy aufzuzeichnen, befolgen Sie diese Schritte:
Stellen Sie Ihr Kubernetes *rest.Config-Objekt auf unsicher und ohne CA-Datei ein:
cfg.Insecure = true cfg.CAFile = ""
Erstellen Sie einen benutzerdefinierten RoundTripper, um ein Header-Feld hinzuzufügen, das die Ressourcenversion enthält. Dieser Header dient als Trace-ID für den Abgleich von Anfragen im selben Status mit aufgezeichneten Mocks. Hier ist eine Beispielimplementierung:
type customRoundTripper struct {
rt http.RoundTripper
}
func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
ctx := req.Context()
rsv := ctx.Value("ResourceVersion")
if rsv != nil {
req.Header.Add("keploy-header", rsv.(string))
}
return crt.rt.RoundTrip(req)
}
cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
return &customRoundTripper{rt: rt}
}
Stellen Sie sicher, dass Sie während des Synchronisierungsvorgangs den Ressourcenversionswert in context.Context festlegen. Dies ist entscheidend für die Übergabe des geänderten Kontexts an die Update- und Create-Methoden Ihres Controllers. Zum Beispiel:
func (c *Controller) syncHandler(ctx context.Context, key string) error {
// set ResourceVersion in ctx
rv := foo.GetResourceVersion()
if rv != "" {
ctx = context.WithValue(ctx, "ResourceVersion", rv)
}
}
Erstellen Sie die Go-Binärdatei Ihres Kubernetes-Controllers:
go build -o sample-controller .
Um die ausgehenden Anrufe über Keploy aufzuzeichnen, schließen Sie Ihren Controller-Befehl mit dem Aufnahmebefehl von Keploy ein. Hinweis – Diese Funktion von keploy befindet sich in der Beta-Phase und ist noch nicht in der Hauptversion veröffentlicht. Dies wurde speziell als Experiment für Kubernetes-Enthusiasten entwickelt, um Bewertungen abzugeben. Sie müssen also in diesem speziellen Zweig auschecken und die Keploy-Binärdatei mit dem Befehl go build erstellen. https://github.com/keploy/keploy/pull/1342.
Kaufabwicklung in der angegebenen Filiale.
1.
git checkout kube-controller
```
{% endraw %}
Erstellen der Keploy-Binärdatei für diesen Zweig.
{% roh %}
go build -o keploy && sudo mv keploy /usr/local/bin
Fügen Sie die erforderlichen Flags entsprechend Ihrer Kube-Konfiguration hinzu:
sudo -E env PATH=$PATH keploy record -c "./sample-controller -kubeconfig=$HOME/.kube/config" --mtls-cert-path "$HOME/.minikube/profiles/minikube/client.crt" --mtls-key-path "$HOME/.minikube/profiles/minikube/client.key" --mtls-host-name 192.168.49.2:8443
Sie können sehen, wie keploy/test-set-0/mocks.yaml erstellt wird, sobald Keploy beginnt, die ausgehenden Anrufe abzufangen. Jede Ressourcenversion verfügt über eine separate Mock-Datei mit der Bezeichnung „mocks_ „
Hinweis - Eine Sache, die ich klarstellen möchte, ist, dass die obige Funktion Ihnen bei TDD (testgetriebene Entwicklung) nicht hilft. Sie können jedoch beim Schreiben von Unit-Tests immer noch keploy verwenden, indem Sie die Stub-Generierungsfunktion von keploy nutzen. Anstatt also einen simulierten API-Server zu erstellen oder Stubs für einen bestimmten Komponententest zu schreiben, können Sie diesen Test einmal in Ihrer realen Umgebung ausführen. Keploy speichert alle Interaktionen in einer Scheindatei und verwendet diese Daten, wenn die Tests das nächste Mal ausgeführt werden.
So testen Sie Ihren Controller mit aufgezeichneten Mocks:
Führen Sie Keploy im Testmodus aus, wobei das MockAssert-Flag auf „true“ gesetzt ist, und stellen Sie Ihre Controller-Binärdatei bereit. Keploy erstellt automatisch eine gefälschte Kube-Konfiguration für Sie:
cfg.Insecure = true cfg.CAFile = ""
Optional können Sie Ihre eigene Wiedergabezeit festlegen, die versucht, Ihre aufgezeichnete Sitzung innerhalb der angegebenen Zeit wiederzugeben: Eine vollständige Beispiel-App, die in keploy integriert ist, finden Sie hier.
type customRoundTripper struct {
rt http.RoundTripper
}
func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
ctx := req.Context()
rsv := ctx.Value("ResourceVersion")
if rsv != nil {
req.Header.Add("keploy-header", rsv.(string))
}
return crt.rt.RoundTrip(req)
}
cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
return &customRoundTripper{rt: rt}
}
Beachten Sie, dass der Wiedergabeprozess die ausreichend große Ereigniszeitlücke auf eine genaue durchschnittliche Dauer zwischen den beiden Ereignissen der Informanten reduziert. Dadurch können Ereignisse früher gesendet werden, als sie in der Aufzeichnung aufgetreten sind, was eine schnellere Wiedergabe ermöglicht.
Dies kann Ihnen helfen, die gesamte Sitzung der vom Controller erzeugten API-Aufrufe wiederzugeben, aber dieses Mal benötigen Sie keinen echten K8S-Server oder eine externe Quelle, um die Antwort zu erhalten. Alle Antworten werden vom Keploy selbst zurückgegeben, der wie ein Scheinserver oder ein Mittelsmann agiert. Dies kann Ihnen Sicherheit geben, es in Ihren CI-CD-Pipelines auszuführen.
Zum Beispiel – Sie arbeiten in einer großen Cloud-Computing-Organisation und um alle Dinge bereitzustellen, ist viel Virtualisierung erforderlich und ein ressourcenintensiver Betrieb. Daher ist es nahezu unmöglich, es in einer realen Umgebung zu testen. Hier kann ein Keploy-ähnliches Tool sehr nützlich sein, da es bereits über die Antwort verfügt, die Sie im Falle einer erfolgreichen Einführung dieser Ressource erhalten möchten. Dies ermöglicht einen schnellen, zuverlässigen und kostensparenden Betrieb, da Sie den richtigen Ablauf Ihres Controller-Dienstes nur einmal erfassen müssen. Und Sie können die Keploy-Wiedergabe in Ihren nachfolgenden Veröffentlichungen wiederverwenden.
Das lokale Testen von Kubernetes-Controllern kann mit Tools wie Keploy effizienter und zuverlässiger gestaltet werden. Durch die Aufzeichnung und Wiedergabe ausgehender Anrufe können Sie sicherstellen, dass sich Ihr Controller in verschiedenen Szenarien korrekt verhält und so die Gesamtqualität Ihrer Kubernetes-Anwendungen verbessert. Da Keploy über native Unterstützung von Test-Frameworks wie Gotest verfügt, ist es auch möglich, die Leitungsabdeckung jeder Anwendung, sogar Ihres Kube-Controllers, zu erhalten. Entdecken Sie Keploy und verbessern Sie Ihren Kubernetes-Controller-Testworkflow!
Aufzeichnen und Wiedergeben ausgehender API-Aufrufe: Dadurch entfällt die Notwendigkeit von Live-Umgebungen während des Testens.
Verbesserte Effizienz: Durch die Verwendung gespeicherter Mocks wird das Testen schneller und unabhängig vom tatsächlichen Kubernetes-Cluster.
Kosten- und Ressourceneinsparungen: Es reduziert die Abhängigkeit von ressourcenintensiven Umgebungen für die Validierung und eignet sich daher ideal für CI/CD-Pipelines in großen Betrieben.
Keploy verwendet eBPF-Probes, um ausgehende Anrufe abzufangen und Anfrage-Antwort-Paare in Scheindateien zu speichern. Im Wiedergabemodus:
Anrufe werden abgefangen und mit zuvor aufgezeichneten Mocks abgeglichen.
Antworten werden von diesen Mocks zurückgegeben, anstatt sich an den eigentlichen API-Server zu wenden.
Dieser Mechanismus stellt sicher, dass Tests ausgeführt werden können, ohne dass ein Live-Kubernetes-Cluster erforderlich ist.
Obwohl die Aufnahme- und Wiedergabefunktion von Keploy nicht speziell für TDD entwickelt wurde, kann sie dennoch effektiv genutzt werden:
Stub-Generierung: Führen Sie den Controller einmal in einer realen Umgebung aus, um Interaktionen zu erfassen. Keploy erstellt Mocks für die spätere Verwendung.
Unterstützung für Unit-Tests: Durch die Nutzung dieser Mocks können Sie das manuelle Schreiben von Stubs vermeiden und sich auf die Testausführung konzentrieren.
Keploy ergänzt bestehende TDD-Workflows, indem es die Mock-Erstellung rationalisiert und den Entwicklungsaufwand reduziert.
Das obige ist der detaillierte Inhalt vonSo testen Sie den Datenverkehr mit einem benutzerdefinierten Kubernetes-Controller: Eine Schritt-für-Schritt-Anleitung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Der Unterschied zwischen xdata und data
So tätigen Sie einen Anruf, ohne Ihre Nummer anzuzeigen
Was sind die Vorteile der Mongodb-Datenbank?
Einführung in den Eröffnungsort von Win8
Gründe für Sitzungsfehler
Der Unterschied zwischen Unix und Linux
Verwendung der Matlab-Colormap-Funktion
Der Unterschied zwischen Win10-Ruhezustand und Ruhezustand
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
