「Oracle Cloud Hangout Cafe (OCHaCafe)」ダイジェスト第3回

Oracle Cloud Hangout Cafe Season5 #1「Kubernetes Operator 超入門」(2022年1月19日開催)

連載第3回の今回は、2022年1月19日に開催された「Oracle Cloud Hangout Cafe Season5 #1『Kubernetes Operator 超入門』」の発表内容に基づいて紹介していきます。

2023年3月17日 6:30

はじめに

「Oracle Cloud Hangout Cafe」(通称「おちゃかふぇ」/以降、OCHaCafe)は、日本オラクルが主催するコミュニティの1つです。定期的に、開発者・エンジニアに向けたクラウドネイティブな時代に身につけておくべきテクノロジーを深堀する勉強会を開催しています。

連載第3回の今回は、2022年1月19日に開催された「Oracle Cloud Hangout Cafe Season5 #1『Kubernetes Operator 超入門』」の発表内容に基づいて紹介していきます。

アジェンダ

今回は、以下アジェンダの流れに従って解説します。一部、内容を割愛しているため、詳細は本編を参照ください。

Kubernetesの拡張性
Kubernetes Operatorパターン
Kubernetes Operator開発
Operator SDKを利用した開発プロセス
おわりに

発表資料と動画については、下記のリンクを参照してください。
【資料リンク】
【動画リンク】

Kubernetesの拡張性

コンテナオーケストレーションプラットフォームの1つである「Kubernetes」は、高い拡張性を持っているため、多彩なユースケースを実現できるといわれています。例えば、コンテナアプリケーションの監視やログ収集の仕組みはもちろん、機械学習プラットフォーム、分散ストレージや分散データベースなども実現できます。

最初に、Kubernetesを拡張するための仕組みを見ていきましょう。

一般的にKubernetesの拡張性には主に以下のようなパターンが考えられます。コンテナアプリケーション観点で列挙していますが、Kubernetesそのものにはネットワークなどをはじめ他にも拡張の仕組みがあります。

拡張パターン	概要	ユースケース例	実装難易度	拡張性
Admission Webhook	Kubernetes上のリソースへの操作をトリガーにチェック(Mutating)/変更(Validation)を行う仕組み	デフォルト設定の自動注入/Open Policy Agentなどのポリシーエンジン	低	低
Operatorパターン(Custom Resource Definition)	独自のリソース定義とKubernetes APIの拡張により、ユーザに変わってKubernetes上のリソース操作を行う仕組み	Istio/KnativeなどのOperatorベースのプロダクト	中	中
API Aggregation	kube-apiserver以外にapiserverを実装し、custom apiserverとして拡張する仕組み	Service Catalog/Metrics Server	高	高

以降で取り上げる「Operatorパターン(Custom Resource Definition)」は難易度、拡張性ともに中程度に位置するものです。発表時は、Admission WebhookとAPI Aggregationにも軽く触れているので、興味がある方は資料および動画を参照ください。

これらの拡張性の仕組みをまとめて全体イメージを整理すると、下図のようになります。

この図から分かるように、Kubernetesの拡張性は「kube-apiserverの拡張性」と言い換えることもできます。

Kubernetes Operatorパターン

そもそもKubernetes Operatorとは?

はじめに、Kubernetes Operatorとは何かについて説明します。

Kubernetes Operatorは、Kubernetes公式ドキュメントでは「Operatorパターン」と定義されています。また「Kubernetesのソースコードを修正することなく、クラスターの振る舞いを拡張可能にする」ということが記載されています。

このOperatorパターンにより、ユーザが独自のワークロードをデプロイしたり、運用を自動化できます。例えば、以下のようなことを実現できます。

アプリケーションの状態のバックアップを取得する/バックアップからリストアする
クラスターの回復力をテストするために、全て、または一部分の障害をシミュレートする

また、以下のように、PodやDeploymentといったような標準リソースに加えて、ユーザが独自に作成したリソースを操作できます。

kubectl get ochacafe
kubectl get ochacafe/sample-ocha
kubectl edit ochacafe/sample-ocha

この「Operatorパターン」を実現するために、ユーザの独自リソースを「定義」したものを「Custom Resource Definision/Custom Resource」、ユーザが定義した独自リソースを「扱う」コンポーネントを「Operator(Custom Controller)」と呼びます。

Custom Resource Definision/Custom Resource

