{"id":35226,"date":"2019-10-31T22:03:05","date_gmt":"2019-10-31T19:03:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator\/"},"modified":"2019-10-31T22:03:05","modified_gmt":"2019-10-31T19:03:05","slug":"gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator","title":{"rendered":"Kubernetes-Cluster einfach und bequem einrichten? Wir k\u00fcndigen den Addon-Operator an","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-Cluster
\n
\nNach Shell-Operator<\/a><\/noindex> pr\u00e4sentieren wir seinen \u00e4lteren Bruder \u2014 Addon-Operator<\/a><\/noindex>. Dies ist ein Open-Source-Projekt, das verwendet wird, um systematische Komponenten in einem Kubernetes-Cluster zu installieren, die man allgemein als Erg\u00e4nzungen bezeichnen kann.<\/a><\/noindex><\/p>\n

Warum \u00fcberhaupt irgendwelche Erg\u00e4nzungen?<\/h2>\n

\nEs ist kein Geheimnis, dass Kubernetes kein fertiges All-in-One-Produkt ist, und um einen \u201eausgewachsenen\u201c Cluster aufzubauen, sind verschiedene Erg\u00e4nzungen erforderlich. Der Addon-Operator hilft dabei, diese Erg\u00e4nzungen zu installieren, zu konfigurieren und aktuell zu halten.<\/p>\n

Der Bedarf an zus\u00e4tzlichen Komponenten im Cluster wird in der Pr\u00e4sentation<\/a><\/noindex> der Kollegen driusha<\/a><\/noindex>. Kurz gesagt, die Situation mit Kubernetes ist derzeit so, dass man f\u00fcr eine einfache Installation zum \u201eAusprobieren\u201c mit den Standardkomponenten auskommen kann, f\u00fcr Entwickler und Testzwecke kann man Ingress hinzuf\u00fcgen, aber um eine vollst\u00e4ndige Installation zu haben, die man als \u201eIhre Produktion ist bereit\u201c bezeichnen kann, m\u00fcssen rund ein Dutzend verschiedener Erg\u00e4nzungen hinzugef\u00fcgt werden: etwas f\u00fcr Monitoring, etwas f\u00fcr Logs, Ingress und Cert-Manager nicht vergessen, Knoten-Gruppen abteilen, Netzwerkrichtlinien hinzuf\u00fcgen, mit sysctl-Einstellungen und Pod-Autoscaler w\u00fcrzen\u2026<\/p>\n

\"Kubernetes-Cluster
\n<\/p>\n

Was ist das Besondere an der Arbeit mit ihnen?<\/h2>\n

\nWie die Praxis zeigt, kommt es mit nur einer Installation nicht aus. F\u00fcr eine komfortable Arbeit mit dem Cluster m\u00fcssen Erg\u00e4nzungen aktualisiert, deaktiviert (aus dem Cluster entfernt) werden, und manches m\u00f6chte man m\u00f6glicherweise vor der Installation im Produktions-Cluster testen.<\/p>\n

Vielleicht reicht hier auch Ansible? M\u00f6glicherweise. Aber vollwertige Erg\u00e4nzungen leben in der Regel nicht ohne Anpassungen<\/b>. Diese Einstellungen k\u00f6nnen je nach Cluster-Variante (aws, gce, azure, bare-metal, do, \u2026) unterschiedlich sein. Einige Einstellungen k\u00f6nnen nicht im Voraus festgelegt werden \u2014 sie m\u00fcssen aus dem Cluster abgerufen werden. Und der Cluster ist nicht statisch: F\u00fcr einige Einstellungen muss man die \u00c4nderungen \u00fcberwachen. Hierf\u00fcr reicht Ansible nicht aus: Es wird ein Programm ben\u00f6tigt, das im Cluster lebt, d.h. ein Kubernetes Operator.<\/p>\n

Diejenigen, die es ausprobiert haben Shell-Operator<\/a><\/noindex>, werden sagen, dass die Aufgaben der Installation und Aktualisierung der Erg\u00e4nzungen sowie das \u00dcberwachen der Einstellungen mit Hilfe von Hooks<\/a><\/noindex> f\u00fcr den Shell-Operator durchaus gel\u00f6st werden k\u00f6nnen. Man kann ein Skript schreiben, das eine bedingte kubectl apply<\/code> ausf\u00fchrt und beispielsweise den ConfigMap \u00fcberwacht, wo die Einstellungen gespeichert werden. Genau so ist es im Addon-Operator implementiert.<\/p>\n

Wie ist es im Addon-Operator organisiert?<\/h2>\n

\nBei der Entwicklung einer neuen L\u00f6sung haben wir folgende Prinzipien zugrunde gelegt:<\/p>\n