- ライター：庄谷 信哉
- 2005年にネットワンシステムズに入社し、スイッチ製品の新旧技術の調査・検証業務を元に
ネットワーク提案、導入を支援する業務を経て、現在は、クラウド関連製品担当に従事。
最近は、企業システムの今後のマルチクラウド化を見据えたクラウド関連技術の最新動向に注目している。
現在、Kubernetesの運用自動化におけるキーワードとして、Operatorが注目されています。
今回のブログでは、そのOperatorの概要について御紹介します。
１．Operatorとは
コンテナを動作させるためのインフラストラクチャは、Kubernetesを利用することにより、現在の状態とDeclarative Configuration（宣言的設定）で宣言されたあるべき状態とを比較します。
あるべき状態になるように差を埋めるべく動き続ける下記のReconciliation Loop（突合せループ）によりコンテナ運用の自動化を実現しています。
しかしながら、ステートフルなアプリケーションで利用されるデータベースを動作させているコンテナ運用では、データの損失や利用不能から保護しながら、スケーリング、アップグレード、バックアップ、復元などを適切に行う必要があります。Kubernetesが持つ標準的なReconciliation Loopだけでは不十分です。
このような場合において、アプリケーション固有の知識をコード化し、データベースのようなステートフルなコンテナをKubernetesクラスター上で正しく運用してくれるのが、Operatorです。
例えば、アップグレードをシームレスに処理し、障害に自動対応を行い、時間を節約するためにソフトウェアバックアップをスキップするといったことが無いよう、高度なシステム運用者が行えるような動作を実施できるよう目指しています。
２．Operatorの構成
Operatorは、KubernetesのAPIを拡張してユーザが、独自のリソース定義を行うCustom Resource Definition（CRD）と、そのリソースの制御を行うCustom Controllerとの組み合わせにより、ステートフルなアプリケーションに対するナレッジをコード化し、Kubernetes API上でアプリケーションライフルサイクルを実現しています。
・Custom Resource Definition：KubernetesのAPI上に任意のリソースを追加する
・Custom Controller：CRDによって定義されたカスタムリソースのライフサイクルを管理する
Custom Controllerでは、KubernetesのAPIを介してCRDによって定義されたあるべき状態に保つために、以下のようなフレームワークを利用することで、プログラム実装が行われています。
そして、Operator Frameworkでは、オープンソースのプロジェクトであり、Operatorの開発を加速できるように以下のコンポーネントが含まれています。
|
説明
|
|
Operator SDK
|
Operatorをビルド、テストおよびパッケージ化するためのツールを提供。
初期レベルのSDKは、Kubernetes APIを利用して、アプリケーションのビジネスロジック（スケーリング、アップグレード、バックアップなど）の操作を実装する。
開発者は、SDKによりスマートなアプリケーションを開発することが可能となり、クラウドサービスのユーザエクスペリエンスも得られる。
また、Operator間で共有される主要なプラクティスとコードパターンがSDKに含まれ、それらを利用することが可能。
|
|
Operator Lifecycle Management
|
Operatorを開発後、Kubernetesクラスターにデプロイする必要がある。
Operator Lifecycle Managerは、Kubernetesクラスター上のOperatorの管理を容易にするバックプレーン。これにより、管理者はどの名前空間で、どのOperatorが使用可能か、誰が実行中のOperatorと対話できるかを制御できる。
また、Operatorとそのリソースの更新をトリガーするなど、Operatorとそのリソースのライフサイクル全体を管理することも可能。
|
|
Operator Metering
|
将来のバージョンで、Operator Frameworkにはアプリケーションの使用状況を測定する機能も含まれる予定。
Operator Meteringは、クラスターのCPUとメモリのレポートに連携するように設計され、IaaSコストやライセンスなどのカスタマイズされたメトリックを計算する。
|
３．Operatorの公開
Red Hatは、AWS、Google Cloud、Microsoftと共同で、利用可能なOperatorを公開および検索するための共通のレジストリーとしたKubernetes Operatorのパブリックレジストリとして、OperatorHub.ioを公開しています。
そして、このOperatorHub.ioでは、Kubernetesのetcdクラスター管理を容易に行えるetcd OperatorやKubernetes上にElasticsearch, Kibanaのデプロイ、ノード管理（スケールアウトなど）を行えるElastic Cloud on Kubernetes Operatorなどが、多数登録されております。
こちらに登録されているOperatorカタログでは、下記のように、単純なインストール（Basic Install）やデプロイから自動操縦（Auto pilot）可能なレベルまでカタログ毎にOperatorの成熟度が表示されております。
Operatorの一例として、Red Hat OpenShift Container Platform（OCP）において利用可能なクラスターロギングOperatorをご紹介致します。こちらのOperator機能を利用した場合、OCPクラスターにおけるログを収集、保存し視覚化するための以下のコンポーネントが、アプリ固有の設定を定義したCustom Resource（CR）に沿ってクラスター内へデプロイされます。
・logStore： Fluentd からのログデータを、データストアまたは インデックス に編成する
現在は、Elasticsearchが実装されている
・collection ： Kubernetesノードからログを収集後、フォーマットされlogstoreに保存するコンポーネント
現在は、Fluentdが実装されている
・visualization：ログ、グラフチャートなどの可視化のためのUIコンポーネント
現在は、Kibanaが実装されている
・curation： グローバルに、またはプロジェクトごとにスケジュールされたメンテナンス操作を実行する
現在は、Curatorが実装されている
そして、クラスターロギングOperatorは、上記、デプロイされたアプリケーションを監視し、クラスターロギング用のCustom Resource（CR）に定義された状態に保つように調整を行います。
まとめ
現在、Kubernetesにおける運用管理の自動化をOperatorにより、さらに高度なレベルに進化させる流れになっております。
弊社のラボ環境では今回ご紹介したOperatorの仕組みをRed Hat OpenShift Container Platform上で、お客様がテストを行うことができる環境の準備を進めております。
近日中にお客様にご案内できる予定ですので、ご期待ください。
参考資料
[Introducing Operators: Putting Operational Knowledge into Software]
https://coreos.com/blog/introducing-operators.html
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
