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:

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

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:

„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.“.

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):

1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
2. Definiere neue Ressource-APIs durch Hinzufügen von Custom Resource Definitions (CRD)
3. Definiere Controller zur Überwachung und Abstimmung von Ressourcen
4. Schreibe die Abstimmungslogik für deinen Controller mit Hilfe des SDK und Controller-Runtime APIs
5. 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.

Dieser Blogbeitrag ist Teil der Serie Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.
IN FRÜHEREN BLOG-POSTS HABEN WIR ÜBER DIE FOLGENDEN THEMEN GESPROCHEN:
Abschnitt 1 – Operatoren, Operatoren-Framework und Operatoren-SDK

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

Abschnitt 2 – Unterstützte Kubernetes Operatoren-SDK Workflows

• Hier werden die drei verfügbaren alternativen Workflows zur Generierung von Operatoren erläutert, die von den letzten Versionen der Operatoren-SDK APIs bereitgestellt werden.
• Wir besprechen auch Vor- und Nachteile der Nutzung der verschiedenen Operatoren-Workflows.

IN DIESEM BEITRAG SPRECHEN WIR ÜBER:
Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows

• Hier zeigen wir Beispiele für die drei verfügbaren alternativen Workflows zur Generierung von Operatoren, die von den Operatoren-SDK APIs bereitgestellt werden.
• Wir konzentrieren uns speziell auf Go-Operatoren, da sie unserer Meinung nach die stabileren verfügbaren APIs sind.

Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows

Wir werden folgendes anschauen:
1) Operator: Go-Operator
2) Operator: Ansible-Operator [in Kürze verfügbar]
3) Operator: Helm-Operator [in Kürze verfügbar]
 
Für jeden dieser SDK-unterstützten Workflows bieten wir:
a) eine Beschreibung der generierten Operator-Struktur (es gibt eine für jeden spezifischen Workflow);
b) einen Link zu unserem/unseren Beispiel(en) von Operator(en), die auf einer solchen Operator-Struktur basieren (es gibt eine für jeden spezifischen Workflow) und Logik.
c) Beschreibungen, wie man solche (3rd Party) Ressourcen hinzufügt, die sich von den Core-Kubernetes-Ressourcentypen unterscheiden, zu deinem Operator 
d) eine Beschreibung der wichtigsten Vor- und Nachteile der Verwendung einer solchen Operator-Struktur (es gibt eine für jeden spezifischen Workflow) und Logik.

Zurück zur Übersicht

Zurück zur Übersicht Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.

Dieser Blogbeitrag ist Teil der Serie Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.
IN FRÜHEREN BLOG-POSTS HABEN WIR ÜBER DIE FOLGENDEN THEMEN GESPROCHEN:
Abschnitt 1 – Operatoren, Operatoren-Framework und Operatoren-SDK

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

IN DIESEM BEITRAG SPRECHEN WIR ÜBER:
Abschnitt 2 – Unterstützte Kubernetes Operatoren-SDK Workflows

• Hier werden die drei verfügbaren alternativen Workflows zur Generierung von Operatoren erläutert, die von den letzten Versionen der Operatoren-SDK APIs bereitgestellt werden.
• Wir besprechen auch Vor- und Nachteile der Nutzung der verschiedenen Operatoren-Workflows.

Abschnitt 2 – Unterstützte Operatoren-SDK Workflows

