Einführung in die Kubedog-Bibliothek für die Ressourcenverfolgung von Kubernetes

Wir freuen uns, eine neue Open Source-Entwicklung der Firma Flant für DevOps-Spezialisten und nicht nur für Kubedog bekannt zu geben . Dies ist eine von Go geschriebene Bibliothek und eine darauf basierende CLI zum Verfolgen von Kubernetes-Ressourcenereignissen und zum Sammeln ihrer Protokolle.


Derzeit unterstützt die Bibliothek die Verfolgung der folgenden Ressourcen: Pod (und Container), Job, Bereitstellung, StatefulSet und DaemonSet. Ereignisse und Protokolle werden über Rückrufe übertragen.

Die Kubedog-CLI verfügt über zwei Betriebsmodi:

• Rollout-Track - Verfolgen der Ressource bis zum Erreichen des Bereitschaftszustands und Beenden im Falle eines Fehlers zur bequemen Verwendung in CI / CD;
• follow - druckt Ereignisse und Protokolle auf dem Bildschirm, ohne sie zu beenden, ähnlich wie tail -f .

Das Problem

Warum haben wir angefangen, eine neue Bibliothek zu schreiben, wenn ähnliche Projekte bereits existieren (siehe „Arbeiten mit Protokollen“ in dieser Rezension ) ? Kubedog wird in unserem DevOps-Dienstprogramm dapp verwendet , um den Rollout von Helm-Diagrammen zu verfolgen. Helm selbst weiß nicht, wie der Status der hinzugefügten Ressourcen überwacht werden soll, und die Protokollübertragung wird auf der Ebene der GRPC-Interaktion zwischen Helm und Pinne nicht bereitgestellt. Bei dieser Gelegenheit gibt es unsere Ausgabe 3481 , in deren Rahmen wir die Verfolgung zusätzlicher Ressourcen implementiert haben ... Das Helm-Projekt zögert jedoch jetzt, Helm 2 neue Funktionen hinzuzufügen, da sich alle Bemühungen auf die neue Version von Helm 3 konzentrieren . Aus diesem Grund haben wir beschlossen, Kubedog in ein separates Projekt zu unterteilen.

Was benötigt die Ressourcenverfolgungsbibliothek?

• Abrufen von Protokollen von Pods, die zu einer Ressource gehören, z. B. Bereitstellung.
• Reagieren Sie auf Änderungen in der Zusammensetzung der zur Ressource gehörenden Pods: Fügen Sie Empfangsprotokolle von neuen Pods hinzu, deaktivieren Sie Protokolle von Pods alter ReplicaSets.
• Tracking- Ereignisse, bei denen verschiedene Fehler entschlüsselt werden. Beispielsweise kann ein Pod aufgrund eines unbekannten Bildes nicht erstellt werden, oder es wird ein Pod erstellt, aber der in der Vorlage angegebene Befehl befindet sich nicht im Bild.
• Eine weitere Anforderung besteht darin, den Übergang einer Ressource vom rollout zum ready verfolgen. Und jede Ressource hat dafür ihre eigenen Bedingungen.

Wie Sie sich vorstellen können, haben wir in Kubedog versucht, all das zu berücksichtigen .

In guter Weise analysieren sie zu Beginn der Arbeit an etwas Neuem vorhandene Lösungen. Es stellte sich jedoch heraus, dass es zwar viele Lösungen in Form der CLI gibt, es jedoch einfach keine Go-Bibliothek gibt. Daher können wir nur einen kleinen Vergleich der Hauptfunktionen der vorhandenen CLI-Dienstprogramme zur Verfolgung von Kubernetes-Ressourcen geben.

Bestehende Lösungen

kubespy

→ GitHub

• Kann nur Bereitstellung und Service überwachen und reagiert auf neue Pods.
• Es gibt einen Verfolgungsmodus für die Beschreibung der Ressource und ihres Status sowie für die Ausgabe von Änderungen in Form von json diff.
• Es gibt eine farbige tabellarische Darstellung der Änderungen, die den Status von ReplicaSets und Bedingungen anzeigt.
• Zeigt keine Pod-Protokolle an.
• Es ist in Go geschrieben, kann aber nicht als Bibliothek verwendet werden.

Kubetail

→ GitHub

