Kubernetes Operator の何が魅力なのか
Why Operator
Operator はある記事では Game-Changer であると言われています。
また Red Hat OpenShift 4 (Released May 1, 2019) の Version 3 からの最大の変更点は Operator を利用した Automation なのではないでしょうか。
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.
Introducing Red Hat OpenShift 4: Kubernetes for the Enterprise – Red Hat OpenShift Blog
歴史
Operator は元々 CoreOS によって 2016 年に提唱されたコンセプトです。
【OSS】CoreOS、コンテナ管理コンセプト「Operators」発表---Dockerコンテナ管理フレームワーク「Kubernetes」向け、エンジニアやデベロッパーの固有の知識を自動化
2018 年 1 月に Red Hat が CoreOS を買収すると発表しました。この時 CoreOS は Operator や Quay を持っていました。
そして 2018 年 5 月に オープンソースのツールキットとして Operator Framework が発表されました。
RedHatのCoreOSがKubernetesアプリケーションを管理するツールキットを発表 | TechCrunch Japan
Operatorとは
Operator とは何でしょうか。CoreOS のサイトでは以下のように説明されています。
Conceptually, an Operator takes human operational knowledge and encodes it into software that is more easily packaged and shared with consumers.
概念的には、オペレータは人間の操作上の知識を取り入れ、それをより簡単にパッケージ化され消費者と共有されるソフトウェアにエンコードする。 by Google Translate
Introducing the Operator Framework: Building Apps on Kubernetes | CoreOS
これだけだとよくわからないので、まずはOperatorの仕組みから見ていきます。
Operatorの仕組み
Operator の仕組みを理解するためには、まずは Kubernetes の CRD と Custom Controller を知っておく必要があります。
CRD (Custom Resource Definition)
Kubernetes には Pod, Service, Deployment などのリソースがありますが、その他に独自リソースを定義することができます。
Custom Controller
Kubernetes にはリソースを管理する Controller があります。たとえば ReplicationController は指定されたレプリカ数のPodを起動した状態に保ちます。 Custom Controller はデフォルトのリソースや CRD に対してアクションを取る独自 Controller を定義することができます。
Operator
以下の記事の説明がとても分かりやすかったため引用します。
Operatorは Custom Resource と Costom Controller から成り立ちます。 Custom ResourceはKubernetes上に登録可能な独自リソースであり、上述の What 部に相当します。 Custom Resourceを作成するには CRD (CustomResourceDefinition) という機能を利用します。 CRDに独自のリソース（Kind: MySQL等）とそのスペックを定義してKubernetes上に登録することで、Custom Resourceの利用が可能になります。
一方Custom Controllerは上述の How に相当し、どのようにCurrent StateとDesired Stateを一致させるか（Reconciliation Logic）を担います。Operatorの文脈ではCustom ResourceをCustom Controllerが扱う対象とします。
つまり、Custom Resourceに定義されたDesired Stateを実現するのがCustom Controllerであり、これらを一括りにOperatorと呼びます。
注意点
Operator が増えてくると、特に適当な名前で登録したCRDなどリソース名が被ってしまうことがあります。 その場合はリソース名のフルパスを指定する必要があるそうです。
また、OpenShift で Operator を使用する場合には適宜 ServiceAccount の権限設定などを適切にしておく必要があります。
Operator Hub
https://operatorhub.io/ というサイトがあり、DockerHub の Operator 版のような位置づけかと思っています。
OpenShift Certified Operators
Operator 自体は誰でも作れるものなので、OpenShift 向けの Operator として Certified Operator というものがあり、安心して使えそうです。
OpenShift 4のCluster Version Operator
OpenShift のクラスタバージョンの管理も Operator で出来てしまうというのはなかなか衝撃的です。
その他
- Operator SDK: Enables developers to build Operators based on their expertise without requiring knowledge of Kubernetes API complexities.
- Operator Lifecycle Management: Oversees installation, updates, and management of the lifecycle of all of the Operators (and their associated services) running across a Kubernetes cluster.
- Operator Metering (joining in the coming months): Enables usage reporting for Operators that provide specialized services.
結論
Operator 利用すると、裏で自動で CRD や Custom Controller を作成してくれます。Controller まで出来上がるということは、リソースをある状態に保てるということです。言い換えれば、Operatorを使うことでKubernetesやOpenShift上でマネージドサービスのように信頼性のあるサービスをPrivateに簡単に構築できてしまうと言えるのではないでしょうか。
参考
KubernetesのCRD(Custom Resource Definition)とカスタムコントローラーの作成 - Qiita