Wie bereits erwähnt, ist das Operator SDK auf GitHub ein sehr aktives Projekt, mit über 10 Releases, die in weniger als einem Jahr produziert wurden. Dies bedeutet, dass das Operator-SDK ein Toolkit ist, das sich im Laufe der Zeit weiterentwickelt (z.B. ändert sich sein Code, seine Struktur und Logik). Insbesondere, wie auf der Github-Hauptseite des Operator-SDK berichtet, sind die Bibliotheken und Tools mit „Projektstatus: pre-alpha“ gekennzeichnet und damit „signifikante Änderungen an der API in den kommenden Releases erwartet werden“.
Das Projekt startete im April 2018 und wir begannen es ab September 2018 intensiv zu beobachten. Wir haben herausgefunden, dass das SDK drei verschiedene Workflows zur Verfügung stellt, um Operatoren basierend auf Go, Ansible, oder Helm zu entwickeln.
Diese Versionen des Operators SDK sind zwischen 2018 und 2019 entstanden. Konkret basierte die erste Version des Operators auf Go und erst ab Dezember 2018 wurde eine Version auf Ansible bereitgestellt.
Schliesslich wurde Anfang 2019 (im Januar) auch der Operator-Workflow auf Basis von Helm freigegeben.
Somit bietet das SDK einen Workflow zur Entwicklung von Operatoren auf Basis von Go, Ansible, oder Helm.
Der folgende Workflow gilt für einen neuen Go-Operator:

1. 1. 1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
      2. Definition neuer Ressourcen-APIs durch Hinzufügen von Custom Resource Definitions (CRD).
      3. Definition von Controllern zur Überwachung und Abstimmung von Ressourcen.
      4. Schreibe die Abstimmlogik für den Controller über das SDK und die Controller-Laufzeit-APIs.
      5. Verwende das SDK CLI, um die Operator Deployment Manifeste zu erstellen und zu generieren.

Der folgende Workflow gilt für einen neuen Ansible-Operator:

1. 1. 1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
      2. Schreibe die Abstimmungslogik für das Objekt mit Hilfe von Ansible Playbooks und Rollen.
      3. Verwende das SDK CLI, um die Operator Deployment Manifeste zu erstellen und zu generieren.
      4. Optional kannst du mit Hilfe des SDK CLI weitere CRD’s hinzufügen und die Schritte 2 und 3 wiederholen.

Der folgende Workflow gilt für einen neuen Helm-Operator:

1. 1. 1. Erstelle ein neues Operator-Projekt mit Hilfe des SDK Command Line Interface (CLI).
      2. Erstelle ein neues (oder füge ein bestehendes) Helm-Chart hinzu, das von der Abstimmungslogik des Operators verwendet wird.
      3. Verwende das SDK CLI, um die Operator Deployment Manifeste zu erstellen und zu generieren.
      4. Optional kannst du mit Hilfe des SDK CLI weitere CRD’s hinzufügen und die Schritte 2 und 3 wiederholen.

Richtlinien:
Command Line Interface: Um mehr über den SDK CLI zu erfahren, lese die SDK CLI Reference, oder führe operator-sdk [command] -h aus.
Eine Anleitung zu Reconcilers, Clients, und Interaktion  mit Ressourcen-Events, siehe Client API doc.
Wie aus der folgenden Abbildung ersichtlich, gibt es keinen grossen Unterschied zwischen den verschiedenen Operator-Workflows.
Der Workflow, der die höchste Reife erreicht hat und mehr Kontrolle über das Verhalten des Operator bietet, ist der auf Go basierende:

Nächster Artikel

Abschnitt 3 – Beispiele für unterstützte Operatoren-SDK Workflows

Zurück zur Übersicht

Zurück zur Übersicht Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.

Einführung in Kubernetes Operatoren, das Operatoren-Framework und Operatoren-SDK

Dieser Blogbeitrag ist Teil der Serie Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.
Abschnitt 1 – Kubernetes Operatoren, Operatoren-Framework und Operatoren-SDK:

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

Abschnitt 1 – Kubernetes Operatoren, Operatoren-Framework und Operatoren-SDK:

