Wir beginnen, Kubernetes-Ressourcen mit Helm zu verwalten, und wir haben einige Benutzer, die es gewohnt sind, Ressourcen mit zu verwalten kubectl edit. Wir möchten, dass Helm die bereitgestellten Ressourcen bei jeder Ausführung bereinigt und sie in einen bekanntermaßen einwandfreien Zustand zurückversetzt.
Ich habe festgestellt, dass helm upgrademeine ConfigMaps dadurch nicht überschrieben werden. Stattdessen werden Attribute zwischen der bereitgestellten ConfigMap und der Helm-Vorlage zusammengeführt, sodass ich Teile meiner ConfigMap-Vorlage und Teile der manuell bearbeiteten ConfigMap erhalte. Wenn es keine Änderungen in der Helm-ConfigMap-Vorlage gab, führt Helm Folgendes aus:nichtSetzen Sie einen beliebigen Teil meiner bereitgestellten ConfigMap auf einen einwandfreien Zustand zurück.
Wie kann ich Helm anweisen, meine gesamten Kubernetes-Ressourcen immer auf die Helm-Vorlagenversionen zurückzusetzen?
Antwort1
Dies ist kein Designziel von Helm und wird es auch weiterhin nicht sein. Es liegt nicht in Helms Zuständigkeitsbereich, Objekte zu manipulieren, die nicht von Helm erstellt wurden, oder Out-of-Band-Änderungen an Objekten unter seiner „Kontrolle“ zu ignorieren – dies ist eine Funktion, die Helm mit anderen Systemen kompatibel macht, die Manifeste ändern können, und die Helm sicher in der Anwendung macht. Denken Sie daran, dass es sich um ein YAML-Rendering-System handelt, nicht um ein Konfigurationsmanagementsystem wie Puppet oder SaltStack. Es „erzwingt“ keine Konfigurationen.
Wenn Sie das beschriebene Verhalten erreichen möchten, können Sie die betreffenden Objekte löschen, bevor Sie sie mit Helm neu erstellen. Sie können möglicherweise Kubernetes-Namespaces verwenden, um dies zuverlässig zu erreichen, indem Sie jedem Diagramm seinen eigenen Namespace zuweisen und den Namespace vor der Diagramminstallation als eine Art „Hard Reset“ löschen.
Oder halten Sie Benutzer, die es gewohnt sind, Manifeste zu bearbeiten, kubectldavon ab, dies zu tun, und weisen Sie sie stattdessen an, diese Änderungen in Diagramme oder Werte zu übertragen. Es erscheint nicht sinnvoll, ihre Änderungen zu verwerfen, wenn sie vorgenommen werden mussten – genau aus diesem Grund führt Helm von vornherein Drei-Wege-Zusammenführungsvorgänge für Manifeste durch. Ich verstehe den Wunsch, die Konfiguration in einem einzigen Orchestrierungspunkt beizubehalten, aber erwarten Sie nicht, dies zu erreichen, indem Sie keinen einzigen Orchestrierungspunkt verwenden.
Dieses Problem tritt immer wieder auf, wenn Orchestrierungspraktiken auf höherer Ebene auf Teams angewendet werden, die an Orchestrierungsmethoden auf niedrigerer Ebene gewöhnt sind, und ist konzeptionell in keiner Weise auf Helm beschränkt. Helm kann die Situation gut handhaben, indem es Zusammenführungsvorgänge durchführt, führt jedoch zu einem funktionierenden Durcheinander von Orchestrierungsmethoden (zumindest geht nichts kaputt oder schlägt einfach fehl). Beginnen Sie damit, das Durcheinander zu vermeiden oder das Durcheinander auf eine Scratch-Umgebung zu beschränken und es für die Produktion in Helm-Diagramme zu übertragen.