Pedia
コンピュータ科学

シーアールディー

しーあーるでぃー

CRD (Custom Resource Definition) は、コンテナオーケストレーションシステムKubernetesの標準APIを動的に拡張するためのメカニズムである。これを用いることで、ユーザーはPodやServiceといった組み込みリソースと同様の形式で、アプリケーション固有の設定や外部サービスの構成を記述・管理する独自のリソースタイプ（カスタムリソース）を定義できる。Kubernetesの宣言的な管理モデルを拡張し、特にOperatorパターンを実現する上での基盤技術となる重要な機能である。

#Kubernetes#クラウド#API#コンテナ
最終更新:

Kubernetes APIの拡張メカニズムとしての機能詳細

CRDの核心は、KubernetesのAPIサーバーに新しいリソースタイプを動的に登録し、既存のリソースと同じエンドポイントと永続性メカニズム（etcd）を利用可能にする点にある。

CRDをクラスターに適用する際、ユーザーは以下の要素を定義する必要がある。

  1. 名前とグループ (Name and Group): リソースを識別するためのグループ名（例: monitoring.coreos.com）と、複数形のリソース名（例: servicemonitors）を決定する。これにより、APIサーバー内で一意のエンドポイント（例: /apis/monitoring.coreos.com/v1/servicemonitors）が生成される。
  2. スコープ (Scope): そのリソースが単一の名前空間（Namespace-scoped）に属するか、クラスター全体（Cluster-scoped）に適用されるかを指定する。
  3. バージョン (Versions): リソースのバージョン情報（例: v1alpha1, v1beta1, v1）を定義し、どのバージョンが「Storage Version」としてetcdに保存されるかを指定する。
  4. スキーマ (Schema): JSON Schema形式を用いて、カスタムリソースの仕様（spec）と状態（status）フィールドの構造、データ型、必須フィールド、値の制約などを厳密に定義する。このスキーマ定義に基づき、APIサーバーはリソース作成時や更新時のバリデーションを自動的に行う。

このように、CRDは単にデータを保存する場所を提供するだけでなく、Kubernetesの宣言的なAPI設計に完全に準拠した形で、アプリケーション固有の設定を扱うための厳密な枠組みを提供する。ユーザーが定義したカスタムリソースのインスタンス（CR）は、標準リソースと同様にetcdに格納され、変更が発生した際にはAPIサーバーがイベントとして通知を発行する。

具体的な使用例・シーン

CRDは、Kubernetesの管理対象をアプリケーションのライフサイクル管理、クラウドインフラストラクチャのプロビジョニング、高度なネットワーク設定など、多岐にわたる領域に拡張するために利用されている。

1. Operatorパターンによる複雑なアプリケーションの自動化

CRDの最も重要な応用例はOperatorパターンである。Operatorは、CRDによって定義されたカスタムリソースの状態を監視し、Kubernetesの標準機能だけでは実現できない、人間が行うような複雑な運用タスクを自動化する。

例えば、クラウドネイティブなデータストアであるCephをKubernetes上で運用する場合、Rook Operatorが導入される。RookはCephClusterというCRDを提供し、ユーザーがこのCRを作成すると、Operatorがそれを読み取り、必要な数のストレージノードのプロビジョニング、レプリケーション設定、ヘルスチェック、障害時の自動復旧といった一連の複雑なストレージ管理タスクを自動実行する。これにより、ステートフルアプリケーションの運用負荷が大幅に軽減される。

2. インフラストラクチャの宣言的プロビジョニング

CRDは、クラウドプロバイダーのインフラストラクチャをKubernetesのAPIを通じて管理するためのインターフェースとしても機能する。例えば、Crossplaneのようなプロジェクトは、AWSやAzureなどの外部クラウドサービス（S3バケット、RDSデータベース、ロードバランサーなど）を定義するためのCRDを提供している。これにより、アプリケーション開発者は、インフラストラクチャのプロビジョニングとアプリケーションのデプロイメントを、統一されたKubernetesマニフェスト内で宣言的に管理できるようになる。

3. CI/CDパイプラインの定義

TektonやArgo WorkflowsといったクラウドネイティブなCI/CDツールは、パイプラインのタスク、ステージ、実行環境などをCRDとして定義している。これにより、CI/CDの定義自体がKubernetesリソースとして扱われ、GitOps環境下で設定変更のバージョン管理や監査が容易になる。

メリット・デメリットと運用上の考慮事項

メリット