a) Operatoren sind Kubernetes-Applikationen.
Eine Kubernetes-Applikation ist eine Applikation, die sowohl auf Kubernetes bereitgestellt als auch über die Kubernetes-APIs und kubectl-Tools verwaltet wird. Um Kubernetes optimal nutzen zu können, benötigst du eine Reihe zusammenhängender APIs, die erweitert werden müssen, um deine Kubernetes-Applikationen, zu warten und zu verwalten. Man kann sich Operatoren als die „Runtime vorstellen, die diese Art von Applikation auf Kubernetes verwaltet“.
Somit ist ein Operator eine Methode zum Packaging, Deployen and Verwalten einer Kubernetes-Applikation. Konzeptionell nimmt ein Operator menschliches Betriebswissen auf und kodiert es in Software, die leichter verpackt und mit den Consumern geteilt werden kann. Wir können uns einen Operator als eine Erweiterung des Engineering-Teams des Softwareanbieters vorstellen, der über die Kubernetes-Umgebung wacht und seinen aktuellen Zustand nutzt, um Entscheidungen in Millisekunden zu treffen. Operatoren folgen einem [Reifegradmodell] von der Basis- bis zur spezifischen Logik für eine Anwendung.
Wir haben in den letzten Jahren gesehen, dass sich die Fähigkeiten der Operatoren in ihrer Komplexität unterscheiden, je nachdem, wie viel Intelligenz in die Implementierungslogik des Operators selbst eingebracht wurde. Wir haben auch erfahren, dass die Erstellung eines Operators typischerweise mit der Automatisierung der Installations- und Self-Service-Funktionen einer Anwendung beginnt und sich dann weiterentwickelt, um je nach Anwendungsfall eine komplexere Automatisierung zu übernehmen. Daher sind fortgeschrittene Operatoren heute so konzipiert, dass sie Upgrades nahtlos handhaben, automatisch auf Ausfälle reagieren und keine Shortcuts nehmen, wie das Überspringen eines Software-Backup-Prozesses, um Zeit zu sparen.
b) Operatoren-Framework
Operatoren sind Kubernetes-native Applikationen, die die Verwaltung komplexer stateful Applikationen auf Kubernetes erleichtern, aber das Schreiben solcher Operatoren kann aufgrund von Herausforderungen wie (i) der Verwendung von Low-Level-APIs und (ii) mangelnder Modularität, die zu Duplication, Inkonsistenzen und unerwartetem Verhalten führt, sehr schwierig sein.
Um diesem Problem zu begegnen, werden derzeit mehrere Tools (z.B. das Operatoren-Framework, Kooper, Metacontroller, etc.) als Ergebnis jahrelanger Arbeit und Erfahrung der Red Hat, Kubernetes und CoreOS Open-Source-Communities bei der Erstellung von Operatoren eingeführt. Insbesondere Red Hat und die Kubernetes Open-Source-Community teilten sich das Operator Framework – ein Open-Source-Toolkit, das entwickelt wurde, um Operatoren effektiver, automatisierter und skalierbarer zu verwalten.
Das Operatoren-Framework  ist ein Open-Source-Toolkit, das aus mehreren low-level APIs besteht. Wir glauben, dass das neue Operatoren-Framework den nächsten grossen Schritt für Kubernetes darstellt, indem es eine Basis führender Praktiken verwendet, um die Barriere für die Anwendungsentwicklung auf Kubernetes zu verringern. Das Projekt bietet ein Software Development Kit (SDK) und die Möglichkeit, App-Installationen und -Aktualisierungen mithilfe des Lifecycle-Management-Mechanismus zu verwalten, während Administratoren die Operatoren-Funktionen in jedem Kubernetes-Cluster nutzen können.
Das Operatoren-Framework beinhaltet:

