カスタムリソース定義

このセクションでは、カスタムリソース定義オブジェクトの作成と使用方法について説明します。

カスタムリソース定義（CRD）を扱う場合、2つの異なる要素を区別することが重要です。

• CRDの宣言。これはkindがCustomResourceDefinitionであるYAMLファイルです。
• CRDを 使用する リソース。例えばCRDがfoo.example.com/v1を定義するとします。apiVersion: example.com/v1と kindFooを持つすべてのリソースは、そのCRDを使用するリソースです。

リソースを使用する前にCRDをインストールする

HelmはKubernetesにできるだけ多くのリソースを高速にデプロイできるように最適化されています。Kubernetesは設計上、マニフェストのセット全体を取得し、それらをすべてオンラインにすることができます（これは reconciliation loop と呼ばれます）。

しかしCRDは違います。

CRDを使用する場合は、そのCRDを使用するリソースを利用する前にCRDをインストールしておく必要があります。そして、CRDの登録には数秒かかる場合があります。

方法1：helmに任せる

Helm 3の登場により、元々使われていたcrd-installフックは削除され、よりシンプルな方法が採用されました。チャートにCRDを保存しておくためのcrdsという特別なディレクトリができました。これらのCRDはテンプレート化されていませんが、チャートのhelm installを実行するとデフォルトでインストールされます。CRDがすでに存在する場合、警告とともにスキップされます。CRDのインストール手順をスキップしたい場合は、--skip-crdsフラグを渡すことができます。

注意事項（および説明）

現時点では、Helmを使用してCRDをアップグレードまたは削除することはサポートされていません。これは、意図しないデータ損失の危険性があるため、コミュニティで多くの議論が行われた結果の決定です。さらにCRDとそのライフサイクルの処理方法については、まだコミュニティ内でどうすべきか決まっていません。今後、Helmはこれらのユースケースのサポートを追加する予定です。

helm installおよびhelm upgradeの--dry-runフラグはCRDではサポートされていません。ドライランの目的は、チャートの出力をサーバーに送信した場合に実際に機能することを検証することです。しかし、CRDはサーバーの動作を変更するものです。HelmはドライランでCRDをインストールできないため、ディスカバリークライアントはそのカスタムリソース（CR）について認識できず、検証は失敗します。代わりに、CRDを独自のチャートに移行するか、helm templateを使用できます。

CRDのサポートに関する議論で考慮すべきもう1つの重要な点は、テンプレートのレンダリング方法です。Helm 2で使用されていたcrd-installメソッドの明確な欠点の1つは、利用できるAPIが変化するため（CRDは実際にKubernetesクラスターに使用可能な新たなAPIを追加しています）チャートを適切に検証できないことでした。チャートがCRDをインストールした場合、helmは有効なAPIバージョンのセットを操作できなくなります。これはCRDのテンプレート化のサポートを削除した理由でもあります。CRDをインストールする新しい方法crdsにより、helmがクラスターの現在の状態の適切な情報を持っていることを保証できるようになりました。

方法2：チャートを分離する

もう1つの方法は、CRDをチャートに配置し、そのCRDを使用するリソースを 別の チャートに配置することです。

この方法では各チャートを個別にインストールする必要があります。しかし、このワークフローはクラスターの管理者アクセス権を持つクラスター管理者にとってより役立つ場合があります。