Der Kern der Geschichte über den beliebtesten Paketmanager für Kubernetes könnte mit einem Emoji dargestellt werden:
- die Box ist Helm (was der neuesten Emoji-Version am nächsten kommt);
- Schloss - Sicherheit;
- Der kleine Mann ist die Lösung des Problems.
Tatsächlich wird alles etwas komplizierter sein und die Geschichte ist voller technischer Details So machen Sie Helm sicher.
- Kurz gesagt, was Helm ist, falls Sie es nicht wussten oder vergessen haben. Welche Probleme löst es und wo befindet es sich im Ökosystem?
- Schauen wir uns die Helm-Architektur an. Kein Gespräch über Sicherheit und wie man ein Tool oder eine Lösung sicherer macht, ist vollständig, ohne die Architektur der Komponente zu verstehen.
- Lassen Sie uns Helm-Komponenten besprechen.
- Die brennendste Frage ist die Zukunft – die neue Version von Helm 3.
Alles in diesem Artikel gilt für Helm 2. Diese Version befindet sich derzeit in Produktion und ist höchstwahrscheinlich die, die Sie derzeit verwenden, und es ist die Version, die die Sicherheitsrisiken birgt.
Über den Sprecher: Alexander Khayorov () entwickelt seit 10 Jahren und hilft dabei, Inhalte zu verbessern und trat dem Ausschuss bei . Jetzt arbeitet er bei Chainstack als Entwicklungsleiter – eine Mischung aus einem Entwicklungsmanager und einer Person, die für die Bereitstellung endgültiger Releases verantwortlich ist. Das heißt, es befindet sich auf dem Schlachtfeld, wo alles von der Entwicklung eines Produkts bis zu seinem Betrieb geschieht.
Chainstack ist ein kleines, aktiv wachsendes Startup, dessen Mission es ist, Kunden zu ermöglichen, die Infrastruktur und Komplexität des Betriebs dezentraler Anwendungen zu vergessen; das Entwicklungsteam befindet sich in Singapur. Bitten Sie Chainstack nicht darum, Kryptowährungen zu verkaufen oder zu kaufen, sondern bieten Sie an, über Enterprise-Blockchain-Frameworks zu sprechen, und man wird Ihnen gerne antworten.
Helm
Dies ist ein Paket-(Diagramm-)Manager für Kubernetes. Die intuitivste und universellste Möglichkeit, Anwendungen in einen Kubernetes-Cluster zu bringen.
Wir sprechen natürlich von einem eher strukturellen und industriellen Ansatz als der Erstellung eigener YAML-Manifeste und dem Schreiben kleiner Dienstprogramme.
Helm ist das Beste, was derzeit verfügbar und beliebt ist.
Warum Helm? Vor allem, weil es von der CNCF unterstützt wird. Cloud Native ist eine große Organisation und die Muttergesellschaft für Projekte wie Kubernetes, etcd, Fluentd und andere.
Eine weitere wichtige Tatsache ist, dass Helm ein sehr beliebtes Projekt ist. Als ich im Januar 2019 begann, darüber zu sprechen, wie man Helm sicher machen kann, hatte das Projekt tausend Sterne auf GitHub. Bis Mai waren es 12.
Viele Menschen interessieren sich für Helm. Selbst wenn Sie es also noch nicht verwenden, profitieren Sie davon, über seine Sicherheit Bescheid zu wissen. Sicherheit ist wichtig.
Das Helm-Kernteam wird von Microsoft Azure unterstützt und ist daher im Gegensatz zu vielen anderen ein recht stabiles Projekt. Die Veröffentlichung von Helm 3 Alpha 2 Mitte Juli zeigt, dass ziemlich viele Leute an dem Projekt arbeiten und den Wunsch und die Energie haben, Helm zu entwickeln und zu verbessern.
Helm löst mehrere grundlegende Probleme der Anwendungsverwaltung in Kubernetes.
- Anwendungsverpackung. Selbst eine Anwendung wie „Hello, World“ auf WordPress besteht bereits aus mehreren Diensten, die Sie bündeln möchten.
- Bewältigung der Komplexität, die mit der Verwaltung dieser Anwendungen einhergeht.
- Ein Lebenszyklus, der nicht endet, nachdem die Anwendung installiert oder bereitgestellt wurde. Es lebt weiter, es muss aktualisiert werden, und Helm hilft dabei und versucht, die richtigen Maßnahmen und Richtlinien dafür zu ergreifen.
Absacken Es ist übersichtlich organisiert: Es gibt Metadaten, die vollständig der Arbeit eines regulären Paketmanagers für Linux, Windows oder MacOS entsprechen. Das heißt, ein Repository, Abhängigkeiten von verschiedenen Paketen, Metainformationen für Anwendungen, Einstellungen, Konfigurationsfunktionen, Informationsindizierung usw. Mit Helm können Sie all dies für Anwendungen abrufen und verwenden.
Komplexitätsmanagement. Wenn Sie viele Anwendungen desselben Typs haben, ist eine Parametrisierung erforderlich. Daraus entstehen Vorlagen, aber um nicht selbst eine eigene Methode zum Erstellen von Vorlagen entwickeln zu müssen, können Sie das verwenden, was Helm standardmäßig bietet.
Anwendungslebenszyklusmanagement - Meiner Meinung nach ist dies die interessanteste und ungelösteste Frage. Aus diesem Grund bin ich damals nach Helm gekommen. Wir mussten den Anwendungslebenszyklus überwachen und wollten unsere CI/CD- und Anwendungszyklen auf dieses Paradigma umstellen.
Mit Helm können Sie:
- Verwaltung von Bereitstellungen, Einführung in das Konzept der Konfiguration und Überarbeitung;
- Rollback erfolgreich durchführen;
- Verwenden Sie Hooks für verschiedene Ereignisse.
- Fügen Sie zusätzliche Anwendungsprüfungen hinzu und reagieren Sie auf deren Ergebnisse.
Zudem Helm hat „Batterien“ - eine große Anzahl leckerer Dinge, die in Form von Plugins eingebunden werden können und Ihr Leben vereinfachen. Plugins können unabhängig voneinander geschrieben werden, sie sind ziemlich isoliert und erfordern keine harmonische Architektur. Wenn Sie etwas implementieren möchten, empfehle ich, es als Plugin zu machen und es dann möglicherweise in den Upstream einzubinden.
Helm basiert auf drei Hauptkonzepten:
- Diagramm-Repo – Beschreibung und Reihe möglicher Parametrisierungen für Ihr Manifest.
- Config – das sind die Werte, die angewendet werden (Text, numerische Werte usw.).
- Loslassen sammelt die beiden oberen Komponenten und zusammen werden sie zu Release. Releases können versioniert werden, wodurch ein organisierter Lebenszyklus erreicht wird: klein zum Zeitpunkt der Installation und groß zum Zeitpunkt des Upgrades, Downgrades oder Rollbacks.
Helmarchitektur
Das Diagramm stellt konzeptionell die High-Level-Architektur von Helm dar.
Ich möchte Sie daran erinnern, dass Helm etwas mit Kubernetes zu tun hat. Daher können wir auf einen Kubernetes-Cluster (Rechteck) nicht verzichten. Die kube-apiserver-Komponente befindet sich auf dem Master. Ohne Helm haben wir Kubeconfig. Helm bringt ein kleines Binärprogramm mit, wenn man es so nennen kann, das Helm-CLI-Dienstprogramm, das auf einem Computer, Laptop, Mainframe – auf allem – installiert wird.
Aber das reicht nicht aus. Helm verfügt über eine Serverkomponente namens Tiller. Es vertritt die Interessen von Helm innerhalb des Clusters; es ist eine Anwendung innerhalb des Kubernetes-Clusters, genau wie jede andere.
Die nächste Komponente von Chart Repo ist ein Repository mit Diagrammen. Es gibt ein offizielles Repository und es kann ein privates Repository eines Unternehmens oder Projekts geben.
Interaktion
Schauen wir uns an, wie die Architekturkomponenten interagieren, wenn wir eine Anwendung mit Helm installieren möchten.
- Wir sprechen
Helm install, greifen Sie auf das Repository (Chart Repo) zu und holen Sie sich ein Helm-Chart.
- Das Helm-Dienstprogramm (Helm CLI) interagiert mit Kubeconfig, um herauszufinden, welcher Cluster kontaktiert werden soll.
- Nach Erhalt dieser Informationen bezeichnet das Dienstprogramm Tiller, das sich in unserem Cluster befindet, als Anwendung.
- Tiller ruft Kube-apiserver auf, um Aktionen in Kubernetes auszuführen und einige Objekte (Dienste, Pods, Replikate, Geheimnisse usw.) zu erstellen.
Als nächstes verkomplizieren wir das Diagramm, um den Angriffsvektor zu sehen, dem die gesamte Helm-Architektur als Ganzes ausgesetzt sein kann. Und dann werden wir versuchen, sie zu beschützen.
Angriffsvektor
Der erste mögliche Schwachpunkt ist privilegierte API-Benutzer. Im Rahmen des Plans handelt es sich um einen Hacker, der sich Administratorzugriff auf die Helm-CLI verschafft hat.
Unprivilegierter API-Benutzer kann auch eine Gefahr darstellen, wenn es sich irgendwo in der Nähe befindet. Ein solcher Benutzer hat einen anderen Kontext, er kann beispielsweise in den Kubeconfig-Einstellungen auf einen Cluster-Namespace festgelegt werden.
Der interessanteste Angriffsvektor könnte ein Prozess sein, der sich in einem Cluster irgendwo in der Nähe von Tiller befindet und darauf zugreifen kann. Dabei kann es sich um einen Webserver oder Microservice handeln, der die Netzwerkumgebung des Clusters sieht.
Eine exotische, aber immer beliebter werdende Angriffsvariante ist Chart Repo. Ein Diagramm, das von einem skrupellosen Autor erstellt wurde, kann unsichere Ressourcen enthalten, und Sie werden es vervollständigen, wenn Sie es im Glauben annehmen. Oder es kann das Diagramm ersetzen, das Sie aus dem offiziellen Repository herunterladen, und beispielsweise eine Ressource in Form von Richtlinien erstellen und deren Zugriff eskalieren.
Versuchen wir, Angriffe von allen vier Seiten abzuwehren und herauszufinden, wo es Probleme in der Helm-Architektur gibt und wo vielleicht keine.
Vergrößern wir das Diagramm, fügen weitere Elemente hinzu, behalten aber alle Grundkomponenten bei.
Die Helm-CLI kommuniziert mit dem Chart Repo, interagiert mit Kubeconfig und die Arbeit wird vom Cluster an die Tiller-Komponente übertragen.
Tiller wird durch zwei Objekte dargestellt:
- Tiller-Deploy-SVC, der einen bestimmten Dienst verfügbar macht;
- Tiller-Deploy-Pod (im Diagramm in einer einzigen Kopie in einem Replikat), auf dem die gesamte Last läuft, die auf den Cluster zugreift.
Für die Interaktion werden unterschiedliche Protokolle und Schemata verwendet. Aus sicherheitstechnischer Sicht sind wir vor allem an Folgendem interessiert:
- Der Mechanismus, mit dem die Helm-CLI auf das Chart-Repository zugreift: Welches Protokoll, gibt es eine Authentifizierung und was kann damit gemacht werden?
- Das Protokoll, über das Helm CLI mithilfe von kubectl mit Tiller kommuniziert. Dies ist ein im Cluster installierter RPC-Server.
- Tiller selbst ist für Microservices, die sich im Cluster befinden, zugänglich und interagiert mit dem Kube-Apiserver.
Lassen Sie uns alle diese Bereiche der Reihe nach besprechen.
RBAC
Es macht keinen Sinn, über Sicherheit für Helm oder einen anderen Dienst innerhalb des Clusters zu sprechen, es sei denn, RBAC ist aktiviert.
Es scheint, dass dies nicht die neueste Empfehlung ist, aber ich bin mir sicher, dass viele Leute RBAC noch nicht einmal in der Produktion aktiviert haben, weil es viel Aufwand bedeutet und viele Dinge konfiguriert werden müssen. Ich ermutige Sie jedoch, dies zu tun.
– Website-Anwalt für RBAC. Es enthält eine Menge interessanter Materialien, die Ihnen bei der Einrichtung von RBAC helfen, zeigen, warum es gut ist und wie Sie grundsätzlich damit in der Produktion leben können.
Ich werde versuchen zu erklären, wie Tiller und RBAC funktionieren. Tiller arbeitet innerhalb des Clusters unter einem bestimmten Dienstkonto. Wenn RBAC nicht konfiguriert ist, ist dies normalerweise der Superuser. In der Grundkonfiguration ist Tiller ein Admin. Aus diesem Grund wird oft gesagt, dass Tiller ein SSH-Tunnel zu Ihrem Cluster ist. Dies trifft tatsächlich zu, sodass Sie anstelle des Standarddienstkontos im obigen Diagramm ein separates dediziertes Dienstkonto verwenden können.
Wenn Sie Helm initialisieren und zum ersten Mal auf dem Server installieren, können Sie das Dienstkonto mit festlegen --service-account. Dadurch können Sie einen Benutzer mit den minimal erforderlichen Rechten verwenden. Es stimmt, Sie müssen eine solche „Girlande“ erstellen: Role und RoleBinding.
Leider wird Helm dies nicht für Sie tun. Sie oder Ihr Kubernetes-Clusteradministrator müssen im Voraus einen Satz Rollen und RoleBindings für das Dienstkonto vorbereiten, um Helm zu übergeben.
Es stellt sich die Frage: Was ist der Unterschied zwischen Role und ClusterRole? Der Unterschied besteht darin, dass ClusterRole für alle Namespaces funktioniert, im Gegensatz zu regulären Roles und RoleBindings, die nur für einen speziellen Namespace funktionieren. Sie können Richtlinien für den gesamten Cluster und alle Namespaces konfigurieren oder für jeden Namespace einzeln personalisieren.
Es ist erwähnenswert, dass RBAC ein weiteres großes Problem löst. Viele Leute beschweren sich darüber, dass Helm leider nicht mandantenfähig ist (keine Mandantenfähigkeit unterstützt). Wenn mehrere Teams einen Cluster nutzen und Helm verwenden, ist es grundsätzlich unmöglich, Richtlinien festzulegen und ihren Zugriff innerhalb dieses Clusters einzuschränken, da es ein bestimmtes Dienstkonto gibt, unter dem Helm ausgeführt wird, und alle Ressourcen im Cluster daraus erstellt , was manchmal sehr unbequem ist. Das ist wahr – wie die Binärdatei selbst, wie der Prozess, Helm Tiller hat kein Konzept von Mandantenfähigkeit.
Es gibt jedoch eine großartige Möglichkeit, Tiller mehrmals in einem Cluster auszuführen. Das ist kein Problem, Tiller kann in jedem Namensraum gestartet werden. Somit können Sie RBAC und Kubeconfig als Kontext verwenden und den Zugriff auf einen speziellen Helm beschränken.
Es wird so aussehen.
Beispielsweise gibt es zwei Kubeconfigs mit Kontext für verschiedene Teams (zwei Namespaces): X Team für das Entwicklungsteam und den Admin-Cluster. Der Admin-Cluster verfügt über einen eigenen weiten Tiller, der im Kube-System-Namespace liegt, ein entsprechend erweitertes Service-Konto. Und ein separater Namespace für das Entwicklungsteam, damit sie ihre Dienste in einem speziellen Namespace bereitstellen können.
Dies ist ein praktikabler Ansatz. Die Bodenfräse ist nicht so energiehungrig, dass sie Ihr Budget stark beeinträchtigen würde. Dies ist eine der schnellen Lösungen.
Sie können Tiller gerne separat konfigurieren und Kubeconfig Kontext für das Team, für einen bestimmten Entwickler oder für die Umgebung bereitstellen: Entwicklung, Staging, Produktion (es ist zweifelhaft, ob sich alles im selben Cluster befindet, dies ist jedoch möglich).
Um unsere Geschichte fortzusetzen, wechseln wir von RBAC und sprechen über ConfigMaps.
ConfigMaps
Helm verwendet ConfigMaps als Datenspeicher. Als wir über Architektur sprachen, gab es nirgendwo eine Datenbank, die Informationen über Releases, Konfigurationen, Rollbacks usw. speichern würde. Dafür wird ConfigMaps verwendet.
Das Hauptproblem bei ConfigMaps ist bekannt – sie sind grundsätzlich unsicher; Es ist unmöglich, sensible Daten zu speichern. Die Rede ist von allem, was nicht über den Dienst hinausgehen sollte, zum Beispiel Passwörter. Der derzeit nativste Weg für Helm besteht darin, von der Verwendung von ConfigMaps auf Secrets umzusteigen.
Das geht ganz einfach. Überschreiben Sie die Tiller-Einstellung und geben Sie an, dass der Speicher geheim sein soll. Dann erhalten Sie für jede Bereitstellung keine ConfigMap, sondern ein Geheimnis.
Man könnte argumentieren, dass Geheimnisse selbst ein seltsames Konzept und nicht sehr sicher sind. Es lohnt sich jedoch zu verstehen, dass dies von den Kubernetes-Entwicklern selbst durchgeführt wird. Ab Version 1.10, d.h. Zumindest in öffentlichen Clouds ist es seit geraumer Zeit möglich, den richtigen Speicher anzubinden, um Geheimnisse zu speichern. Das Team arbeitet derzeit an Möglichkeiten, den Zugriff auf Geheimnisse, einzelne Pods oder andere Entitäten besser zu verteilen.
Besser ist es, Storage Helm auf Secrets zu übertragen, diese wiederum werden zentral gesichert.
Natürlich wird es bleiben Datenspeicherlimit von 1 MB. Helm verwendet hier etcd als verteilten Speicher für ConfigMaps. Und da dachten sie, dass dies ein geeigneter Datenblock für die Replikation usw. sei. Auf Reddit gibt es dazu eine interessante Diskussion, ich empfehle, sich diese lustige Lektüre für das Wochenende zu suchen oder den Auszug zu lesen .
Diagramm-Repos
Diagramme sind sozial am stärksten gefährdet und können zu einer Quelle von „Man in the Middle“ werden, insbesondere wenn Sie eine Aktienlösung verwenden. Zunächst geht es um Repositories, die über HTTP verfügbar gemacht werden.
Sie müssen Helm Repo unbedingt über HTTPS verfügbar machen – dies ist die beste und kostengünstige Option.
Beachten Sie die Diagrammsignaturmechanismus. Die Technologie ist höllisch einfach. Dies ist dasselbe, was Sie auf GitHub verwenden, einem regulären PGP-Computer mit öffentlichen und privaten Schlüsseln. Richten Sie es ein und stellen Sie sicher, dass es sich wirklich um Ihr Diagramm handelt, indem Sie über die erforderlichen Schlüssel verfügen und alles unterschreiben.
Außerdem, Der Helm-Client unterstützt TLS (nicht im serverseitigen HTTP-Sinn, sondern gegenseitiges TLS). Zur Kommunikation können Sie Server- und Client-Schlüssel verwenden. Ehrlich gesagt nutze ich einen solchen Mechanismus nicht, weil ich gegenseitige Zertifikate nicht mag. Im Prinzip, – das Haupttool zum Einrichten von Helm Repo für Helm 2 – unterstützt auch die Basisauthentifizierung. Sie können die Basisauthentifizierung verwenden, wenn diese bequemer und leiser ist.
Es gibt auch ein Plugin , mit dem Sie Chart Repos auf Google Cloud Storage hosten können. Das ist sehr praktisch, funktioniert hervorragend und ist ziemlich sicher, da alle beschriebenen Mechanismen recycelt sind.
Wenn Sie HTTPS oder TLS aktivieren, mTLS verwenden und die Basisauthentifizierung aktivieren, um Risiken weiter zu reduzieren, erhalten Sie einen sicheren Kommunikationskanal mit Helm CLI und Chart Repo.
gRPC-API
Der nächste Schritt ist sehr wichtig – die Sicherung von Tiller, der sich im Cluster befindet und einerseits ein Server ist, andererseits selbst auf andere Komponenten zugreift und versucht, sich als jemand auszugeben.
Wie ich bereits sagte, ist Tiller ein Dienst, der gRPC verfügbar macht, der Helm-Client kommt über gRPC darauf. Standardmäßig ist TLS natürlich deaktiviert. Warum dies gemacht wurde, ist eine umstrittene Frage, es scheint mir, um die Einrichtung am Anfang zu vereinfachen.
Für die Produktion und sogar das Staging empfehle ich die Aktivierung von TLS auf gRPC.
Meiner Meinung nach ist dies im Gegensatz zu mTLS für Diagramme hier angemessen und sehr einfach zu bewerkstelligen: PQI-Infrastruktur erstellen, Zertifikat erstellen, Tiller starten, Zertifikat während der Initialisierung übertragen. Danach können Sie alle Helm-Befehle ausführen und erhalten dabei das generierte Zertifikat und den privaten Schlüssel.
Auf diese Weise schützen Sie sich vor allen Anfragen an Tiller von außerhalb des Clusters.
Wir haben also den Verbindungskanal zu Tiller gesichert, RBAC bereits besprochen und die Rechte des Kubernetes-Apiservers angepasst, wodurch die Domäne reduziert wurde, mit der er interagieren kann.
Geschützter Helm
Schauen wir uns das endgültige Diagramm an. Es ist die gleiche Architektur mit den gleichen Pfeilen.
Alle Verbindungen können nun sicher in grün gezeichnet werden:
- Für Chart Repo verwenden wir TLS oder mTLS und Basisauthentifizierung.
- mTLS für Tiller, und es wird als gRPC-Dienst mit TLS bereitgestellt, wir verwenden Zertifikate;
- Der Cluster verwendet ein spezielles Dienstkonto mit Role und RoleBinding.
Wir haben den Cluster erheblich gesichert, aber jemand Schlaues sagte:
„Es kann nur eine absolut sichere Lösung geben – einen ausgeschalteten Computer, der in einem Betonkasten steht und von Soldaten bewacht wird.“
Es gibt verschiedene Möglichkeiten, Daten zu manipulieren und neue Angriffsvektoren zu finden. Ich bin jedoch zuversichtlich, dass diese Empfehlungen einen grundlegenden Industriestandard für Sicherheit erreichen werden.
Bonus
Dieser Teil hat nicht direkt mit der Sicherheit zu tun, wird aber auch nützlich sein. Ich zeige Ihnen einige interessante Dinge, die nur wenige Menschen kennen. Zum Beispiel, wie man nach offiziellen und inoffiziellen Diagrammen sucht.
Im Repository Mittlerweile gibt es etwa 300 Charts und zwei Streams: Stable und Incubator. Jeder, der einen Beitrag leistet, weiß genau, wie schwierig es ist, vom Brutkasten in den Stall zu gelangen und wie einfach es ist, aus dem Stall zu fliegen. Dies ist jedoch aus einem einfachen Grund nicht das beste Tool für die Suche nach Diagrammen für Prometheus und was auch immer Sie möchten: Es handelt sich nicht um ein Portal, auf dem Sie bequem nach Paketen suchen können.
Aber es gibt einen Service , was das Auffinden von Diagrammen wesentlich erleichtert. Am wichtigsten ist, dass es viel mehr externe Repositories und fast 800 Charms gibt. Außerdem können Sie Ihr Repository verbinden, wenn Sie Ihre Diagramme aus irgendeinem Grund nicht an Stable senden möchten.
Probieren Sie hub.helm.sh aus und lassen Sie uns es gemeinsam entwickeln. Dieser Dienst gehört zum Helm-Projekt und Sie können sogar zu seiner Benutzeroberfläche beitragen, wenn Sie ein Front-End-Entwickler sind und einfach nur das Erscheinungsbild verbessern möchten.
Ich möchte Sie auch darauf aufmerksam machen Öffnen Sie die Service Broker-API-Integration. Es klingt umständlich und unklar, löst aber Probleme, mit denen jeder konfrontiert ist. Lassen Sie es mich anhand eines einfachen Beispiels erklären.
Es gibt einen Kubernetes-Cluster, in dem wir eine klassische Anwendung ausführen wollen – WordPress. Im Allgemeinen ist für die volle Funktionalität eine Datenbank erforderlich. Es gibt viele verschiedene Lösungen. Sie können beispielsweise Ihren eigenen Statefull-Dienst starten. Das ist nicht sehr praktisch, aber viele Leute tun es.
Andere, wie wir bei Chainstack, verwenden verwaltete Datenbanken wie MySQL oder PostgreSQL für ihre Server. Deshalb liegen unsere Datenbanken irgendwo in der Cloud.
Es entsteht jedoch ein Problem: Wir müssen unseren Dienst mit einer Datenbank verbinden, eine Datenbankvariante erstellen, die Anmeldeinformationen übertragen und sie irgendwie verwalten. All dies wird normalerweise manuell vom Systemadministrator oder Entwickler durchgeführt. Und es ist kein Problem, wenn es nur wenige Anwendungen gibt. Wenn es viele davon gibt, braucht man einen Mähdrescher. Es gibt einen solchen Harvester – es ist Service Broker. Es ermöglicht Ihnen, ein spezielles Plugin für einen öffentlichen Cloud-Cluster zu verwenden und Ressourcen beim Anbieter über den Broker zu bestellen, als wäre es eine API. Hierfür können Sie native Kubernetes-Tools verwenden.
Es ist sehr einfach. Sie können beispielsweise Managed MySQL in Azure mit einer Basisschicht abfragen (diese kann konfiguriert werden). Mithilfe der Azure-API wird die Datenbank erstellt und für die Verwendung vorbereitet. Hier muss man nicht eingreifen, dafür ist das Plugin verantwortlich. Beispielsweise gibt OSBA (Azure-Plugin) Anmeldeinformationen an den Dienst zurück und übergibt sie an Helm. Sie können WordPress mit Cloud-MySQL verwenden, müssen sich überhaupt nicht mit verwalteten Datenbanken befassen und müssen sich keine Gedanken über darin enthaltene Statefull-Dienste machen.
Man kann sagen, dass Helm als Klebstoff fungiert, der einerseits die Bereitstellung von Diensten ermöglicht und andererseits die Ressourcen von Cloud-Anbietern verbraucht.
Sie können Ihr eigenes Plugin schreiben und die gesamte Geschichte vor Ort verwenden. Dann haben Sie einfach Ihr eigenes Plugin für den Unternehmens-Cloud-Anbieter. Ich empfehle, diesen Ansatz auszuprobieren, insbesondere wenn Sie einen großen Umfang haben und schnell Entwicklung, Staging oder die gesamte Infrastruktur für eine Funktion bereitstellen möchten. Dies wird Ihren Betrieb oder DevOps das Leben erleichtern.
Ein weiterer Fund, den ich bereits erwähnt habe, ist Helm-GCS-Plugin, mit dem Sie Google-Buckets (Objektspeicher) zum Speichern von Helm-Diagrammen verwenden können.
Sie benötigen nur vier Befehle, um es zu verwenden:
- Installieren Sie das Plugin.
- initiiere es;
- Legen Sie den Pfad zum Bucket fest, der sich in gcp befindet.
- Veröffentlichen Sie Diagramme auf die übliche Weise.
Das Schöne ist, dass für die Autorisierung die native GCP-Methode verwendet wird. Sie können ein Dienstkonto, ein Entwicklerkonto oder was auch immer Sie möchten verwenden. Es ist sehr praktisch und der Betrieb kostet nichts. Wenn Sie wie ich die Opsless-Philosophie vertreten, ist dies insbesondere für kleine Teams sehr praktisch.
Alternativen
Helm ist nicht die einzige Service-Management-Lösung. Es gibt viele Fragen dazu, was wahrscheinlich auch der Grund dafür ist, dass die dritte Version so schnell erschien. Natürlich gibt es Alternativen.
Dies können spezialisierte Lösungen sein, beispielsweise Ksonnet oder Metaparticle. Sie können Ihre klassischen Infrastrukturmanagement-Tools (Ansible, Terraform, Chef usw.) für die gleichen Zwecke verwenden, über die ich gesprochen habe.
Endlich gibt es eine Lösung , dessen Popularität wächst.
Operator Framework ist die beste Helm-Alternative, die Sie in Betracht ziehen sollten.
Es ist eher in CNCF und Kubernetes integriert. aber die Eintrittsbarriere ist viel höher, müssen Sie mehr programmieren und Manifeste weniger beschreiben.
Es gibt verschiedene Add-ons, wie Draft, Scaffold. Sie machen das Leben viel einfacher, zum Beispiel vereinfachen sie den Zyklus des Sendens und Startens von Helm für Entwickler, um eine Testumgebung bereitzustellen. Ich würde sie „Empowermenter“ nennen.
Hier ist eine visuelle Übersicht darüber, wo sich alles befindet.
Auf der x-Achse ist der Grad Ihrer persönlichen Kontrolle über das Geschehen, auf der y-Achse der Grad der Nativeness von Kubernetes. Helm-Version 2 liegt irgendwo in der Mitte. In Version 3 nicht enorm, aber sowohl die Kontrolle als auch der Grad der Nativität wurden verbessert. Lösungen auf Ksonnet-Ebene sind selbst Helm 2 immer noch unterlegen. Sie sind jedoch einen Blick wert, um zu erfahren, was es sonst noch auf dieser Welt gibt. Natürlich steht Ihr Konfigurationsmanager unter Ihrer Kontrolle, aber er ist absolut nicht nativ in Kubernetes enthalten.
Das Operator Framework ist absolut nativ für Kubernetes und ermöglicht Ihnen eine viel elegantere und sorgfältigere Verwaltung (aber denken Sie an die Einstiegsebene). Dies eignet sich vielmehr für eine spezielle Anwendung und die Erstellung von Management dafür und nicht für einen Massen-Harvester zum Verpacken einer großen Anzahl von Anwendungen mithilfe von Helm.
Extender verbessern lediglich die Kontrolle ein wenig, ergänzen den Workflow oder sparen Abstriche bei CI/CD-Pipelines.
Die Zukunft von Helm
Die gute Nachricht ist, dass Helm 3 kommt. Die Alpha-Version von Helm 3.0.0-alpha.2 wurde bereits veröffentlicht, Sie können es ausprobieren. Es ist recht stabil, die Funktionalität ist jedoch immer noch eingeschränkt.
Warum brauchen Sie Helm 3? Zunächst einmal handelt es sich hier um eine Geschichte Verschwinden von Tiller, als Komponente. Wie Sie bereits verstehen, ist dies ein großer Fortschritt, da aus Sicht der Sicherheit der Architektur alles vereinfacht wird.
Als Helm 2 erstellt wurde, was etwa zur Zeit von Kubernetes 1.8 oder noch früher geschah, waren viele Konzepte noch unausgereift. Beispielsweise wird das CRD-Konzept derzeit aktiv umgesetzt, und Helm wird dies tun Verwenden Sie CRDStrukturen zu speichern. Es ist möglich, nur den Client zu verwenden und den Serverteil nicht zu warten. Nutzen Sie dementsprechend native Kubernetes-Befehle, um mit Strukturen und Ressourcen zu arbeiten. Das ist ein großer Fortschritt.
Wird erscheinen Unterstützung für native OCI-Repositorys (Open-Container-Initiative). Dies ist eine riesige Initiative, und Helm ist vor allem daran interessiert, seine Charts zu veröffentlichen. Es kommt so weit, dass beispielsweise Docker Hub viele OCI-Standards unterstützt. Ich vermute nicht, aber vielleicht bieten Ihnen klassische Docker-Repository-Anbieter die Möglichkeit, ihre Helm-Charts zu hosten.
Die für mich kontroverse Geschichte ist Lua-Unterstützung, als Template-Engine zum Schreiben von Skripten. Ich bin kein großer Fan von Lua, aber das wäre eine völlig optionale Funktion. Ich habe das dreimal überprüft – die Verwendung von Lua ist nicht erforderlich. Daher schließen sich diejenigen, die Lua nutzen möchten, diejenigen, die Go mögen, unserem riesigen Camp an und verwenden dafür go-tmpl.
Was mir zum Schluss definitiv gefehlt hat, war Schemaentstehung und Datentypvalidierung. Es wird keine Probleme mehr mit int oder string geben, es ist nicht nötig, Nullen in doppelte Anführungszeichen zu setzen. Es erscheint ein JSONS-Schema, mit dem Sie dies explizit für Werte beschreiben können.
Wird stark überarbeitet ereignisgesteuertes Modell. Es wurde bereits konzeptionell beschrieben. Schauen Sie sich den Helm 3-Zweig an und Sie werden sehen, wie viele Ereignisse, Hooks und andere Dinge hinzugefügt wurden, was die Bereitstellungsprozesse und Reaktionen darauf erheblich vereinfacht und andererseits die Kontrolle über sie erhöht.
Helm 3 wird einfacher, sicherer und unterhaltsamer sein, nicht weil uns Helm 2 nicht gefällt, sondern weil Kubernetes immer fortschrittlicher wird. Dementsprechend kann Helm die Entwicklungen von Kubernetes nutzen und darauf hervorragende Manager für Kubernetes erstellen.
Eine weitere gute Nachricht ist das Alexander Khayorov wird Ihnen sagen, Wir möchten Sie daran erinnern, dass die Konferenz zur Integration von Entwicklungs-, Test- und Betriebsprozessen in Moskau stattfinden wird 30. September und 1. Oktober. Ihr könnt es noch bis zum 20. August machen und erzählen Sie uns von Ihren Erfahrungen mit der Lösung Aufgaben des DevOps-Ansatzes.
Verfolgen Sie Konferenzkontrollpunkte und Neuigkeiten unter и .
Source: habr.com