• • Operatoren-SDK: Ermöglicht es Entwicklern, Operatoren auf der Grundlage ihrer Fachkenntnisse zu erstellen, ohne dass Kenntnisse über die Komplexität der Kubernetes-API erforderlich sind.
  • Operatoren-Lifecycle-Management: Überwacht die Installation, Aktualisierung und Verwaltung des Lebenszyklus aller Operatoren (und der damit verbundenen Dienste), die über einen Kubernetes-Cluster laufen. Einmal gebaut, müssen die Operatoren auf einem Kubernetes-Cluster deployed werden. Der Operator-Lifecycle-Manager ist die Backplane, die die Verwaltung von Operatoren auf einem Kubernetes-Cluster erleichtert. Damit können Administratoren steuern, welche Operatoren in welchen Namespaces verfügbar sind und wer mit laufenden Operatoren interagieren kann. Sie können auch den gesamten Lebenszyklus der Operatoren und ihrer Ressourcen verwalten, z.B. Aktualisierungen für einen Operator und seine Ressourcen auslösen.
  • Operatoren-Metering (folgt in den kommenden Monaten): Ermöglicht Nutzungsberichte für Operatoren, die spezielle Dienste bereitstellen. In einer zukünftigen Version wird das Operatoren-Framework auch die Möglichkeit beinhalten, die Anwendungsnutzung zu messen – ein Kubernetes first, das Erweiterungen für zentrale IT-Teams zum Budgetieren und für Softwareanbieter, die kommerzielle Software anbieten, bietet. Operatoren-Metering wurde entwickelt, um in die CPU- und Speicherberichte des Clusters eingebunden zu werden, IaaS-Kosten zu berechnen und kundenspezifische Kennzahlen wie Lizenzierung zu berechnen.

Einfache, stateless Applikationen können die Lifecycle-Management-Funktionen des Operatoren-Frameworks nutzen ohne Code zu schreiben, indem sie einen generischen Operator (z.B. den Helm Operator) verwenden. Komplexe und stateful Applikationen sind jedoch der Ort, an dem ein Operator glänzen kann. Die cloud-ähnlichen Funktionen, die in den Operator-Code kodiert sind, können eine erweiterte Benutzererfahrung bieten und Funktionen wie Updates, Backups und Skalierung automatisieren.
Im nächsten Unterabschnitt diskutieren wir über das Operatoren-SDK, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.
c) Popularität des Operatoren-SDK
Das Operatoren-SDK ist ein Toolkit, das kürzlich auf dem Operatoren-Framework aufgebaut wurde und die Werkzeuge zum Erstellen, Testen und Verpacken von Operatoren bereitstellt. Zunächst erleichterte das SDK die Verbindung der Businesslogik einer Anwendung (z.B. wie man skaliert, aktualisiert oder sichert) mit der Kubernetes-API, um diese Operationen auszuführen. Im Laufe der Zeit entwickelt sich das SDK jedoch weiter, so dass Entwickler Anwendungen intelligenter gestalten und die Benutzerfreundlichkeit von Cloud Services nutzen können. Infolgedessen sind führende Praktiken und Codemuster, die von allen Operatoren gemeinsam genutzt werden im SDK enthalten, um zu verhindern, dass das Rad neu erfunden wird.
Aus Entwicklersicht ist der Einstiegspunkt das Operatoren-SDK, das von CoreOS stammt und als Teil des Operatoren-Frameworks angeboten wird und nach seiner Selbstbeschreibung „ein Open-Source-Toolkit ist, um Kubernetes native Anwendungen, sogenannte Operatoren, effektiv, automatisiert und skalierbar zu verwalten“. Das SDK richtet sich spezifisch an Go-Entwickler und Applikationen und selbst wenn derzeit die Unterstützung für andere Programmiersprachen (z.B. Java, C, etc.) fehlt, gibt es bereits Zukunftspläne für deren Integration.
In GitHub wird das Operatoren-SDK zu einem sehr aktiven Projekt, das bereits eine hohe Sichtbarkeit/Popularität erlangt hat:

