Kubernetes Helm vs Operator
Kubernetes のパッケージ管理には Helm がありますが、一見似ている機能を持った Operator が最近注目を集めています。
例えば Red Hat OpenShift のバージョン 3 から 4 へのもっとも大きな変更点は Operator を前提としたアーキテクチャとなったことです。
以下の記事では、「Install, Upgrade, Management の方法を完全に再構築し、これにより高度な運用や Automation が実現できます。この達成に貢献したものといえば Operator 以上のものはありません」ということが述べられています。
OpenShift 4 is Kubernetes at its core and in this release we have completely re-architected how we install, upgrade and manage the platform, while also bringing advanced day 2 management and automation to the application services that run on the platform. These advancements are based on many new innovations in the Kubernetes ecosystem, none bigger than Kubernetes Operators.
RHEL8からはAnsibleが完全にMainstreamになりAutomationの時代になりましたが、この流れを汲んでいるような印象です。
ちなみに、Operator で OpenShift 自体の Upgrade までできてしまいます。
Helm vs Operator
ところで Helm と Operator は何が違うのでしょうか。
以下の記事がわかりやすいためいくつか引用しながら説明していきます。
Helm Charts are useful for addressing the complexities of installation and simple upgrades of particularly stateless applications like web apps. However when it comes to stateful applications there is more to the upgrade process than upgrading the application itself.
Webアプリのようなステートレスなアプリケーションのインストールやアップグレードには便利だが、ステートフルなアプリに関してはアプリ自体以外への変更も必要なためHelmでは不十分だということです。
Webアプリのコンテナは状態を持たないように、セッションなどの状態はデータベースへ保存するようにしますが、このデータベース自体はどうするかということですね。
If you have ever tried to upgrade a PostgreSQL database before, you know that upgrading PostgreSQL itself is the least of the problems. Dealing with the schema changes between database versions is where the main complexity lies, which often requires dumping the data and re-importing it back to the new version of the database in a controlled manner
例えばデータベースのバージョンによってSchemaに変更があるのであれば、一度データをdumpしてから後でimportしてあげる必要があります。これを Operator だとうまくやってくれるのでしょう。
実際に OperatorHub で PostgreSQL や MySQL の Operator を見てみると、Rolling Upgrade や Scaling, Failover などの機能が提供されているものがあります。
ということで、Helm では Stateful なサービスの管理は難しいという背景から Operator がでてきたことがわかりました。
Operator 自体の説明はこちらの記事を参照してください。
