CustomControllerでinformerを使ってリソースの追加や更新といったイベント毎に処理を行う

Hello Custom Controller!ではカスタムリソースの取得を素朴にループで実装している。しかし、code-generatorにはinformer-genというコマンドがあり、これを使うとリソースの追加や更新、削除といったイベントに対応して任意の処理を実行することが出来る。コードの見通しもよくなるので、informerを使った形に書き換えてみよう。

準備

kubernetes v1.12.3を使う。minikubeで環境を作成:

  • go: v1.11.2

informer用のコードを生成する

code-generatorのinformer-genを使う。

コントローラーの実装

informerを素朴に使った実装は以下の通り。リソースの追加、更新、削除に対応して任意の処理を実行できる。

後はビルドしてデプロイするだけ。注意点として、使用するサービスアカウントがリソースをwatchできる必要があるのでRoleの更新が必要。

カスタムリソースを追加するとaddFunc関数が呼び出されることが確認できる。

informerを使えばイベントに応じて任意の処理を書くことが出来る、ということを確認出来た。code-generatorでコードを生成できるので、基本的にはinformerを使っていくのがよさそうだなあ。

Hello Custom Controller!

2019年はカスタムコントローラーや!ということで2018年末頃から少しづつ調べている。まずは非常に簡単なものを動かしてみる。

Custom Controller is…

CRDについてのメモにも書いたが、CRD自体はただのデータなので、それだけでは何も起こらない。Kubernetesのdeclarative APIを活用するためにはコントローラーの作成が必要。なお、本記事は以下のページを参考にしています。

作っていく

カスタムコントローラーを作っていくわけだが、いきなり複雑なものを作るのは難しい。そこで、まずはカスタムリソースを読み込み、ログに出力するだけのコントローラーを作る。カスタムコントローラー用のSDKやBuilderがいろいろあるようだがこれも使わず、KubernetesのAPI用コードを出力するだめの code-generator を用いて素朴に作ってみる。code-generatorはいくつかの機能を持っている。

  • deepcopy-gen – 各型についてDeepCopy用のメソッドを生成
  • client-gen – カスタムリソースを扱うためのクライアントセットを生成
  • informer-gen – カスタムリソースの変更に対応するためのイベントベースインターフェースを生成
  • lister-gen – GetとListについて、読み取り用キャッシュレイヤを扱うコードを生成

本格的にカスタムリソースを扱うためにはinformer-genやlister-genが必要になるが、今回はdeepcopy-genとclient-genのみ。deepcopy-genも不要な気がするが、これなしでうまく動かす方法がちと分からなかった。

生成元のコードを用意する

まずは apis/foo/v1alpha/doc.go

次にapis/foo/v1alpha/register.go

最後にapis/foo/v1alpha/types.go

コード生成

これらのファイルを用意したら、code-generatorでコードを生成する。なお、code-generatorのバージョンは kubernetes-1.12.3を使用。

カスタムコントローラーを実装

これで、GoからFooリソースを扱うことが出来る。カスタムコントローラー用のコードを書いていく:

コントローラー用のマニフェスト。defaultアカウントがオブジェクトを取得できるようにRBACの設定も行っている:

デプロイして動作確認する

カスタムコントローラーのビルドからKubernetesへのデプロイまで行うためのMakefile:

デプロイする:

カスタムコントローラーのログを見ると、Fooリソースを取得してログに出力していることが確認できた:

非常にシンプル、というかとくに何もしていないが、カスタムコントローラーができたといっていいだろう。理屈ではログ出力の部分をロジックに置き換えればいいはず。実際にはinformerを用いてイベントベースで処理を行うようなコードになるのだと思う。次はログ出力だけではなく別リソースを扱うようにしていきたい。

ソースコードなどはtakaishi/hello2019にあります。

CRDについてのメモ

Kubernetesのカスタムリソースについてのメモ。基本的には公式ドキュメントの Custom Resources にいろいろと説明が書かれているのでここを読めばよい。カスタムリソース自体は構造化されたデータをKubernetes上に保存・取得できる機能といえる。これにカスタムコントローラを組み合わせることで、Deploymentのようなビルトインリソースと同じような宣言的APIを用いた状態管理を実現できるようになる。データ保存だけなら必ずしもカスタムコントローラーは必要ではないというのが最初分かっていなかった。

軽く試す。使用バージョンは以下の通り:

  • Kubernetes v1.12.3
  • minikube v0.32.0

検証用環境はminikubeで起動:

kubernetes/sample-controller を参考にしつつ、CRD用のマニフェストを作成する。グループやバージョンがリソースへアクセスする際のAPIとなる(/apis/<group>/<version>)。リソースのkindや単数形、複数形なども定義できる。

このマニフェストを適用すると、以下のようにcrdリソースとして見えるようになる:

Fooリソースを作ってみる。以下のようなマニフェストを用意し、 kubectl applyする:

Fooリソースが作成されていることがわかる:

リソースの詳細を見ると、マニフェストで指定したspecが確認できる:

リソース毎にspecが異なることも確認できる:

CRDでバリデーションを行うこともできる(OpenAPIv3.0を使うようだ)。kubernetes/sample-controller を見つつ、replicasのバリデーションを設定してみる:

これで、replicasの最小値と最大値が設定される。replicasが10より大きいマニフェストを用意して適用してみる:

バリデーションに引っかかり、作成に失敗することが確認できた。

API Aggregationというものもあるようだが、そちらはまた今度。

参考: