カスタムリソース定義：バージョン管理とリリース戦略

はじめに

Kubernetesにおいてカスタムリソース定義（CRD）は、拡張性を実現するための基盤技術として重要です。CRDのバージョン管理とリリース戦略は、APIの変更を安全に実施し、ユーザーに破壊的変更を防ぐために不可欠です。本記事では、CRDにおけるバージョン制御の種類、変更管理のベストプラクティス、実験的APIの設計戦略、およびGateway APIにおける改善策を詳細に解説します。

バージョン制御とリリースの基本

カスタムリソース定義の種類

• 実裝特化型CRD：コントローラーと緊密に結合され、バージョン管理が単純です。例：Link、Conourプロジェクト。
• 上流CRD：コミュニティ開発の規範で、バージョン管理が複雑です。例：Gateway API、Network Policy。

バージョンの種類

1. APIバージョン：v1alpha1など、APIの主なバージョンを區別します。
2. スキーマバージョン：リソース構造を定義し、APIバージョンとは獨立して変更可能です。変更は逆転可能（ラウンドトリップ）を確保する必要があります。
3. ストレージバージョン：etcdに保存されるバージョンで、安全な変換を実施してデータ喪失を防ぎます。

ラウンドトリップの重要性

• 逆転可能な変更：リソースが異なるバージョン間で正しく変換される必要があります。例えば、デフォルト値を持つフィールド（widthのデフォルト値10）は逆転可能です。しかし、ユーザーが手動で非デフォルト値（width=11）を設定した場合、変換時にデータが失われる可能性があります。
• ストレージバージョンの変換：異なるバージョン間でのデータ変換を安全に実施し、データ喪失を防ぐ必要があります。

特徴フラグの活用

• 実裝特化型CRD：コントローラー內に內蔵し、フィールドの利用可否を直接制御します。
• 上流CRD：規範で実験的フィールドをマーキングし、チャンネル管理で変更を制御します。例：Gateway APIの標準チャンネルと実験チャンネル。
  • 標準チャンネル：安定したリソースとフィールドのみを含みます。
  • 実験チャンネル：すべてのフィールドを含み、ユーザーがチャンネルを選択することで機能を有効化します。
  • 利點：ユーザーはリソースを変更せずに機能を有効化できます。
  • リスク：実験チャンネルから標準チャンネルへの移行で機能が失われる可能性があります。

バージョン変更のリスクと対策

1. 実験的フィールドの標準化：
   • 利點：安定した機能でテスト済み。
   • リスク：既存機能の破壊を防ぐ必要があります。
2. 実験的リソースの追加：
   • リスク：後続の変更が必要なため、慎重な設計が求められます。
3. 標準リソースへの実験的フィールド追加：
   • リスク：dead fields問題によりデータが失われる可能性があります。実験的フィールドを明確にマークする必要があります。

Gateway APIの改善策

• 実験リソースの処理：
  • xcrd APIグループを使用し、X前綴名（例：XGateway）で命名します。
  • 影響：実裝者は新しいモジュールを再導入し、ユーザーは手動でリソース変換を実施する必要があります。
  • 利點：標準リソースと実験リソースが同一クラスターで共存可能で、安全に実験リソースを削除できます。

バージョン管理の課題と提案

• 実裝特化型CRD：上流CRDの複雑なバージョン管理メカニズムを避ける必要があります。
• 上流CRD：実験的機能と標準機能を明確に區別し、チャンネル管理で変更を制御する必要があります。
• ストレージバージョンの変換：データ逆転可能を確保し、データ喪失を防ぐ必要があります。
• 変更戦略：安定した機能の向上を優先し、新規リソースやフィールドの追加には慎重な設計が必要です。

バージョンロールアウトとAPI変更

1. バージョンロールアウトの課題：
   • APIバージョンのロールアウトには大量の変更が必要で、ユーザーと実裝者に影響を與えます。
   • Webhookの強制実行は追加インフラ（Webhookサービスのデプロイ、CVE対応など）が必要です。
2. コアとエコシステムの違い：
   • KubernetesコアAPIのバージョンロールアウトは比較的容易ですが、非コアAPI（例：Gateway API）では実裝者の負擔とユーザー體験のバランスを取る必要があります。

実験的APIの設計考慮

1. 実験的APIの不確実性：
   • 実験チャンネルは不確実で、変換できない破壊的変更を含む可能性があります。
   • ユーザーはこのリスクを明確に理解し、生産環境での誤使用を防ぐ必要があります。
2. エコシステム統合の問題：
   • ツール（例：Argo CD、Kubernetes Manager）が実験的APIまたは標準APIのみをサポートする場合、互換性問題が発生します。
   • 標準APIと実験APIを分離することで摩擦を減らす必要があります。

技術的トレードオフとコミュニティフィードバック

1. 実裝者の負擔と設計権威：
   • 実験的APIのテストに実裝者がリソースを投入する必要があります。
   • 実裝者が関與しない場合、設計決定がニーズを無視する可能性があります。
2. 多バージョンCRDのストレージ問題：
   • 現在の解決策は持続不可能で、長期的な解決策が求められます。
   • コミュニティが代替案（例：多バージョンストレージ）を提案する可能性がありますが、実裝コストと実現可能性を評価する必要があります。

結論

Gateway APIはバージョン管理と実験的APIの管理戦略を通じて、実裝者の負擔とユーザー體験のバランスを取っています。検証アドミッションポリシーとツールサポートを通じてリスクを低減しています。今後はバージョンロールアウトメカニズムとエコシステム統合の最適化が求められ、安定性と拡張性を確保する必要があります。