Helm は Kubernetes の複雑なマニフェストを抽象化してくれるもので、似たようなものは他にもありますが、とにかく Kubernetes を効率的に扱うには現在では必要不可欠なものです。
解釈によっては、Linux の Apt や DNF のように考えることができ、そのように使えるという人もいますが、私の解釈は違っており、おそらくそのようにはなりません。
例えば、Apt は、パッケージをインストールするものであり、その後の動作は .conf のようなファイルで設定しながら、試行錯誤しながら意図した動作がするように作っていきます。この際、前者と後者は明確に目的が分離しています。つまり、インストールする、そして動くように設定するの 2 ステップです。DNF も基本的に同じです。
一方で、Helm は段階が、それよりも多層化されています。大きくは、コンテナ、マニフェスト、コンフィグレーションです。Helm の場合、それら全てが適切でなければ起動すらしませんし、動かない原因を突き止めるのも骨が折れます。
つまり、Helm はあらかじめ、その目的に沿った設定状態が、かなり高レベルで設計されていないと動くところすら確認できないということです。おそらく、Apt と似たようなものと考える人は、非常に単純な起動しか試していない可能性もあるでしょう。
しかし、その他の近しい自動構築の仕組みも実は似たようなものであり、例えば、OpenStack や OpenShift などもそうです。もっと範囲を広げれば、複雑なプログラム自体もそうでしょう。
これまで述べたとおり、インフラをコード化するというのは複雑性を増すのですが、一度設計してしまえば高い管理性があり、似たような展開が非常に楽になります。要するに、従来通り、インフラのネットワークデバイスやサーバーはコード化しなければ単一での管理が可能であり、それによるメリットもあります。コード化しても単一に管理することも可能ですが、どちらかというと、もう一つ大きな括りでまとめたオーケストレーションが可能になることが一番のメリットだと思います。