• Ein Bash-Skript, das kubectl aufruft.
• Kann Protokolle vorhandener Pods anzeigen.
• Es werden keine neuen Pods erkannt. Wenn ein Rollback auftritt, muss kubetail neu gestartet werden.

Heck

→ GitHub

• Zeigt die Protokolle der durch Pod-Abfrage gefilterten Pods an.
• Entdecken Sie neue Pods.
• Protokolllinien sind zur besseren Wahrnehmung farbig.
• Zeigt die Ereignisse beim Hinzufügen und Entfernen von Pods mit den Namen der darin enthaltenen Container an.
• Es folgt keinen Ereignissen, daher wird die Ursache für Pod-Fehler nicht angezeigt.
• Es ist in Go geschrieben, kann aber nicht als Bibliothek verwendet werden.

Kail

→ GitHub

• Kann gleichzeitig Protokolle aus verschiedenen Namespaces für verschiedene Ressourcen anzeigen.
• Überwacht keine Ereignisse, zeigt nicht die Fehlerursache an, z. B. für die Bereitstellung.
• Malt keine Protokolle von Pods.
• Es ist in Go geschrieben, kann aber nicht als Bibliothek verwendet werden.

k8stail

→ GitHub

• Eine Auswahl von Pods nach Namespace und Labels.
• Verfolgt neue, Löschen.
• Folgt keinen Ereignissen, zeigt keine Fehler an.
• On Go, aber keine Bibliothek.

Kubedog

→ GitHub

• Die CLI arbeitet in zwei Modi: Endlos-Tracking und Tracking, bis die Ressource in den Status BEREIT wechselt.
• Verfolgt eine Ressource.
• Reagiert auf Ressourcenänderungen und abonniert die Protokolle neuer Pods.
• Kann Bereitstellung, StatefulSet, DaemonSet, Job oder einen separaten Pod überwachen.
• In Go können Sie es als Bibliothek verwenden, um Ihrem Programm Ressourcen hinzuzufügen, um den Status von Ressourcen zu überwachen und Protokolle von Containern zu erhalten.

Wenn Sie genauer hinschauen, können Sie sagen, dass jedes Dienstprogramm seine Konkurrenten in irgendeiner Weise übertrifft und es keinen einzigen Gewinner gibt, der alles kann, was die anderen tun.

Also Kubedog!

Das Wesentliche an der Arbeit von kubedog ist: Führen Sie für die angegebene Ressource Watchers on Events und Pods aus, die zur Ressource gehören, und führen Sie den Logger aus, wenn Pod angezeigt wird. Alles, was mit der Ressource passiert, wird durch Aufrufen von Rückrufen an den Client gesendet.

Schauen wir uns ein Beispiel für DaemonSet an, das für Code verfügbar ist, der die Bibliothek verwendet. Die Rückrufschnittstelle für Deployment, StatefulSet und DaemonSet ist dieselbe * - dies ist ControllerFeed :

 type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error } 

* Die Ausnahme ist AddedReplicaSet , was nur für die Bereitstellung sinnvoll ist (Sie können diese Methode zum Verfolgen von DaemonsSet nicht definieren).

Erläuterungen zu anderen Schnittstellenmethoden:

• Added entspricht der watch.Added Ereignis des Beobachters für die ausgewählte Ressource watch.Added ;
• Ready wird aufgerufen, wenn die Ressource in den Status Ready (für DaemonSet ist dies beispielsweise der Moment, in dem die Anzahl der aktualisierten und verfügbaren Pods mit der „gewünschten“ Anzahl der Pods übereinstimmt).
• Failed - Diese Methode wird aufgerufen, wenn eine Ressource gelöscht wird oder wenn ein Ereignis mit der Ursache und Beschreibung des Fehlers empfangen wird (z. B. FailedCreate ).
• EventMsg wird für jedes Ereignis aufgerufen, das von der Ressource oder ihren Pods empfangen wird: Dies sind Ereignisse zum Erstellen der Ressource, zum Hochladen von Bildern usw. Einschließlich Fehlermeldungen;
• AddedPod - eine Methode, mit der Sie die Momente beim Erstellen neuer Pods AddedPod können.
• PodLogChunk wird aufgerufen, wenn ein anderes Protokoll von der Kubernetes-API stammt.
• PodError wird PodError , wenn Pod fehlschlägt.

