Was ist das Kubernetes-Operator-Muster?

Als Softwareerweiterung zu Kubernetes funktionieren Operatoren, indem sie das Wissen eines menschlichen Bedieners erfassen. Ingenieure, die Kubernetes nutzen, haben eine einzigartige Perspektive darauf, wie Apps und Dienste sich verhalten sollten und wie sie reagieren, wenn Probleme auftreten. Diese gleichen Ingenieure automatisieren gerne wiederholbare Aufgaben – und das Operator-Pattern ist für diese Automatisierung unerlässlich. In diesem Artikel werde ich das Operator-Pattern beleuchten, einschließlich seiner Anwendung auf Kubernetes, wann man es nutzen sollte und einige Tools, die den Einstieg in die Erstellung eines Kubernetes erleichtern.

Verständnis des K8S-Operators

Mit einem Kubernetes-Operator kannst du eine stateful Application betreiben, indem du einen eigenen Controller mit domänenspezifischem Wissen schreibst. Wenn du neu bei Kubernetes bist, kann die Vorstellung eines Operators verwirrend sein, also schauen wir uns ein einfaches Beispiel an. Angenommen, du hast eine Java-App, die sich mit einer Datenbank verbindet. Du solltest diese auf deinem K8s-Cluster deployen. Idealerweise solltest du etwas wie eine "Deployment" für die mit einem Service bereitgestellte Java-App ausführen und für das Backend ein "Statefulset" für die Datenbankanwendung ausführen. Dieses Setup besteht aus zwei Teilen:

• Der stateless Teil, die Java-App
• Der zustandsbehaftete Teil, die Datenbank

Um einen Operator zu verstehen, denken Sie an den zustandsvollen Teil des Setups – die Datenbank oder jede Anwendung, die Daten speichert, wie etcd. In unserem Beispiel können wir das, was wir über die Beziehung der Anwendung wissen, auf die Datenbank anwenden und einen Controller erstellen, der bestimmte Dinge erledigt, wenn sich die Anwendung auf eine bestimmte Weise verhält. Site Reliability Engineers und Operational Engineers sind oft damit beauftragt oder daran interessiert, Dinge wie Backup, Updates, Datenwiederherstellung usw. zu automatisieren. Wie diese Aufgaben erledigt werden, variiert je nach Anwendung selbst und dem geschäftlichen Anwendungsfall (Domänenwissen). Genau das tun k8s-Operatoren: Sie handeln im Namen des Benutzers, wenn bestimmte Aufgaben ausgeführt werden müssen, die normalerweise ein SRE/Ops-Ingenieur erledigen muss.

Operatoren folgen K8S-Mustern

Operator basiert auf zwei zentralen Prinzipien von Kubernetes: einer benutzerdefinierten Ressource und einem benutzerdefinierten Controller.

Benutzerdefinierte Ressource

In Kubernetes ist eine Ressource ein Endpunkt in der k8s-API, der eine Reihe von API-Objekten eines bestimmten Typs speichert. Sie ermöglicht es uns, k8s zu erweitern, indem wir weitere Objekte einer Art zum Cluster hinzufügen. Danach können wir kubectl verwenden, um auf unser Objekt zuzugreifen, genau wie auf jedes andere eingebaute Objekt. Nehmen wir zum Beispiel einen Pod oder eine Deployment. Wenn Sie ein Manifest schreiben, müssen Sie einen Typ (Pod oder Deployment) in der yaml-Datei angeben. Eine benutzerdefinierte Ressource ist einfach eine Ressource, die nicht direkt mit k8s geliefert wird.

Benutzerdefinierter Controller

Ein Controller ist eine Steuerungsschleife, die den Cluster auf Änderungen an einer bestimmten Ressource (benutzerdefinierter Ressource) überwacht und sicherstellt, dass der aktuelle Zustand mit dem gewünschten Zustand übereinstimmt. Tatsächlich verwenden wir bereits eine Art Controller, die bereits in k8s integriert ist. Ein gutes Beispiel ist eine Deployment, bei der man einen Pod abschaltet und ein anderer startet. Der Controller sieht, dass die gewünschte Anzahl der Pods nicht mit dem aktuellen Zustand übereinstimmt, also startet er einen neuen, um den gewünschten Zustand zu erreichen. Warum werden diese eingebauten Controller also nicht Operatoren genannt? Weil diese Controller nicht spezifisch für eine bestimmte Anwendung sind; sie sind Upstream-Controller, die mit eingebauten Ressourcen wie Deployment, Jobs usw. verwendet werden.

Wann man einen Operator verwenden sollte

Es ist wichtig zu wissen, dass alle Bediener Controller sind, aber nicht alle Controller Operatoren sind. Damit ein Controller als Operator gilt, muss er über Anwendungsdomänenwissen verfügen, um automatisierte Aufgaben im Auftrag des Benutzers (SRE/Ops-Ingenieur) auszuführen.

• Verwenden Sie einen Operator, wann immer Sie Ihre zustandsbehaftete Anwendungs-Geschäftslogik mit der Kubernetes-API einkapseln müssen. Das ermöglicht eine Automatisierung rund um Ihre Anwendung, die in das k8s-Ökosystem integriert ist.
• Nutze einen Operator, wann immer du ein Tool bauen musst, das deine Anwendungen auf Änderungen überwacht und bestimmte SRE/Ops-Aufgaben ausführt, wenn bestimmte Dinge passieren.

