Go-Operator
use create
deploye unsere Operatoren Schritt für Schritt.
Für diesen SDK-unterstützten Workflow bieten wir:
a) eine Beschreibung der generierten Operator-Struktur (es gibt eine für jeden spezifischen Workflow);
b) einen Link zu unseren Operator-Beispielen basierend auf einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.
c) Beschreibungen wie (z.B. 3rd-Party) Ressourcen, die sich vom Core Kubernetes Ressource-Typ unterscheiden, zum Operator hinzugefügt werden können
d) eine Beschreibung der wichtigsten Vor- und Nachteile der Verwendung einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.
a) Beschreibung der generierten Operator-Struktur (es gibt eine für jeden spezifischen Workflow)
Nachfolgend die Struktur eines generierten GO-Operators:
Datei/Ordner |
Zweck |
|---|---|
cmd |
Enthält
|
pkg/apis |
Enthält den Verzeichnisbaum, der die APIs der Custom Resource Definitions (CRD) definiert. Von den Benutzern wird erwartet, dass sie die Dateien
|
pkg/controller |
Dieser pkg enthält die Controller-Implementierungen. Von den Benutzern wird erwartet, dass sie die Datei
|
build |
Enthält das dockerfile und Build-Skripte, die zum Erstellen des Operators verwendet werden. |
deploy |
Enthält verschiedene YAML-Manifeste zur Registrierung von CRDs, zur Einrichtung von RBAC und zur Bereitstellung des Operators als Deployment. |
Gopkg.toml Gopkg.lock |
Die Go Dep Manifeste beschreiben die externen Abhängigkeiten dieses Operators. |
vendor |
Der golang vendor Ordner, der die lokalen Kopien der externen Abhängigkeiten enthält, die die Importe dieses Projekts erfüllen. Go Dep verwaltet den vendor direkt. |
Operator scope
Ein namespace-scoped Operator (der Standard) überwacht und verwaltet Ressourcen in einem einzigen Namespace, während ein cluster-scoped Operator Ressourcen clusterweit überwacht und verwaltet. Namespace-scoped Operators werden wegen ihrer Flexibilität bevorzugt. Sie ermöglichen entkoppelte Upgrades, Namespace Isolation für Fehler und Überwachung sowie unterschiedliche API Definitionen. Es gibt jedoch Anwendungsfälle, in denen ein cluster-scoped Operator sinnvoll sein kann. So wird beispielsweise der cert-manager Operator häufig mit cluster-scoped Berechtigungen und Überwachungen eingesetzt, um die Ausstellung von Zertifikaten für einen ganzen Cluster zu verwalten.
b) Beispiele von Operator(en) basierend auf einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.
Wir diskutieren zwei Beispiele eines GO-Operators:
1) Beispiel 1: Dieser Operator repliziert sich nur unter einem bestimmten Projekt
2) Beispiel 2: Dieser Operator erlaubt es, die Anzahl der Pods in einem Projekt zu manipulieren.
c) Wie 3rd Party Ressourcen (z.B. unterschiedlich zum Core Kubernetes Ressource-Typ) zum Operator hinzufügen
Der Operator-Manager unterstützt die Core Kubernetes Ressourcen-Typen, wie sie im client-go scheme („register.go„) Paket enthalten sind und registriert auch die Schemata aller benutzerdefinierten Ressourcen-Typen, die im Projekt definiert sind unter pkg/apis
import ( "github.com/example-inc/memcached-operator-long/pkg/apis" ...)// Setup Scheme for all resourcesif err := apis.AddToScheme(mgr.GetScheme()); err != nil { log.Error(err, "") os.Exit(1)} |
Um eine 3rd Party Ressource zu einem Operator hinzuzufügen, musst du sie zum managers scheme hinzufügen. Indem du eine AddToScheme Methode erstellst oder wiederverwendest, kannst du ganz einfach eine Ressource zu deinem Schema hinzufügen. Ein Beispiel zeigt, dass du eine Funktion definierst und dann mit dem runtime Paket nutzt, um einen SchemeBuilder zu erstellen.
Registriere dich mit dem Managers Schema
Rufe die AddToScheme() Funktion auf für deine 3rd Party Ressource und übergebe sie in das Manager-Schema über mgr.GetScheme().
Beispiel:
import ( .... routev1 "github.com/openshift/api/route/v1")func main() { .... if err := routev1.AddToScheme(mgr.GetScheme()); err != nil { log.Error(err, "") os.Exit(1) } ....} |
„Nachdem du deinem Operator-Projekt neue Importpfade hinzugefügt hast, führe dep ensure im root-Verzeichnis deines Projektes aus, um die Abhängigkeiten zu erfüllen.“.
$ dep ensure |
d) Eine Beschreibung der wichtigsten Vor- und Nachteile bei der Verwendung dieser Operatorstruktur (es gibt eine für jeden spezifischen Workflow) und Logik;
Vorteile (+) und Nachteile (-):
(+) Es ist einfach zu bedienen und erstellt einen einfachen Operator.
Das Hauptprogramm für den Operator cmd/manager/main.go initialisiert und führt den manager aus. Der Manager registriert automatisch das Schema für alle custom resource definiert unter pkg/apis/... und führt alle Controller aus unter pkg/controller/....
Der Manager kann den Namespace einschränken, den alle Controller auf Ressourcen überwachen:
mgr, err := manager.New(cfg, manager.Options{Namespace: namespace})
Standardmässig ist dies der Namespace, in dem der Operator läuft. Um alle Namespaces zu sehen, lassen Sie die Option namespace leer:
mgr, err := manager.New(cfg, manager.Options{Namespace: ""})
(+) genügend klare Möglichkeit, Ressourcen von 3rd Parties (d.h. anders als die Core Kubernetes Ressourcen-Typen) zum Operator hinzuzufügen.
(-) es ist immer noch instabil/Änderungen der APIs und die zukünftigen Versionen davon könnten nicht unterstützt werden (wir beobachten diese Entwicklung und aktualisieren den Blogbeitrag entsprechend).
Damit der Operator funktioniert, mussten wir einige Issues in Github öffnen (die geschlossen und als Fehler eingestuft wurden):
https://github.com/operator-framework/operator-sdk/issues/651
https://github.com/operator-framework/operator-sdk/issues/927
https://github.com/operator-framework/operator-sdk/issues/1053
(-) Der Workflow zur Erstellung der GO-Operatoren erscheint etwas komplexer/unklar (Schritte in rot) als der mit Ansible und Helm generierte (die weniger Schritte erfordern):
- Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
- Definiere neue Ressource-APIs durch Hinzufügen von Custom Resource Definitions (CRD)
- Definiere Controller zur Überwachung und Abstimmung von Ressourcen
- Schreibe die Abstimmungslogik für deinen Controller mit Hilfe des SDK und Controller-Runtime APIs
- Verwende das SDK CLI Operator-Deployment-Manifest zum builden und generieren
Zurück zur Übersicht
Zurück zur Übersicht Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows.
