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.

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 GoAnsible, 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 GoAnsible, oder Helm.

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

      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. 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. 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 Referenceoder 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:

Go-Operator-building-simplified-with-SDK_VSHN

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.