custom-controller＠カスタムリソース¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. custom-controllerとは¶
カスタムリソースのためのkube-controllerに相当する。
ただし、kube-controllerとは異なりNode上で稼働する。
実体はDeploymentやStatefulSet配下のPodであることが多い。
02. custom-controllerの仕組み¶
アーキテクチャ¶
custom-controllerは、client-goコンポーネントとcustom-controller-componentsコンポーネントから構成される。
client-goコンポーネント¶
▼ client-goコンポーネントの仕組み¶
リフレクター、インフォーマー、インデクサー、から構成される。
▼ リフレクター¶
kube-apiserverからKubernetesリソースのマニフェストの変更を検知する。
また、変更内容に応じて作成したKubernetesリソースの実体をDelta FIFOキューに格納する。
▼ インフォーマー¶
Delta FIFOキューからKubernetesリソースの実体を取得する。
また、取得した実体をインデクサーを介して保管し、Kubernetesリソースの種類に応じてリソースイベントハンドラーをコールする。
▼ インデクサー¶
キャッシュとして、Kubernetesリソースの実体をNodeのメモリ上に保管する。
custom-controller-componentsコンポーネント¶
▼ custom-controller-componentsコンポーネントとは¶
リソースイベントハンドラー、ワークキュー、アイテム処理、から構成される。
これらを組み合わせて、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自体はkubectlクライアントが作成する必要がある。
04. セットアップ¶
既にあるものを使用する¶
自前で実装する¶
custom-controllerを自前で実装する。
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¶
記入中...