• • über 200 Entwickler, die ihre Entwicklungen in GitHub geforkt haben, die meisten von ihnen spielen/erweitern einige einfache Beispiele von Operatoren;
  • ca. 1000 commits seit dem ersten Release (5. April 2018).
  • über 10 Releases die in weniger als einem Jahr produziert wurden.
  • eine zunehmende Anzahl von GitHub Issues, die in den letzten Monaten von anderen Mitwirkenden geöffnet wurden.
    • [einige wurden auch von uns geöffnet, siehe https://github.com/operator-framework/operator-sdk/issues/651 und https://github.com/operator-framework/operator-sdk/issues/927]
  • mit über 1200 Sternen ist es eines der beliebtesten/trending Go-Projekten auf Github https://github.com/trending/go?since=monthly

Selbst wenn das Projekt mit der Zeit immer beliebter wird, ist sein Projektstatus immer noch „pre-alpha“, was bedeutet, dass „signifikante Änderungen an der API in den kommenden Versionen erwartet werden„.
Daher erfordert das Operatoren-SDK Toolkit noch ein wenig mehr Reife, um in breiteren praktischen Arbeitsszenarien eingesetzt zu werden. Als Forscher glauben wir, dass dieses Software Development Kit (SDK) in Zukunft weit verbreitet sein wird, da es die Entwickler bei der Verwaltung von App-Installationen und -Updates mit Hilfe des Lifecycle-Management-Mechanismus unterstützen wird, während es Administratoren ermöglicht, die Operator-Fähigkeiten auf jedem Kubernetes-Cluster auszuüben (siehe folgende Abbildung, die die Gesamtansicht der geplanten Unterstützung des Operator-SDKs verdeutlicht).

Im Folgenden sprechen wir über den allgemeinen Workflow des Operatoren-SDK.
d) Allgemeiner Workflow von Operatoren-SDK
Das Operatoren-SDK  ist ein Toolkit, das die Werkzeuge zum Erstellen, Testen und Verpacken von Operatoren bereitstellt, wie in der folgenden Abbildung dargestellt.

Insbesondere stellt das Toolkit den folgenden spezifischen Workflow zur Verfügung, um das Schreiben, Erstellen, Testen und Paketieren eines neuen Go-Operators zu unterstützen:

1. 1. 1. Erstelle ein neues Operatoren-Projekt mit Hilfe des SDK Command Line Interface (CLI)
      2. Definition neuer Ressourcen-APIs durch Hinzufügen von Custom Resource Definitions (CRD)
      3. Definition von Controllern zur Überwachung und Abstimmung von Ressourcen
      4. Schreibe die Abstimmlogik für deinen Controller mit dem SDK und der Controller-Laufzeit-APIs
      5. Verwende das SDK CLI um die Operatoren-Deployment-Manifeste zu erstellen und zu generieren

In diesem Zusammenhang verwendet das Operator-SDK für seinen Workflow die controller-runtime library, die das Schreiben von Operatoren erleichtert durch Bereitstellung von:

• • • High level APIs und Abstraktionen, um die operationale Logik intuitiver zu schreiben.
    • Tools für Scaffolding und Codegenerierung, um ein neues Projekt zu bootstrappen.
    • Erweiterungen zur Abdeckung gängiger Anwendungsfälle von Operatoren.

Ein einfaches Beispiel für die Erstellung und Bereitstellung eines einfachen Operators mit dem SDK-Toolkit findest du im offiziellen Operatoren-SDK GitHub-Repository:
https://github.com/operator-framework/operator-sdk
Der daraus resultierende automatisch generierte GO-Operator stellt die folgende Referenzstruktur dar:

Im nächsten Blogbeitrag werden wir über den aktuellen Status des Operatoren-SDKs sprechen, z.B. verfügbare Versionen und Workflows.

Nächster Artikel

Abschnitt 2 – Unterstützte Operatoren-SDK Workflows

Zurück zur Übersicht

Zurück zur Übersicht Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln.

Kubernetes Operatoren mit dem Operatoren SDK Framework entwickeln

