はじめに
Kubernetesは2014年にリリースされ、Cloud Native Computing Foundation（CNCF）の graduate プロジェクトとして現在まで成長しました。プロジェクト規模の拡大に伴い、設計提案プロセスの體系化が求められ、KEP（Kubernetes Enhancement Proposal）やCubeの提案プロセスが進化してきました。本記事では、KEPの構造やCubeのプロセス改善、実裝における課題と今後の方向性について解説します。
Kubernetesの設計提案プロセス（KEP）
背景と起源
Kubernetesは初期の段階でSlackやメール、GitHub Issuesを通じて議論が行われていましたが、プロジェクトの規模拡大に伴い、透明性と協業効率を高めるためのシステム化が求められました。KEPは、提案の品質を確保し、コミュニティの協力を促進するためのフレームワークとして確立されました。
KEPの構造
KEPテンプレート
- 提案の內容と段階（Alpha/Beta/Stable）を明確にします。
- 動機、設計詳細、テスト計畫、リスク評価などの項目を含みます。
メタデータファイル（YAML）
- 參加者（Driver、Approver、Contributor、Informed）を記録します。
- DCモデル（Driver-Approver-Contributor-Informed）でプロジェクト管理視點を提供します。
PRレビュープロセス
- 獨立チームによる生産性レビューを行い、現行システムへの影響を評価します。
- レビュー結果はGitHubに保存され、ステータス（Approver、PR Approverなど）が明記されます。
発行サイクルとの統合
- 発行サイクル：15〜16週間ごとに、議論、設計、実裝、テストの段階を區切ります。
- Enhancement Freeze：提案範囲を固定し、関連ファイルの変更を禁止します。
- Code & Test Freeze：実裝PRの審査とマージを期限內に完了させます。
- 例外処理：未達成の提案は再評価を経て延長が可能ですが、厳格な條件があります。
課題と改善
- ドキュメント負擔：一部の貢獻者が更新を怠り、情報が古くなることがあります。
- プロセスの柔軟性：SIG（Special Interest Group）はニーズに応じて門戸を調整し、初期は小規模な範囲から開始することを推奨します。
- ツール統合：YAMLメタデータは外部ツール（看板、ダッシュボードなど）との連攜を可能にします。
- 継続的な進化：プロセスはプロジェクトの成長に合わせて調整され、コミュニティのコミュニケーションと責任分擔が重視されます。
Cubeの設計提案プロセスの進化
初期段階
2016年に設立され、初期はPRと簡潔なドキュメントで機能を実裝していました（例：仮想マシンの移行）。貢獻者は3〜5人程度で、迅速なイテレーションが行われていましたが、構造化されたプロセスは存在しませんでした。
プロセスの確立と初期の課題
- PRテンプレート：機能目標と非目標を記載するよう求められましたが、実際には一貫性がありませんでした。
- コミュニティリポジトリ：設計ディレクトリを設け、提案テンプレート（目標、非目標など3〜5のセクション）を保管しました。
- 混亂狀態：提案と他の議論が混在し、追跡メカニズムが欠如していたため、透明性が不足していました。
改善と現在の狀況
- 設計ディレクトリ：提案とその他の內容を分離し、可読性を向上させました。
- 追跡メカニズム：Gitログで貢獻者と機能狀態を追跡しましたが、議論履歴は記録されていません。
- 機能閾値の不明確さ：提案範囲が明確でなかったため、一部の機能（仮想マシンの優先順位など）が記録されていません。
- 閾値の未定義：機能のデフォルトスイッチや削除タイミングが明確でなかったため、長期的なメンテナビリティに影響を與えました。
今後の方向性
- プロセスの標準化：KubernetesのKEP構造を參考に、より完全な提案テンプレートを構築します。
- コミュニティ參加の強化：設計ミーティングやコミュニティ協力の強化により、提案の透明性と一貫性を向上させます。
- ツール統合：GitHubの機能（タグ、プロジェクトボードなど）を活用して、提案の進捗と狀態を追跡します。
設計提案プロセスの拡張と最適化
既存プロセスの課題
- テンプレートの簡略化：初期は目標と非目標の記載のみで、プロセスルールが明確ではありませんでした。
- 追跡メカニズムの欠如：提案と他の議題（人材配置、権限調整など）が混在し、明確なプロセス管理が欠如していたため、提案の狀態が不明瞭でした。
- 透明性の不足：提案評価や進捗の追跡が明確でなかったため、誰がどの機能を推進しているかが把握できませんでした。
- 個人関係依存：機能進捗が個人の関係に依存し、包容性や新規貢獻者の參加が妨げられました。
- 機能管理の混亂：例として、Hot Plug機能が調整不足により、ストレージ層とコンピュート層の実裝が不一致になっていた。
新プロセスの設計
- Kubernetesの拡張プロセスを參考に：KEPの構造を採用し、テンプレートを簡略化（元の半分程度）します。
- 専用リポジトリ：
cubert-enhancementsリポジトリを設置し、提案を集中管理するプラットフォームとして活用します。
- GitHub Issueテンプレート：
- 機能目標：提案の目的と非目的を明確にします。
- 連絡先指定：主な連絡者（Primary Contact）とCubert側の責任者（Maintainer）を指定します。
- 成熟度ステータス：機能の現在段階（草案、Alpha、Betaなど）を記載します。
- SIGルーティングメカニズム：
- 提案は自動的に関連SIG（例：ネットワーク、ストレージ）にルーティングされます。
- SIGは機能の所有者（Owner）を指定し、実現可能性を評価します。
- プロセス段階：
- 初期評価：コアMaintainerによる初期レビュー（2〜3人）。
- 所有権移管：評価通過後、機能の所有権をSIGに移管します。
- ライフサイクル管理：SIGが機能の開発と統合を主導します。
発行サイクルとの統合
- Kubernetesと同期：Kubernetesの発行サイクルに合わせ、季節ごとに3回のリリース（元は4回で、安定テストのため2か月遅延）。
- 機能統合閾値：
- リリース前には統合テストを完了し、ブロックするバグを修正する必要があります。
- 特に重要な機能は90%完了度を條件にリリースを延期申請可能（議論の結果で調整）。
- ロールバックとテスト：
- コミュニティメンバーが機能を下流ブランチにロールバック可能。
- 夜間ビルド（Nightly Builds）を提供してテストを支援。
今後の提案
- 段階的なプロセス拡張：
- まずGitHub Issueのシンプルなフレームワークから始めて、貢獻者を引きつける。
- 次第にプロセスの複雑さを増やし、過度なルールを導入しない。
- プロセスと柔軟性のバランス：
- OpenStackの経験を參考に、過度なプロセス化を避ける。
- 時間駆動型のリリースサイクルを主軸とし、重要な機能の調整は偶発的に行う。
- コミュニティ協力：
- SIGを活用して個人関係依存を減らし、包容性を高める。
- 明確なプロセスと追跡メカニズムにより、機能進捗の予測可能性を確保する。
結論
設計提案プロセスの拡張は、プロジェクトの成長に応じて柔軟に調整する必要があります。KEPやCubeのプロセス改善は、コミュニティの協力と透明性の確保を通じて、信頼性と効率性を高めています。今後の課題として、ドキュメントの更新やツールの統合が重要であり、継続的な改善が求められます。