コンテンツにスキップ

Custom Controller

はじめに

本サイトにつきまして、【IT技術の知見】はじめに - 俺の技術ノート をご認識のほど宜しくお願いいたします。


01. Custom Controller とは

カスタムリソースのための kube-controller に相当する。

ただし、kube-controller とは異なり Node 上で稼働する。

実体は Deployment や StatefulSet 配下の Pod であることが多い。


02. Custom Controller の仕組み

アーキテクチャ

Custom Controller は、client-go コンポーネントと custom-controller コンポーネントから構成される。

kubernetes_custome-controller_architecture


client-go コンポーネント

▼ client-go コンポーネントの仕組み

リフレクター、インフォーマー、インデクサーから構成される。

▼ リフレクター

kube-apiserver から Kubernetes リソースのマニフェストの変更を検知する。

また、変更内容に応じて作成した Kubernetes リソースの実体を Delta FIFO キューに格納する。

▼ インフォーマー

Delta FIFO キューから Kubernetes リソースの実体を取得する。

また、取得した実体をインデクサーを介して保管し、Kubernetes リソースの種類に応じてリソースイベントハンドラーをコールする。

▼ インデクサー

キャッシュとして、Kubernetes リソースの実体を Node のメモリ上に保管する。


custom-controller コンポーネント

▼ custom-controller コンポーネントとは

リソースイベントハンドラー、ワークキュー、アイテム処理から構成される。

これらを組み合わせて、Reconciliation を実行する。

▼ リソースイベントハンドラー

Informer から Kubernetes リソースの作成、更新、削除のイベントを受け取り、対象の Kubernetes リソースのキーをワークキューに追加する。

▼ ワークキュー

処理対象の Kubernetes リソースのキーを保管するキューであり、アイテム処理はワークキューからキーを取り出して Reconciliation を実行する。


03. reconciliation

処理の仕組み

custom_controller

  1. Custom Controller は、kube-apiserver を介して、etcd に watch イベントを送信している。

  2. カスタムリソースと CRD のマニフェストを何らかの方法 (例：kubectl apply コマンド、kubectl edit コマンドなど) で etcd 上に永続化したとする。

  3. Custom Controller は、etcd 上でカスタムリソースと CRD のマニフェストを検知し、実際にカスタムリソースを作成/変更する。

クライアントからのマニフェストの作成/変更は、etcd 上のマニフェストの設定値を変更しているのみで、実際のカスタムリソースを作成/変更しているわけではないことに注意する。

その他、etcd 上のカスタムリソースに応じて、外部サービスの API (例：証明書の Fastly) をコールする。そして、カスタムリソースとペアになるもの (例：Fastly の証明書) も作成できる。

注意点として、CRD を削除すると kube-controller はカスタムリソースを削除する。

このとき CRD をあらためて作成しても、kube-controller はカスタムリソースを自動的に作成しない。

kube-controller に不具合があると、etcd 上の CRD の通りにカスタムリソースが作成されない。


reconciliation ループ

kube-controller-manager は、Node にある Custom Controller を反復的に実行する。

これにより、カスタムリソースは CRD の宣言通りに定期的に修復される (reconciliation ループ) 。

ただし、Custom Controller 自体は kube-apiserver クライアント (例：kubectl クライアント、Kubernetes リソースなど) が作成する必要がある。


04. セットアップ

実装パターン

▼ 自前で実装する場合

Custom Controller を自前で実装する。

▼ OSS を使用する場合


05. Operator パターン

Operator パターンとは

Custom Controller を内蔵し、特定のカスタムリソースをセットアップする責務を持つ。


Operator パターンの仕組み

▼ アーキテクチャ

Operator パターンは、カスタムリソース、Custom Controller の Operator、認可スコープ付与リソース、といったコンポーネントから構成されている。

kubernetes_operator_architecture

▼ Operator

Custom Controller として動作する。

Custom Controller と同様に、実体は Deployment や StatefulSet 配下の Pod であることが多い。

Operator がいる状況で、カスタムリソースと CRD のマニフェストを何らかの方法 (例：kubectl apply コマンド、kubectl edit コマンドなど) で etcd 上に永続化したとする。

すると Operator は、operator は etcd 上でカスタムリソースと CRD のマニフェストを検知し、実際にカスタムリソースを作成/変更する。

反対に、CRD を削除すると、Operator はカスタムリソースを削除する。

このとき CRD をあらためて作成しても、Operator はカスタムリソースを自動的に作成しない。

Operator に不具合があると、etcd 上の CRD の通りにカスタムリソースが作成されない。

Operator は関連するすべての CRD を要求し、たとえその CRD に対応するカスタムリソースを作成しないとしても、CRD だけは永続化しておく必要がある。(例：Prometheus 系の CRD をすべて作成しないと、PrometheusOperator がエラーになる)

kubernetes_operator-controller

▼ 認可スコープ付与リソース

Operator が kube-apiserver にリクエストを送信できるように、Operator に認可スコープを付与する。


Operator パターンの例

OperatorHub で公開されている。

  • ArgoCDOperator
  • IstioOperator
  • PrometheusOperator
  • ...


06. Operator のフレームワーク

KubeBuilder

CRD とカスタムコントローラーを開発するためのフレームワークであり、controller-runtime パッケージと controller-tools パッケージを使用したコードの雛形を作成する。


OperatorFramework

▼ OperatorFramework とは

Operator を開発するためのフレームワークのこと。

▼ Operator SDK

Operator を、開発、テスト、リリース、ために必要なツールを提供する。

▼ Operator Lifecycle Manager

Operator の、作成、削除を管理する。

▼ Operator Metering

Operator が提供するサービスの使用状況をレポートする。