Kubernetes hat sich zu einer omnipräsenten Plattform für das Hosting von Cloud-native Applikationen entwickelt. Als eher Low-Level-Plattform wird sie oft entwicklerfreundlich gemacht, indem sie in übergeordnete Plattformen wie OpenShift (OKD) verpackt und in eine Managed Service Plattform wie APPUiO umgewandelt wird, die in jede Cloud-Infrastruktur deployed werden kann. Applikationsentwickler interagieren mit Kubernetes hauptsächlich, indem sie geeignete Deployment-Deskriptoren erstellen und ihren Code, der die Deployments auslöst, forcieren. Aufgrund ständiger Funktionserweiterungen ist nicht so viel über nützliche Kombinationen von Annotationen auf Kubernetes-Deployments (und anderen deklarativ beschriebenen Objekten), Kubernetes-Operatoren (eine Art von Hooks) und Custom Resource Definitions bekannt
In dieser Beitragsserie teilen wir einige der Erfahrungen, die wir bei der Erforschung von Massnahmen zur Auslösung von Aktionen bei bestimmten Updates der Deskriptoren gesammelt haben, als Vorläufer dynamischer und autonomer Feedback-Loops, die die Deployments von Applikationen selbst verwalten können.
Insbesondere bieten wir Zugang zu den angepassten Originalbeispielen von Operatoren, die mit dem Operator SDK-Toolkit generiert wurden, die sich mit Kubernetes-Ressourcen befassen, indem sie Annotationen zu Kubernetes-Deployments und Kubernetes-Operator Konzepten kombinieren. Der Link zu unseren Operator Beispielen ist auf Github verfügbar: https://github.com/appuio/operator-sdk-examples. In weiteren Blog-Posts werden wir einige beschreiben und diskutieren, wie sie für eine fortgeschrittenere Entscheidungsfindung erweitert werden können. Insbesondere die Anpassung der (Go)-Operatoren, damit sie in verschiedenen Umgebungen funktionieren, erfordert die Änderung einiger wichtiger Go-Dateien (z.B. pkg/controller/memcached/memcached/memcached_controller.go wie in der folgenden Abbildung dargestellt).

IN WEITEREN BLOG-POSTS SPRECHEN WIR ÜBER

Abschnitt 1 – Kubernetes Operatoren, Operatoren-Framework und Operatoren-SDK

• Hier diskutieren wir in einem allgemeinen Rahmen über Operatoren, Operatoren-Framework und Operatoren-SDK.
• Dann werden wir über das Operatoren-SDK diskutieren, das in GitHub immer beliebter wird und im Allgemeinen über den „Operatoren-SDK Workflow“, der für die Generierung und Handhabung von Operatoren verwendet wird.

Abschnitt 2 – Unterstützte Kubernetes Operatoren-SDK Workflows

• Hier werden die drei verfügbaren alternativen Workflows zur Generierung von Operatoren erläutert, die von den letzten Versionen der Operatoren-SDK APIs bereitgestellt werden.
• Wir besprechen auch Vor- und Nachteile der Nutzung der verschiedenen Operatoren-Workflows.

Abschnitt 3 – Beispiele für unterstützte Kubernetes Operatoren-SDK Workflows

• Hier zeigen wir Beispiele für die drei verfügbaren alternativen Workflows zur Generierung von Operatoren, die von den Operatoren-SDK APIs bereitgestellt werden.
• Wir konzentrieren uns speziell auf Go-Operatoren, da sie unserer Meinung nach die stabileren verfügbaren APIs sind.

Abschnitt 4 – Beispiel(e) von Operatoren, die Dienste mit Prometheus monitoren (in Kürze verfügbar)

• Hier zeigen wir ein Beispiel für einen Operator, der mit Prometheus (derzeit zur Überwachung von Kubernetes-Clustern eingesetzt) kommuniziert, um fortgeschrittenere Entscheidungen zu treffen (z.B. erweiterte Überwachung des Dienstes).

Über die Autoren

Diese Beitragsserie wurde von Dr. Josef Spillner und Dr. Sebastiano Panichella von der ZHAW (Zürcher Hochschule für Angewandte Wissenschaften) School of Engineering geschrieben. Vielen Dank an Josef und Sebastiano, dass sie ihr Wissen mit unseren Lesern teilen!