カスタムリソース定義

このベストプラクティスガイドのセクションでは、カスタムリソース定義オブジェクトの作成と使用について説明します。

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

• CRDの宣言があります。これは、種類がCustomResourceDefinitionのYAMLファイルです。
• 次に、CRDを使用するリソースがあります。たとえば、CRDがfoo.example.com/v1を定義するとします。apiVersion: example.com/v1と種類Fooを持つリソースは、CRDを使用するリソースです。

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

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

ただし、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ではサポートされていません。「Dry Run」の目的は、チャートの出力がサーバーに送信された場合に実際に機能することを検証することです。ただし、CRDはサーバーの動作の変更です。HelmはドライランでCRDをインストールできないため、ディスカバリークライアントはそのカスタムリソース（CR）について認識せず、検証が失敗します。代わりに、CRDを独自のチャートに移動するか、helm templateを使用することができます。

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

方法2：別々のチャート

別の方法として、CRD定義を1つのチャートに入れ、そのCRDを使用するリソースを別のチャートに入れることができます。

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