1. 概要CRD (カスタム リソース定義) 自体は Kubernetes の組み込みリソース タイプ、つまりカスタム リソースの定義であり、ユーザー定義のリソースがどのようなものかを説明するために使用されます。 CRD 関連の概念: - CRD は、コードを変更せずに Kubernetes API を拡張し、カスタム オブジェクトを管理するために使用できる、v1.7 以降で追加されたメカニズムです。これは実際には、v1.8 で削除された ThirdPartyResources (TPR) のアップグレード バージョンです。
- Kubernetes のユーザーの観点から見ると、Service、Deployment など、YAML の Kind フィールドの内容であるすべてがリソースと呼ばれます。
- Kubernetes では、一般的な組み込みリソースに加えて、ユーザーがリソースをカスタマイズすることができ、CRD はカスタム リソースの定義を表します。
- 新しい CustomResourceDefinition (CRD) を作成すると、Kubernetes API サーバーは指定したバージョンごとに新しい RESTful リソース パスを生成します。
- CRD オブジェクトに基づいて作成されたカスタム リソースは、CRD オブジェクトの spec.scope フィールドの設定に応じて、名前空間スコープまたはクラスター スコープにすることができます。
- CRD オブジェクトを定義すると、指定した名前とスキーマを持つ新しいカスタム リソースが作成されます。 Kubernetes API は、カスタム リソースのストレージおよびアクセス サービスを提供します。 CRD オブジェクトの名前は有効な DNS サブドメイン名である必要があります。
DNS サブドメイン 多くのリソース タイプでは、DNS サブドメインとして使用できる名前が必要です。名前は次の規則を満たす必要があります。
- 253文字を超えることはできません
- 小文字、数字、「-」、および「.」のみを含めることができます。
- 英数字で始まる必要があります
- 英数字で終わる必要があります
CRD 公式ドキュメント: https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ 2. カスタマイズされたリソースカスタム リソースは、Kubernetes API の拡張機能です。 1) カスタムリソースとカスタムコントローラ- リソースは、特定のカテゴリの API オブジェクトのコレクションを格納する Kubernetes API のエンドポイントです。たとえば、組み込みの Pod リソースには、一連の Pod オブジェクトが含まれています。
- カスタム リソースは Kubernetes API の拡張です。カスタム リソースは、特定の Kubernetes インストールのカスタマイズを表します。ただし、Kubernetes のコア機能の多くはカスタム リソースを使用して実装されるようになり、Kubernetes はよりモジュール化されています。
- カスタム リソースは、動的登録を通じて実行中のクラスターに表示および非表示になる可能性があり、クラスター管理者はクラスターとは独立してカスタム リソースを更新できます。
- カスタム リソースがインストールされると、ユーザーは Pod などの組み込みリソースの場合と同様に、kubectl を使用してそのリソース内のオブジェクトを作成およびアクセスできるようになります。
2) カスタムコントローラ- カスタム リソース自体は、構造化データの保存とアクセスにのみ使用できます。カスタム リソースとカスタム コントローラーを組み合わせると、カスタム リソースは真に宣言的な API を提供できます。
- Operator パターンは、カスタム リソースとカスタム コントローラーを組み合わせます。
3) オペレーター紹介 Kubernetes CRD オペレーター = kubernetes CRD + カスタム コントローラー
- Operator は、データベース、キャッシュ、監視システムなどの複雑なステートフル アプリケーションの作成、構成、管理に使用される特定のアプリケーション コントローラーを使用して Kubernetes API を拡張するために CoreOS によって開発されました。
- オペレーターは、Kubernetes のリソースとコントローラーの概念に基づいて構築されますが、アプリケーション固有のドメイン知識も組み込まれています。 Operator を作成するための鍵は、CRD (カスタム リソース) の設計です。
- Operator は、カスタム リソースを使用してアプリケーションとそのコンポーネントを管理する Kubernetes 拡張ソフトウェアです。オペレーターは、特にコントローラーに関しては Kubernetes の哲学に従います。
- Operator パターンは、（Kubernetes 自体が提供する機能を超えて）記述するタスク自動化コードをカプセル化します。
- Kubernetes Operator パターンの概念により、Kubernetes コード自体を変更することなく、コントローラーを 1 つ以上のカスタム リソースに関連付けることで、クラスターの機能を拡張できます。
- Operator は Kubernetes API のクライアントです。 Operator は、管理するリソースに対して強力な自動化機能を提供するように設計されているため、追加のサポート コードも必要です。
1. オペレータフレームワーク Operator Framework は、CoreOS の Operator を迅速に開発するためのオープン ソース ツールキットでもあります。フレームワークは、次の 2 つの主要部分で構成されます。
- Operator SDK - 複雑な Kubernetes API 機能を理解しなくても、独自の専門知識に基づいて Operator アプリケーションを構築できます。
- Operator Lifecycle Manager OLM - クラスター全体で実行中のすべてのOperator（および関連するサービス）のインストール、更新、管理に役立ちます。
2. オペレータのインストールOperator SDK は、新しい Operator を開発するための次のワークフローを提供します。 - SDKを使用して新しいOperatorプロジェクトを作成する
- カスタムリソース（CRD）を追加して新しいリソースAPIを定義する
- SDK APIを使用して監視するリソースを指定します
- オペレータの調整ロジックを定義する
- Operator SDK を使用して Operator デプロイメント マニフェスト ファイルをビルドおよび生成します。
3. オペレーターSDKをインストールするダウンロードアドレス: https://github.com/operator-framework/operator-sdk/releasesoperator sdk 公式ドキュメント: https://sdk.operatorframework.io/docs/installation/ https://github.com/operator-framework/operator-sdk/releases/download/v1.23.0/operator-sdk_linux_amd64を実行します。
# 実行権限を追加する
chmod + x 演算子- sdk_linux_amd64
# ソフトリンクを追加
ln -s / opt / k8s / crd /演算子/演算子- sdk_linux_amd64 / usr /ローカル/ bin /演算子- sdk 4. オペレーターは使いやすい[例1] 素早く簡単に使える オペレーター- sdk init --domain=example.com --repo=github.com/example-inc/memcached-operator
# ステップ 2 : API を作成する (演算子- sdk create api --group cache --version v1 --kind Memcached --resource=true --cnotallow=true)
演算子- SDK作成API --group キャッシュ --version v1 --kind Memcached --resource=true --cnotallow=true
# ステップ 3 :イメージをビルドします- docker 環境がローカルに存在する必要があります (make docker - build IMG = liumiaocn / memcache : v1)
docker -build img = liumiaocn / memcache : v1 を実行します。
# ステップ 4 : Operator を実行-環境には K8s / K3s が必要です (make install && make deploy IMG = liumiaocn / memcache : v1)
インストールしてデプロイします IMG = liumiaocn / memcache : v1
# ステップ5: カスタムリソースを作成する
kubectl apply -f config /サンプル/ cache_v1_memcached .yaml
# ステップ 6: CR と関連リソースを削除する (kubectl delete - f config / samples / cache_v1_memcached .yaml )
kubectl delete -f config /サンプル/ cache_v1_memcached .yaml これは単なる簡単なインストールと展開です。 Operator の詳細については後ほど別の記事で紹介したいと思います。 4) Kubernetes API集約レイヤー- 集約レイヤーを使用すると、ユーザーは Kubernetes コア API によって提供される機能に制限されることなく、追加の API を通じて Kubernetes を拡張できます。ここでの追加 API は、メトリック サーバーなどの既成のソリューション、または独自に開発した API にすることができます。
- 集約レイヤーはカスタム リソースとは異なります。後者の目的は、kube-apiserver が新しいオブジェクト カテゴリ (Kind) を認識できるようにすることです。
- 集約レイヤーは kube-apiserver プロセス内で実行されます。拡張リソースが登録されるまで、集約レイヤーは何も実行しません。
- API を登録するには、Kubernetes API で URL パスを「要求」するために使用する APIService オブジェクトを追加します。今後、集約レイヤーは、その API パス (例: /apis/myextension.mycompany.io/v1/…) に送信されたすべてのものを登録された APIService に転送します。
5) 宣言型API通常、宣言型 API では次のようになります。 - API は、比較的少数の小さなサイズのオブジェクト (リソース) で構成されています。
- オブジェクトは、アプリケーションまたはインフラストラクチャの構成情報を定義します。
- オブジェクトの更新操作の頻度は低くなります。
- 通常、オブジェクトを読み取ったり書き込んだりするには人間が必要です。
- オブジェクトに対する主な操作は CRUD スタイル (作成、読み取り、更新、削除) です。
- オブジェクト間のトランザクション サポートは必要ありません。API オブジェクトは、実際の状態ではなく、望ましい状態を表します。
命令型 API は宣言型 API とは異なります。以下は、API が宣言的ではない可能性があることを示す兆候です。 - クライアントは「この操作を実行する」という命令を発行し、操作が完了すると同期応答を受け取ります。
- クライアントは「この操作を実行する」という命令を発行し、操作 ID を取得します。その後、Operation オブジェクトをチェックして、要求が正常に完了したかどうかを判断する必要があります。
- API はリモート プロシージャ コール (RPC) に似ています。
- 大量のデータを直接保存します。たとえば、オブジェクトごとに数キロバイト、または数千のオブジェクトを格納します。
- 高いアクセス帯域幅が必要です (長時間にわたって 1 秒あたり数十件のリクエスト)。
- エンドユーザー データ (画像、個人識別情報 (PII) など) や、アプリケーションによって処理されるその他の大規模データを保存します。
- オブジェクトに対して実行される通常の操作は CRUD スタイルではありません。
6) カスタムリソースを追加するKubernetes では、クラスターにカスタム リソースを追加する方法が 2 つ用意されています。 - CRD は比較的シンプルで、CRD を作成するためにプログラミングは必要ありません。
- API 集約にはプログラミングが必要ですが、データの保存方法や異なる API バージョン間での変換方法など、API の動作をより細かく制御できます。
Kubernetes は、使いやすさや柔軟性を犠牲にすることなく、さまざまなユーザーのニーズを満たすために両方のオプションを提供します。 - 集約 API は、メイン API サーバーの背後で実行されるいくつかの下位レベルの API サーバーを指します。メイン API サーバーはプロキシ方式で動作します。この形式の組織は API Aggregation (AA) と呼ばれます。ユーザーにとっては、Kubernetes API のみが拡張されたように見えます。
- CRD を使用すると、ユーザーは新しい API サーバーを追加することなく、新しいリソース タイプを作成できます。 CRD を使用する場合、API 集約を理解する必要はありません。
CRDS
| 集約API
| プログラミングは必要ありません。ユーザーは、CRD コントローラーを実装するために任意の言語を選択できます。
| 実行可能ファイルとイメージのプログラミングとビルドが必要です。
| 追加のサービスを実行する必要はありません。 CRD は API サーバーによって処理されます。
| 追加のサービスを作成する必要があり、無効になる可能性があります。
| CRD が作成されると、継続的なサポートは必要ありません。バグ修正は、Kubernetes マスターのアップグレード中に自動的にロールインされます。
| 定期的にアップストリームからバグ修正を取得し、集約 API サーバーを更新する必要がある場合があります。
| API の複数のバージョンを扱う必要はありません。たとえば、リソースのクライアントを制御する場合は、API との同期を維持するためにクライアントを更新できます。
| API の複数のバージョンを処理する必要がある。たとえば、多くの人と共有することを目的とした拡張機能を開発する場合などです。
| CRUD 操作のみがサポートされており、「logs」や「exec」などの操作はサポートされていません。
| CRUD 以外の操作もサポートします。
|
7) カスタムリソースにアクセスする Kubernetes クライアント ライブラリを使用してカスタム リソースにアクセスできます。すべてのクライアント ライブラリがカスタム リソースをサポートしているわけではありません。 Go および Python クライアント ライブラリがサポートされています。
新しいカスタム リソースを追加したら、次のいずれかの方法でアクセスできます。 - kubectl
- Kubernetes DynamicClient は、CRD カスタム リソースを含む任意の Kubernetes リソースに対して RESTful 操作を実行できます。
- あなたが書いたRESTクライアント
- Kubernetes クライアント ジェネレーターによって生成されたクライアントを使用します。クライアントの生成は少し難しいですが、一部のプロジェクトではCRDまたは集約APIとともにクライアントが提供される場合があります。
3. CRDの例のデモンストレーション1) CRD（カスタムリソース）を作成する新しい CustomResourceDefinition (CRD) を作成すると、Kubernetes API サーバーは指定したバージョンごとに新しい RESTful リソース パスを生成します。 CRD オブジェクトに基づいて作成されたカスタム リソースは、CRD オブジェクトの spec.scope フィールドの設定に応じて、名前空間スコープまたはクラスター スコープにすることができます。
cat >リソース定義.yaml << EOF
apiバージョン: apiextensions .k8s .io / v1
種類:カスタムリソース定義
メタデータ:
# 名前は以下の仕様フィールドと一致している必要があり、形式は'<名前の複数形>.<グループ名>' です。
名前: crontabs.stable.example.com
仕様:
# REST API で使用されるグループ名: / apis /<group> / <version>
グループ: stable .example .com
# この CustomResourceDefinition でサポートされているバージョンを一覧表示します
バージョン:
-名前: v1
# 各バージョンは、servedフラグを使用して個別に有効化または無効化できます
提供： true
# ストレージバージョンとしてマークできるバージョンは 1 つだけです
ストレージ: true
スキーマ:
オープンAPIV3スキーマ:
タイプ:オブジェクト
プロパティ:
仕様:
タイプ:オブジェクト
プロパティ:
cronスペック:
タイプ:文字列
画像：
タイプ:文字列
レプリカ:
タイプ:整数
# 名前空間またはクラスター化可能
スコープ:名前空間
名前:
# URL で使用される名前の複数形: / apis /<group> /<version> /<名前の複数形>
複数形: crontabs
# コマンドラインで使用したり、表示したりするときに別名として使用される名前の単数形
単数形: crontab
# kind は通常、単数形の CamelCase です。リソース リストではこの形式が使用されます。
種類: CronTab
# shortNamesを使用すると、コマンドラインでリソースを一致させるために短い文字列を使用できます
短縮名:
-ct
終了 実行 作成 kubectl apply -fリソース定義.yaml 新しい名前空間 RESTful API エンドポイントが次の場所に作成されます: /apis/stable.example.com/v1/namespaces/ オブジェクトの種類は、上記で作成した仕様の CronTab になります。 Kubernetes (k8s) APIの操作については、前回の記事「Kubernetes (k8s) API Server 詳細説明」を参照してください。 kubectl get --raw /apis/stable.example.com/v1/
kubectl get --raw /apis/stable.example.com/v1/|python -m json.tool 2) カスタムオブジェクト（カスタムコントローラ）を作成する CustomResourceDefinition オブジェクトを作成した後、カスタム オブジェクト (カスタム オブジェクト) を作成できます。カスタム オブジェクトにはカスタム フィールドを含めることができます。これらのフィールドには任意の JSON データを含めることができます。次の例では、cronSpec および image カスタム フィールドが、CronTab クラスのカスタム オブジェクトに設定されています。 CronTab クラスは、上記で作成した CRD の仕様から取得されます。
cat > my - crontab .yaml << EOF
apiバージョン: "stable.example.com/v1"
種類: CronTab
メタデータ:
名前:私の新しいcronオブジェクト
仕様:
cronSpec : "* * * * * /5"
画像:私の-素晴らしい- cron -画像
終了 そして、create コマンドを実行します。 kubectl apply -f my - crontab .yaml kubectl を使用して CronTab オブジェクトを管理できます。例えば： kubectl crontab を取得する
kubectl get ct -o yaml 3) CustomResourceDefinitionを削除するCustomResourceDefinition を削除すると、サーバーは RESTful API エンドポイントをアンインストールし、サーバーに保存されているすべてのカスタム オブジェクトを削除します。 kubectl delete -fリソース定義.yaml
kubectl crontab を取得する | 