Wie man einen Operator baut

Es gibt mehrere Möglichkeiten, einen Operator zu erstellen:

• ClientGo verbindet sich mit der Kubernetes-API.
  • Der Vorteil: Es nutzt die gleichen Ressourcen wie deine eingebauten Ressourcen, sodass du beruhigt sein kannst, dass der Code nach k8s-Standards getestet und versioniert ist.
  • Der Nachteil: Es gibt eine steile Lernkurve, wenn man die Programmiersprache Go nicht versteht.
• Kubebuilder, Teil der k8s sigs-Organisation, ist in go geschrieben und verwendet die Controller-Runtime.
• Das Operator SDK, ursprünglich von Core OS geschrieben und jetzt von RedHat betrieben, ist ein Framework, das mit Hilfsfunktionen ausgestattet ist, um Operatoren in Go, HEML oder Ansible zu erstellen.

Wie man einen Operator einsetzt

Sie können einen Operator auf zwei Arten einsetzen:

• Ich benutze yaml wie jedes andere Kubernetes-Manifest.
• Helm-Diagramm verwenden, um sowohl CRD als auch Controller als Paket bereitzustellen.

Best Practices zur Erstellung eines Operators

K8S-Controller sind für den Cluster selbst, und Operatoren sind Controller für Ihre bereitgestellten zustandsvollen Anwendungen. Beim Erstellen eines Operators folgen Sie diesen Best Pattern Practices:

• Nutzen Sie eingebaute Typen, um Ihre eigenen Typen zu erstellen. So nutzen Sie bereits getestete und bewährte Typen.
• Stelle sicher, dass kein weiterer externer Code benötigt wird, damit dein Controller funktioniert. Also sollte das Ausführen der kubectl-Installation ausreichen, um den Controller zu deployen.
• Wenn der Bediener gestoppt wird, stelle sicher, dass deine Anwendung weiterhin wie erwartet funktioniert.
• Verwenden Sie ausreichende Tests für Ihren Controller-Code.

Wenn Sie bereit sind, Ihre eigenen anwendungsspezifischen benutzerdefinierten Ressourcen zu erstellen, die mit Ihrem eigenen Controller abgestimmt werden können und so das normale Verhalten von Kubernetes erweitern können – sind Sie bereit, Operatoren zu nutzen.

Zusätzliche Ressourcen

Für mehr Informationen zu Kubernetes entdecken Sie diese Ressourcen:

• Kubernetes-Leitfaden mit 20+ Artikeln und Tutorials
• BMC DevOps Blog
• Bring Kubernetes in die serverlose Partei
• Wie eBay sein IT-Programm mit Kubernetes & Replatforming neu erfindet

DevOps-Leitfaden

1. Was ist DevOps? Eine umfassende Einführung
2. Eine kurze Geschichte von DevOps
3. Einführung in die DevOps-Architektur
4. Automatisierung in DevOps: Warum und wie man DevOps-Praktiken automatisiert
5. Was ist CI/CD? Kontinuierliche Integration und kontinuierliche Lieferung erklärt
6. Wie man eine CI/CD-Pipeline mit Jenkins aufbaut
7. DevOps-Metriken zur Optimierung von CI/CD-Pipelines
8. Kontinuierliche Liefermetriken
9. Ist Continuous Integration in Continuous Deployment ein Fortschritt – oder nicht?
10. Unterschiede zwischen Continuous Integration (CI), Delivery (CD) und Deployment
11. Quellcode und Versionskontrolle in DevOps
12. Was ist kontinuierliche Testung?
13. Testautomatisierungs-Frameworks: Der ultimative Leitfaden
14. Release Management in DevOps
15. Erklärt: Monitoring & Telemetrie in DevOps
16. Anwendungs-Leistungsmanagement in DevOps
17. DevOps-Orchestrierung im SDLC
18. Einführung in Datenbank-DevOps
19. Die Rolle der Microservices in DevOps
20. Die Rolle der Virtualisierung in DevOps
21. Container & DevOps: Wie Container in DevOps-Lieferpipelines passen
22. Was ist eine Containerpipeline?
23. Was ist eine DevOps-Toolchain?
24. Verwaltung von Containern und Code für DevOps
25. Die Rolle von Agile in DevOps
26. Die Rolle der Cloud in DevOps
27. Was ist FinDevOps?
28. Top-DevOps-Trends im Jahr 2022
29. DevOps-Werte & Prinzipien
30. DevOps-Kennzahlen und KPIs
31. DevOps-Ratschläge für kleine, mittlere und große Organisationen
32. DevOps-Teamstruktur
33. Top-DevOps-Bücher, die man heute lesen sollte
34. Buchrezension von The Phoenix Project: DevOps For Everyone
35. DevOps-Influencer: 11 DevOps-Experten, denen Sie auf Twitter folgen können
36. GitHub, GitLab, Bitbucket & Azure DevOps: Was ist der Unterschied?
37. Best Practices: Wie man Anwendungen für Kubernetes architekt
38. Konfigurationsmanagement in DevOps
39. DevOps-Verzweigungsstrategien erklärt
40. DevOps-Jobbezeichnungen, Rollen und Verantwortlichkeiten
41. Testen in DevOps: Konzepte, Best Practices und mehr
42. Der vollständige DevOps-Zertifizierungsleitfaden für 2022
43. Was ist das Kubernetes-Operator-Muster?

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.