Custom Controller＠カスタムリソース¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. Custom Controllerとは¶
カスタムリソースのための kube-controller に相当する。
ただし、kube-controller とは異なり Node 上で稼働する。
実体は Deployment や StatefulSet 配下の Pod であることが多い。
02. Custom Controllerの仕組み¶
アーキテクチャ¶
Custom Controller は、client-go コンポーネントと custom-controller コンポーネントから構成される。
client-goコンポーネント¶
▼ client-goコンポーネントの仕組み¶
リフレクター、インフォーマー、インデクサー、から構成される。
▼ リフレクター¶
kube-apiserver から Kubernetes リソースのマニフェストの変更を検知する。
また、変更内容に応じて作成した Kubernetes リソースの実体を Delta FIFO キューに格納する。
▼ インフォーマー¶
Delta FIFO キューから Kubernetes リソースの実体を取得する。
また、取得した実体をインデクサーを介して保管し、Kubernetes リソースの種類に応じてリソースイベントハンドラーをコールする。
▼ インデクサー¶
キャッシュとして、Kubernetes リソースの実体を Node のメモリ上に保管する。
custom-controllerコンポーネント¶
▼ custom-controllerコンポーネントとは¶
リソースイベントハンドラー、ワークキュー、アイテム処理、から構成される。
これらを組み合わせて、Reconciliation を実行する。
▼ リソースイベントハンドラー¶
記入中...
▼ ワークキュー¶
記入中...
03. reconciliation¶
処理の仕組み¶
(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、認可スコープ付与リソース、といったコンポーネントから構成されている。
▼ 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 がエラーになる)
- https://developers.redhat.com/articles/2021/06/22/kubernetes-operators-101-part-2-how-operators-work
- https://stackoverflow.com/questions/47848258/what-is-the-difference-between-a-kubernetes-controller-and-a-kubernetes-operator
- https://www.howtogeek.com/devops/what-are-kubernetes-controllers-and-operators/
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#delete-a-customresourcedefinition
▼ 認可スコープ付与リソース¶
Operator が kube-apiserver にリクエストを送信できるように、Operator に認可スコープを付与する。
Operatorパターンの例¶
OperatorHub で公開されている。
- ArgoCDOperator
- IstioOperator
- PrometheusOperator
- ...
06. Operatorのフレームワーク¶
KubeBuilder¶
記入中...
OperatorFramework¶
▼ OperatorFrameworkとは¶
Operator を開発するためのフレームワークのこと。
▼ Operator SDK¶
Operator を、開発、テスト、リリース、ために必要なツールを提供する。
▼ Operator Lifecycle Manager¶
Operator の、作成、削除を管理する。
▼ Operator Metering¶
記入中...