私たちは Helm を使用して Kubernetes リソースの管理を開始しており、 を使用したリソース管理に慣れているユーザーもいますkubectl edit。Helm を実行するたびに、デプロイされたリソースをサニタイズして、既知の良好な状態に戻すようにしたいと考えています。
ConfigMapsを上書きしないことを確認しましたhelm upgrade。代わりに、デプロイされたConfigMapとHelmテンプレートの属性をマージし、テンプレート化されたConfigMapの一部と手動で編集されたConfigMapの一部を提供します。Helm ConfigMapテンプレートに変更がない場合、Helmはないデプロイされた ConfigMap の任意の部分を正常な状態にリセットします。
Kubernetes リソース全体を常に Helm テンプレート バージョンにリセットするように Helm に指示するにはどうすればよいですか?
答え1
これは Helm の設計目標ではなく、今後もそうではありません。Helm によって作成されていないオブジェクトを操作したり、Helm の「制御」下にあるオブジェクトに対する帯域外の変更を無視したりすることは、Helm の管轄範囲ではありません。これは、マニフェストを変更する可能性のある他のシステムと Helm の互換性を保ち、Helm を安全に使用できるようにする機能です。これは YAML レンダリング システムであり、Puppet や SaltStack のような構成管理システムではないことに注意してください。構成を「強制」するものではありません。
説明されている動作を実現したい場合は、Helm で再作成する前に、問題のオブジェクトを削除できます。各チャートに独自の名前空間を与え、チャートのインストール前に「ハードリセット」の形で名前空間を削除することで、Kubernetes 名前空間を使用してこれを確実に実現できる可能性があります。
または、マニフェストの編集に慣れているユーザーがkubectlその操作を行わないようにし、代わりにそれらの変更をチャートや値にプッシュするように指示します。変更が必要な場合、その変更を破棄するのは合理的ではないようです。これが、Helm がマニフェストに対して 3 方向のマージ操作を実行する理由です。単一のオーケストレーション ポイントで構成を永続化したいという要望は理解できますが、単一のオーケストレーション ポイントを使用しないことでこれを実現できるとは思わないでください。
この問題は、より低レベルのオーケストレーション方法に慣れているチームに、より高レベルのオーケストレーション手法を適用するときに常に発生しますが、概念的に Helm に限定されるものではありません。Helm は、マージ操作を実行して状況を適切に処理できますが、オーケストレーション方法論の機能的な混乱が生じます (少なくとも、何かを壊したり、単に失敗したりすることはありません)。混乱を起こさないようにするか、混乱をスクラッチ環境に制限して、それを本番環境用の Helm チャートに取り込むことから始めます。