誇大広告なしのヘルム。 落ち着いた表情
HelmはKubernetesのパッケージマネージャーです。
一見、悪くない。 このツールを使用すると、リリースプロセスが大幅に簡素化されますが、面倒な場合があり、何もできません。
最近、Helmは@CloudNativeFdnのトッププロジェクトとして公式に認められ、コミュニティで広く使用されています。 これは多くのことを言っていますが、このパッケージマネージャーに関連する不快な瞬間について簡単に説明したいと思います。
Helmの真の価値は何ですか？
私はまだこの質問に自信を持って答えることができません。 Helmは特別な機能を提供しません。 Tiller（サーバー側）にはどのような利点がありますか？
多くのHelmチャートは完璧とはほど遠いものであり、Kubernetesクラスターで使用するには追加の努力が必要です。 たとえば、RBAC、リソース制限、およびネットワークポリシーがありません。 Helmチャートをバイナリ形式で取得してインストールするだけで、どのように機能するかを考えずに機能しません。
最も単純な例を挙げて、ヘルムを称賛するだけでは十分ではありません。 特に安全なマルチテナント作業環境の観点から、なぜこれが優れているのかを説明します。
言葉は空です。 コードを見せてください！
—ライナス・トーバルズ
承認とアクセス制御の追加レベル
Tillerを「巨大なsudoサーバー」と比較している人を覚えています。 私の意見では、これは次のレベルの承認であり、同時に追加のTLS証明書が必要ですが、アクセス制御機能は提供しません。 Kubernetes APIと、監査とRBACをサポートする既存のセキュリティモデルを使用してみませんか？
過大評価されているテンプレート処理ツールですか？
実際、Goテンプレートファイルの処理と静的分析では、 values.yamlファイルの構成がvalues.yaml 、処理されたKuberentesマニフェストがConfigMapに格納された対応するメタデータとともに使用されます。
そして、いくつかの簡単なコマンドを使用できます。
$ # render go-template files using golang or python script $ kubectl apply
開発者は通常、環境ごとに1つのvalues.yamlファイルを使用していること、または使用前にvalues.yaml.tmplから取得していることにもvalues.yaml.tmpl 。
Kubernetesシークレットを操作する場合、これは意味がありません。Kubernetesシークレットは、多くの場合暗号化され、リポジトリに複数のバージョンがあります。 この制限を回避するには、helm-secretsプラグインまたは--set key=valueコマンドを使用する必要があります。 いずれにしても、別の難易度が追加されます。
インフラストラクチャライフサイクル管理ツールとしてのHelm
忘れて 特に、kube-dn、CNIプロバイダー、クラスターオートスケーラーなど、Kubernetesの主要コンポーネントについて話している場合、これは不可能です。 これらのコンポーネントのライフサイクルはさまざまであり、Helmはそれらに適合しません。
Helmの私の経験から、このツールはKubernetesコアリソースへの単純な展開に最適であり、ゼロから簡単に実行でき、複雑なリリースプロセスを必要としないことがわかります。
残念ながら、ネームスペース、RBAC、NetworkPolicy、ResourceQuota、PodSecurityPolicyなど、より複雑で頻繁な展開では、Helmは対処できません。
Helmファンは私の言葉を好まないかもしれないことを理解していますが、これは現実です。
ステートヘルム
Tillerサーバーは、Kubernetes内のConfigMapファイルに情報を保存します。 彼は彼自身のデータベースを必要としません。
残念ながら、 etcdの制限により、 ConfigMapのサイズは1 MBを超えることはできません。
ストレージに移動する前に、シリアル化されたバージョンを圧縮するようにConfigMapストレージドライバーを改善する方法を誰かが思いつくことを願っています。 しかし、この方法では、本当の問題はまだ解決できないと思います。
ランダムなクラッシュとエラー処理
私にとって、ヘルムの最大の問題はその不安です。
エラー：アップグレードに失敗しました：「foo」にはリリースがデプロイされていません
これ、私見、ヘルムの最も厄介な問題の1つです。
最初のバージョンを作成できなかった場合、後続の各試行は、不明な状態からの更新が不可能であることを示すエラーで失敗します。
変更を有効にする次のリクエストは、 --forceフラグを追加することでエラーを「修正」します。これは、実際にhelm delete & helm install —replaceコマンドを実行するだけで問題をマスクします。
ただし、ほとんどの場合、リリースの完全なクリーニングを行う必要があります。
helm delete
エラー：fooの解放に失敗しました：条件の待機中にタイムアウトしました
ServiceAccountがないか、RBACが特定のリソースの作成を許可しない場合、Helmは次のエラーメッセージを返します。
Error: release foo failed: timed out waiting for the condition
残念ながら、このエラーの根本的な原因は確認できません。
kubectl -n foo get events --sort-by='{.lastTimestamp}'
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found
青から失敗する
最も高度なケースでは、Helmはアクションをまったく実行せずにエラーをスローします。 たとえば、リソース制限が更新されない場合があります。
helm initはHA構成ではなく、1つのコピーで耕うん機を実行します
デフォルトでは、Tillerは高可用性を意味するものではなく、 参照による変更を有効にする要求はまだ開いています。
ある日それはダウンタイムにつながります...
ヘルム3？ オペレーター？ 未来は？
Helmの次のバージョンでは、いくつかの有望な機能が追加されます。
- クライアントとサーバーを分離しないシングルサービスアーキテクチャ。 これ以上の分げつ;
- 組み込みのLuaスクリプトエンジン。
- 包含リクエストと新しいHelm Controllerプロジェクトに基づくDevOpsワークフロー。
詳細については、 Helm 3 Project Proposalsを参照してください。
Tillerを使用しないアーキテクチャのアイデアは本当に気に入っていますが、Luaベースのスクリプトはチャートを複雑にする可能性があるため、疑問に思っています。
最近、ヘルムチャートよりもKubernetesに適した演算子が人気を博していることに気付きました。
コミュニティがすぐにHelmの問題に対処することを本当に期待しています（もちろん、私たちの助けを借りて）が、今のところは、私自身はこのツールをできるだけ使用しないようにします。
これを理解してください：この記事は個人的な意見であり、Kubernetesに基づいた展開のためのハイブリッドクラウドプラットフォームを作成するときに思いつきました。