CRDの導入は、Kubernetesクラスターの管理と拡張において以下の大きな利点をもたらす。

  1. 統一された操作性: 全ての管理操作をkubectlやKubernetesクライアントライブラリを通じて行えるため、運用ツールやプロセスを統一できる。新たな独自ツールセットを開発・習得する必要がない。
  2. 組み込みのセキュリティと監査: CRDを通じて作成されたカスタムリソースは、KubernetesのネイティブなRBAC（Role-Based Access Control）システムによって保護される。これにより、ユーザーやサービスアカウントごとに、特定のリソースに対するアクセス権限を細かく制御でき、監査ログも自動的に記録される。
  3. 高度な抽象化: 複雑なシステムや運用手順を、シンプルで宣言的なリソース定義として抽象化し、開発者やユーザーがインフラストラクチャの詳細に煩わされることなく、高レベルな要求を記述できるようになる。

デメリットと考慮事項

一方で、CRDを導入し運用する際には、いくつかの注意が必要である。

  1. クラスターの複雑化: クラスターに多数のCRDを導入すると、クラスターのAPIスキーマが肥大化し、管理者が把握すべきリソースの種類が増加する。不必要なCRDは削除するなど、定義の整理が求められる。
  2. APIの設計責任: CRDの設計者は、バージョニング、スキーマ定義、互換性の維持といった、API設計者としての責任を負うことになる。特に、フィールド名の変更や型の変更は、ダウンストリームのユーザーに大きな影響を与えるため、慎重な検討が必要である。
  3. etcdへの負荷: カスタムリソースが頻繁に更新される場合、そのデータが保存されているetcdに負荷がかかる。特に大規模なカスタムリソース（データ量が大きいオブジェクトや、非常に数が多いオブジェクト）を扱う際には、etcdの性能とスケーラビリティを考慮する必要がある。

関連する概念：OperatorパターンとWebhooks

CRDは静的な「定義」を提供するが、その定義に基づく動的な動作、すなわちカスタムリソースの実現と維持には、密接に関連する追加の技術要素が必要となる。

Operatorパターン

前述の通り、OperatorはCRDを有効活用するための実行エンジンである。Operatorは、CRDが定義するカスタムリソースの状態を監視する制御ループ（Reconcile Loop）として機能し、ユーザーが宣言した「望ましい状態」と「現在の状態」を比較し、差分があればそれを解消するための操作を実行する。CRDとOperatorは表裏一体の関係にあり、高度な自動化を実現するためには両者が不可欠である。

Webhooks（Admission Webhook）

CRDのスキーマ定義（JSON Schema）は強力であるが、特定のビジネスロジックに基づくより複雑な検証や、リソースが永続化される直前のデータ変更（ミューテーション）はスキーマだけでは処理できない。このため、KubernetesはAdmission Webhookというメカニズムを提供する。

  1. Validating Webhook: カスタムリソースが作成・更新される際、APIサーバーはこれを外部のWebhookサービスに送信し、サービス側で複雑な検証ロジック（例：複数のフィールド間の論理的な整合性チェック）を実行させる。検証が失敗した場合、APIサーバーはリソースの永続化を拒否する。
  2. Mutating Webhook: リソースがetcdに書き込まれる前に、フィールドのデフォルト値の補完や、特定の設定値の上書きなど、データを変更（変異）させるために使用される。

CRDはこれらのKubernetesの拡張メカニズムと組み合わされることで、ユーザー独自の高度な運用自動化プラットフォームをKubernetes上に構築することを可能にする、中心的な技術基盤となっている。

由来・語源

CRDはCustom Resource Definitionの頭文字を取った略称であり、「独自リソース定義」と訳される。この機能がKubernetesに導入された背景には、標準リソース（Pod、Deployment、Serviceなど）だけではカバーできない、ユーザー固有の複雑な運用要件やアプリケーションの設定を、Kubernetesの管理フレームワークに統合したいという強いニーズがあった。

Kubernetesの初期バージョンでは、この目的のためにThirdPartyResource (TPR) という仕組みが存在したが、これはスキーマのサポートが不十分であり、APIサーバーとの統合度も低かったため、拡張性と安定性に課題があった。これらの問題を解決し、より堅牢で標準的なAPIサーバーの機能（例えば、バージョン管理やバリデーション）を独自リソースにも適用可能とするために、Kubernetesバージョン1.7以降でCRDが導入され、現在ではKubernetesを拡張する際のデファクトスタンダードとなっている。CRDによって定義されるカスタムリソースは、Kubernetesの制御平面における第一級オブジェクトとして扱われるのである。

使用例

(記述募集中)

関連用語

  • (なし)
TOP / 検索 Amazonで探す