Custom Resource Definision(以降、CRD)はユーザ独自のリソース定義で、中身はフィールドの型やフォーマットを示したスキーマです。CRDにより、Kubernetesはユーザが定義する独自のリソースを認識できるようになります。

一方、Custom Resource(以降、CR)は、CRDをもとに定義するユーザ独自のリソースの実体を指します。

具体的な例を挙げると、下図のようになります。

CRDではリソースの実体となるCRの各フィールドのフォーマットが記載されており、"string"や"object"、必須/オプションなどを定義できます。CRでは、CRDで定義したフォーマットをもとに独自リソースの実体を定義していきます。

このCRD/CRが作成されると、/api/ochacafe.oracle.com/v1alpha1/namespace/default/ochacafe/ochacafe-sampleのようにリソースに対するAPIエンドポイントも作成されます。このAPIエンドポイントに対して、クライアント(多くの場合はkubectl)からリクエストを投げることで対象リソースを操作します。

また、CRD/CRにはサブ機能も存在します。今回は、その一部として、ValidationとAdditional Printer Columnsという機能を紹介します。

Validationは、名前の通りユーザがCRを適用した際にCRDで定義したフォーマットと差異があれば、エラーを返却する機能です。CRDはOpenAPI v3.0 Validation Schemaを採用しているため、こちらを利用してバリデーションを行います。

例えば、下図のイメージではOchacafeというCRの.spec.sizeにaaa(期待されるのは整数値)と定義されている場合、CR適用時にgot "string", expected "integer";というエラーを返します。

Additional Printer Columnsは、kubectl getコマンドでCRを取得した際に出力結果として表示したい項目を定義できる機能です。デフォルトではnameとageのみが出力されます。

Operator(Custom Controller)について

Operator(Custom Controller)は、Kubernetes APIの機能を拡張したアプリケーション固有のコントローラーです。OperatorとCustom Controllerという言葉はほとんど同じ意味で語られることが多いため、今回も同じものとして扱います^*1。

*1:CNCFが提供しているOperatorのWhite Paperには、"Technically, there is no difference between a typical controller and an operator. Often the difference referred to is the operational knowledge that is included in the operator. Therefore, a controller is the implementation, and the operator is the pattern of using custom controllers with CRDs and automation is what is looking to be achieved with this. As a result, a controller which spins up a pod when a custom resource is created, and the pod gets destroyed afterwards can be described as a simple controller. If the controller has operational knowledge like how to upgrade or remediate from errors, it is an operator."と記載されています。

以降では、"Operator"という言葉に統一します。

Operatorは、CR(CRD)と連携しながら適切な処理を実行します。Kubernetes自体がGolangで実装されているため、OperatorもGolangで実装されることが多いですが、実際にはKubernetes上のコンテナとして動作すれば良いため、他の言語でも実装できます。

Operatorを語る上で重要な要素が「宣言的オペレーション」と「Reconciliation Loop(調整ループ)」です。どちらもKubernetesを語る上で非常に重要な要素です。

宣言的オペレーションとはKubernetesが実現するオペレーションのコンセプトであり、ユーザが定義したCRを「あるべき状態」としてOperatorに実装されたReconciliation Loopにより、今の状態を「あるべき状態」に収束させていく仕組みです。

一方、Reconciliation Loopは宣言的オペレーションを実現する仕組みで、ユーザが定義したCRに合わせて今の状態を調整します。

Operatorを実装する際には、この宣言的オペレーションとReconciliation Loop(調整ループ)を意識することが非常に重要です。また、Operatorには成熟度モデルがあり、Level1〜5まで定義されています。

Level5である"Auto Pilot"、つまり「運用者による一切の介入なしにOperatorをスケールしたり、障害復旧などを自動で実施可能」というレベルを実現できるのが理想です。しかし、その分コストや難易度が高くなるため、実装するOperatorをどの成熟度レベルまで到達させるのかは検討する必要があります。

最後に、OperatorHubは、Kubernetes Operatorのパブリックリポジトリです。Amazon社、Microsoft社、Google社、RedHat社によって立ち上げられたもので、現在(2023/2)では297のOperatorが登録されています。

OperatorHubには様々なソフトウェアに対応したOperatorが登録されているので、OperatorHubにあるOperatorで事足りる場合は、無理に自作せず、こちらを利用することも問題ありません。とは言え、どうしてもOperatorを自作せざるを得ない場合もあると思います。

Kubernetes Operator開発