{"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 vorbereiten? Wir stellen den Addon-Operator vor.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-Cluster
\n
\nNach shell-operator<\/a><\/noindex> Wir pr\u00e4sentieren seinen gro\u00dfen Bruder \u2014 addon-operator<\/a><\/noindex>. Es handelt sich um ein Open Source-Projekt, das zur Installation von Systemkomponenten in einem Kubernetes-Cluster verwendet wird, die wir allgemein als Erg\u00e4nzungen bezeichnen k\u00f6nnen.<\/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 f\u00fcr den Aufbau eines 'reifen' Clusters sind verschiedene Erg\u00e4nzungen erforderlich. Der Addon-Operator hilft dabei, diese Erg\u00e4nzungen zu installieren, zu konfigurieren und aktuell zu halten.<\/p>\n

Die Notwendigkeit zus\u00e4tzlicher Komponenten im Cluster wird in in seiner Pr\u00e4sentation<\/a><\/noindex> Kollegen driusha<\/a><\/noindex>deutlich. Kurz gesagt, die Situation bei Kubernetes ist derzeit so, dass man f\u00fcr eine einfache Installation zum Ausprobieren mit den Standardkomponenten auskommen kann, f\u00fcr Entwickler und Tester jedoch Ingress hinzuf\u00fcgen sollte. F\u00fcr eine vollst\u00e4ndige Installation, bei der man sagen kann 'Ihre Produktion ist bereit', m\u00fcssen etwa ein Dutzend verschiedener Erg\u00e4nzungen hinzugef\u00fcgt werden: etwas zur \u00dcberwachung, etwas f\u00fcr Logs, nicht vergessen Ingress und Cert-Manager, Knoten-Pools festlegen, Netzwerkrichtlinien hinzuf\u00fcgen, mit Sysctl-Einstellungen und einem Pod-Autoscaler w\u00fcrzen\u2026<\/p>\n

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

Was ist die spezielle Handhabung dieser Komponenten?<\/h2>\n

\nWie die Erfahrungen zeigen, bleibt es nicht bei einer einzigen Installation. F\u00fcr eine reibungslose Arbeit mit dem Cluster m\u00fcssen Erg\u00e4nzungen aktualisiert, deaktiviert (aus dem Cluster entfernt) werden, und einige m\u00f6chten vielleicht vor der Installation im Produktionscluster getestet werden.<\/p>\n

Aber reicht hier vielleicht Ansible aus? M\u00f6glicherweise. Doch vollst\u00e4ndige Erg\u00e4nzungen leben in der Regel nicht ohne Konfigurationen.<\/b>. Diese Einstellungen k\u00f6nnen je nach Cluster-Option (aws, gce, azure, bare-metal, do, \u2026) variieren. 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 im Auge behalten. Hier reicht Ansible nicht aus: Es braucht ein Programm, das im Cluster lebt, also einen Kubernetes Operator.<\/p>\n

Diejenigen, die es ausprobiert haben, shell-operator<\/a><\/noindex>, werden sagen, dass die Aufgaben der Installation und Aktualisierung von Erweiterungen und die \u00dcberwachung der Konfigurationen durchaus mit Hilfe von Hooks<\/a><\/noindex> f\u00fcr den Shell-Operator gel\u00f6st werden k\u00f6nnen. Man kann ein Skript schreiben, das eine bedingte kubectl apply<\/code> und beispielsweise \u00fcber ConfigMap wacht, wo die Konfigurationen gespeichert werden. Etwas \u00c4hnliches ist im addon-operator umgesetzt.<\/p>\n

Wie ist das im addon-operator organisiert?<\/h2>\n

\nBei der Erstellung einer neuen L\u00f6sung gingen wir von folgenden Grunds\u00e4tzen aus:<\/p>\n