Jeder Rückruf kann einen StopTrack und die Verfolgung wird abgeschlossen. So zum Beispiel im Rollout-Tracker - Ready StopTrack und CLI beendet seine Arbeit.

Um die Definition von Rückrufen zu vereinfachen, gibt es eine ControllerFeedProto Struktur, mit der Sie beim Erstellen eines Objekts die gewünschte Rückrufmethode bestimmen können.

So sieht beispielsweise die endlose Ausgabe von DaemonSet-Protokollen ohne zusätzliche Informationen zu Ereignissen und Status aus:

 // kubedog     Kubernetes',    // . https://github.com/flant/kubedog/blob/master/pkg/kube/kube.go kubeClient, err := kubernetes.NewForConfig(config) if err != nil { return err } feed := &tracker.ControllerFeedProto{ PodLogChunkFunc: func(chunk *tracker.ReplicaSetPodLogChunk) error { for _, line := range chunk.LogLines { fmt.Printf(">> po/%s %s: %s\n", chunk.PodName, chunk.ContainerName, line) } return nil }, } //    timeout   API   ,     .   ,     ,    Pod'. opts := tracker.Options{ Timeout: time.Second * time.Duration(300), LogsFromTime: time.Now(), } tracker.TrackDaemonSet(dsName, dsNamespace, kubeClient, feed, opts) 

Der letzte Anruf ist blockierend : Er startet eine Endlosschleife des Empfangs von Ereignissen von Kubernetes und ruft entsprechende Rückrufe auf. Sie können diesen Zyklus programmgesteuert unterbrechen, indem Sie StopTrack vom Rückruf zurückgeben.

Anwendungsbeispiele

Die Verwendung von kubedog als Bibliothek wird im dapp-Dienstprogramm angezeigt. Hier werden vorgefertigte Rollout-Tracker ausgeführt, um die von Helm erstellten oder aktualisierten Ressourcen zu überprüfen.

Kubedog CLI kann beim Rollout im CI / CD-System helfen , unabhängig davon, ob es verwendet wird: kubectl, Helm oder etwas anderes. Schließlich können Sie kubectl apply und dann kubedog rollout track , und Sie werden einen Fehler in den kubedog rollout track Protokollen sehen, wenn etwas mit der Ressource nicht stimmt. Diese Verwendung von Kubedog verkürzt die Zeit für die Diagnose von Rollout-Problemen.

Was weiter?

Wir planen, die Bibliothek so zu entwickeln, dass mehr Ressourcen unterstützt werden - zum Beispiel möchte ich Service and Ingress wirklich folgen. Darüber hinaus soll an der Klassifizierung der reason in Event'ah gearbeitet werden, um den Zeitpunkt genauer zu bestimmen, zu dem davon ausgegangen werden kann, dass der Rollout der Ressource fehlgeschlagen ist. Ein weiterer Vektor der Bibliotheksentwicklung ist die gleichzeitige Verfolgung mehrerer Ressourcen, beispielsweise nach labelSelector oder nach dem labelSelector . Ich möchte auch verschiedene Anmerkungen unterstützen, die die Art der Verfolgung ändern können, z. B. für Helm-Hooks. Dies ist jedoch für dapp noch relevanter.

In naher Zukunft wird der Schwerpunkt auf der Bibliothek liegen, aber auch für die CLI sind Verbesserungen geplant: bequemere Befehle und Flags, Färben von Protokollen, Meldungen zum Entfernen von Pods wie im Heck. Wir erwägen auch die Möglichkeit, einen interaktiven Modus mit einer Bereitstellungsstatustabelle und Ereignissen in einem Fenster und mit Protokollen in einem anderen Fenster zu erstellen.

Wie versuche ich es?

Die Kubedog-CLI-Builds für Linux und MacOS sind auf bintray verfügbar.

Ich freue mich sehr auf Ihr Feedback und Ihre Probleme auf GitHub !

PS

Lesen Sie auch in unserem Blog:

• " Kubebox und andere Konsolen-Shells für Kubernetes ";
• „ Einführung von Loghouse - ein Open-Source-System für die Arbeit mit Protokollen in Kubernetes “;
• "Wir vertreten offiziell dapp - DevOps-Dienstprogramm zur Unterstützung von CI / CD ";
• " Infrastruktur mit Kubernetes als erschwinglichem Service ."