カスタムリソース定義
ベストプラクティスガイドのこのセクションでは、カスタムリソース定義オブジェクトの作成と使用方法について説明します。
カスタムリソース定義（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 の kind を持つリソースを使用する前に、まず CRD の宣言を登録する必要があります。この登録処理には数秒かかることがあります。
方法1: helm に任せる
Helm 3 の登場により、古い crd-install フックは削除され、よりシンプルな方法が採用されました。chart 内に crds という特別なディレクトリを作成し、CRD を配置できます。これらの CRD はテンプレート化されませんが、helm install を実行するとデフォルトでインストールされます。CRD がすでに存在する場合は、警告とともにスキップされます。CRD のインストール手順をスキップしたい場合は、--skip-crds フラグを指定してください。
注意事項（および説明）
現時点では、Helm を使用して CRD をアップグレードまたは削除することはサポートされていません。これは、意図しないデータ損失の危険性があるため、コミュニティで多くの議論が行われた結果、明示的に決定されたものです。さらに、CRD とそのライフサイクルの処理方法については、コミュニティ内でコンセンサスが得られていません。この状況が進展すれば、Helm はこれらのユースケースのサポートを追加する予定です。
helm install および helm upgrade の --dry-run フラグは、CRD ではサポートされていません。ドライランの目的は、chart の出力をサーバーに送信した場合に実際に機能するかを検証することです。しかし、CRD はサーバーの動作を変更するものです。Helm はドライランで CRD をインストールできないため、ディスカバリークライアントはそのカスタムリソース（CR）を認識できず、検証は失敗します。代わりに、CRD を別の chart に分離するか、helm template を使用してください。
CRD サポートに関する議論で考慮すべきもう1つの重要な点は、テンプレートのレンダリング処理です。Helm 2 で使用されていた crd-install メソッドの明確な欠点の1つは、API の利用可能性が変化するため chart を適切に検証できないことでした（CRD は実際に Kubernetes クラスターに新しい API を追加します）。chart が CRD をインストールすると、helm は有効な API バージョンのセットを把握できなくなります。これが CRD のテンプレート化サポートを削除した理由でもあります。新しい crds メソッドにより、helm がクラスターの現在の状態について完全に有効な情報を持つことが保証されます。
方法2: chart を分離する
もう1つの方法は、CRD 定義を1つの chart に配置し、その CRD を使用するリソースを 別の chart に配置することです。
この方法では、各 chart を個別にインストールする必要があります。しかし、このワークフローはクラスターへの管理者アクセス権を持つクラスターオペレーターにとってはより有用な場合があります。