metacontroller

●STEP5:Operatorのテスト

Operator SDKにより、プロジェクト作成時にcontrollers/suite_test.goにテストスイートが作成されています。テストスイートを見てみると、下図のようになっています。

ここで、envtestについて補足しておきます。envtestはcontroller-runtimeに含まれているテストユーティリティパッケージです。擬似的なkube-apiserverとetcdを起動してOperatorのテストを実行します。

使い方の概要は、以下の通りです。

• envtest.Environment.Start()でAPI Serverとetcdの起動
  • 返却値としてAPI Serverにアクセスするためのrest.Config(kubeconfigにあたる)を取得
• rest.Configからkubernetes.Clientsetを作成
• kubernetes.Clientsetを利用して、CRや標準リソースを作成・削除したりすることが可能
• envtest.Environment.Stop()でAPI Serverとetcdの停止

Operatorのテストは、このenvtestを利用して実施します。実際のテストケースはcontrollers/ochacafe_test.goに実装します。今回実装するOperatorに対するサンプルテストケースはのイメージは下図の通りです。

この例では、BeforeEach関数で環境のリセットや対象OperatorのReconcile関数を起動しています。また、It()がテストケースの1つ分になっており、このテストケースの中でCRを作成し、リソースが想定される状態になっているかどうかを確認します。例えば、今回の場合はCRで指定されたイメージやReplica数になっているかどうかという点です。

テストケースの実装が終わったら、makeコマンドを利用してテストを実行します。実行イメージは以下の通りです。

make test

実行結果は、以下のイメージです。

/ochacafe-operator-intro/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
/ochacafe-operator-intro/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."
go fmt ./...
go vet ./...
KUBEBUILDER_ASSETS=”/Library/Application Support/io.kubebuilder.envtest/k8s/1.21.4-darwin-amd64" go test ./... -coverprofile cover.out
?       github.com/oracle-japan/ochacafe-operator-intro [no test files]
?       github.com/oracle-japan/ochacafe-operator-intro/api/v1alpha1    [no test files]
ok      github.com/oracle-japan/ochacafe-operator-intro/controllers      8.632s  coverage: 62.7% of statements

また、カバレッジレポートを出力したい場合は以下のように実行します。この場合は、HTML形式でレポートが出力されます。

go tool cover -html=cover.out -o cover.html

●STEP6:デプロイ

最後に、実装したOperatorをKubernetes環境にデプロイします。デプロイの方法は2つあります。

• OLMを利用したデプロイ
• makeコマンドでのデプロイ

それぞれについて説明する前に、まずは共通する手順としてOperatorをコンテナイメージとしてビルド/プッシュします。コンテナイメージのプッシュ先はMakefileに定義することになっているので、必要に応じて変更します。

make docker-build docker-push

ここから、2つのデプロイ方法に分けて見ていきます。

• OLMを利用したデプロイの場合
  OLM(Operator Lifecycle Manager)を利用する場合は、まずOLMそのもののインストールから開始します。
  

  operator-sdk olm install

  次に、バンドルイメージのビルドとプッシュを行います。バンドルイメージとは、OLMとOperatorをパッケージ化したイメージです。
  

  make bundle bundle-build bundle-push

  最後にデプロイを行います。デプロイにはoperator-sdkコマンドを利用します。
  

  operator-sdk run bundle nrt.ocir.io/orasejapan/ochacafe_sample_operator-bundle:v0.0.1

  これでOperatorがデプロイされます。
• makeコマンドでのデプロイ
  こちらは非常にシンプルで、以下のコマンドを実行するだけでOperatorがデプロイされます。
  

  make deploy

  補足ですが、いずれのデプロイ方法の場合も、kustomizeを利用してManifestをビルド(kustomizeコマンドはMakefileに記載)します。

以上がOperaror SDKを利用した開発プロセスです。当日のセッションでは、ここで開発したOperatorを実際に動作させているので、興味がある方は動画を確認してください。

metacontroller

最後に、参考情報としてmetacontrollerというアドオン機能を紹介します。

metacontrollerは、Google社が開発していたKubernetesアドオン機能の1つで、現在は別リポジトリでオープンソースとして開発が継続中です。最新バージョンはv4.7.4(2023/2現在)です。

metacontrollerはWebhookを利用してスクリプト形式で実装し、Operatorをデプロイできる仕組みです。仕組みの概要は“metacontroller server”が“CompositeController”と“DecoratorController”(合わせて“lambda controller”と呼ばれる)を呼び出し、必要な処理を実行します。

“lambda controller”の実体は対象のCRとWebhookのエンドポイントを定義したDeploymentです。Webhookのロジックとして実装に集中できるため、より簡易的にOperatorを実装できます。また、Webhookのエンドポイントを実装できれば良いので、言語的な制限もありません。今回紹介したシンプルなOperatorであれば、metacontrollerで十分に実装できます。

おわりに

ここまで、Kubernetesの拡張性から「Kubernetes Operatorパターン」を取り上げ、Operatorの仕組み、SDK、開発プロセスについて見てきました。Kubernetesがかなり普及してきた中で、ユーザ独自のワークロードやアプリケーションを運用する機会も増えてきていると思います。

また、Kubernetes上で動作するミドルウェアやデーターベースなども、今回紹介した「Operatorパターン」を利用しているものがほとんどです。従来の「職人技」と言われてきた作業や「手動運用」を「コード」に落とし込み、Operatorを利用して運用を自動化することでアプリケーションやワークロードの可能性を無限大に拡張できます。

本記事が、読者の皆さまが運用されているコンテナアプリケーションやその環境に対する何かしらのお役に立てれば幸いです。