要約

  • implementable は、関係 SIG の approver が KEP の実装を認めた状態である。特定のコード、リリース、クラスター設定、支援契約を認めた状態ではない。
  • マイルストーン、Production Readiness Review、試験、feature gate、番号付きリリース、運用者の採用は、異なる主体が担う別々の記録である。
  • 提案から運用までの短い証跡を残せば、設計判断を存在しない運用保証へ変換せずに済む。

KEP の状態は設計上の権限範囲を示す

Kubernetes Enhancement Proposal は、単なる要望票ではない。公開された KEP プロセスは、重要な変更について動機、設計、責任、安定性の目標、複数リリースにまたがる進捗を追えるようにする仕組みとして説明している。影響を受ける SIG から選ばれた approver が、KEP を implementable に移す時点を決める。状態には provisional、implemented、deferred、rejected、withdrawn、replaced もある。 KEP プロセス

したがって implementable は実体のある判断だ。設計を実装に進めることを、該当 SIG の範囲で認める。しかし、それだけでは特定のコミットが取り込まれたことも、特定のリリースに入ったことも、運用中のクラスターでどの gate が true かも分からない。まして、ある運用者が顧客に対してサポートを負うことを決めた記録にはならない。

SIG が見るのは設計、API、依存関係といった技術的判断だ。運用者が見るのは容量、ノードとコントロールプレーンの組合せ、アドオン、監視、version skew、顧客契約、復旧の可否である。両者を同じ「承認」と呼ぶと、後者の費用を負う主体が記録から外れる。これは SIG の判断を弱めるのではなく、正確な大きさに保つ。

リリース候補には別の証拠が要る

KEP テンプレートは、コードを対象リリースへ入れるには KEP を参照する enhancement issue が Enhancement Freeze より前にマイルストーンを指していなければならないとしている。signoff checklist には implementable の承認だけでなく、設計詳細、試験計画、graduation criteria、完了・承認された Production Readiness Review、実装履歴、利用者向け文書、補足資料が並ぶ。しかも、この checklist はマイルストーンで検討されるたびに更新・再確認する反復的なものとされる。 KEP テンプレート

これは、設計を作れる状態と、今回のリリースで採るに足る証拠を分けるための仕組みだ。設計は十分でも試験や文書がその周期に追いつかないことがある。逆に issue にマイルストーンが付いていても、後続の審査が終わったとは限らない。対象化、収録、公開を同一視すると、途中で誰が何を再確認したかを失う。

PRR はさらに別の役割を置く。Kubernetes は、SIG lead とは別のチームが observability、scalability、supportability、安全な運用、無効化と rollback を検討するものとして PRR を説明する。Kubernetes 1.21 以降、enhancement がリリースの一部となるには PRR 承認が必要だという。 Production Readiness Review

この審査は上流のリリース収録に対する強い境界だが、すべての配布形態や全クラスターへの保証ではない。特定の CNI、CSI、admission 設定、ネットワーク、容量、契約上の支援範囲まで PRR が決めるわけではない。

feature gate は各コンポーネントと各運用者の選択に残る

Kubernetes の feature-gate リファレンスは、gate を各コンポーネントの --feature-gates で設定する key=value の対として定義する。コンポーネントは自分の機能に関係する gate だけを扱い、参照表は Alpha、Beta、stable、導入・削除バージョンを区別する。 Kubernetes Feature Gates

これは選択肢の文書であって、選択の証明ではない。ある gate がバージョンに掲載されても、特定のクラスターが有効にしたとは分からない。複数コンポーネントの協調が必要な場合もある。配布元が独自の制約を設けることも、運用者が計測、容量、version skew、rollback の確認まで無効のままにすることもある。上流がレバーを提供することと、運用者がレバーを引くことは違う。

KEP の graduation 例もこの段階差を保っている。Alpha は feature flag の背後の実装と初期 e2e 試験、Beta は機能・security・monitoring・testing の要求と既知の欠落の解消、GA は実運用の利用、フィードバック、Beta で得た問題の解決を扱う。非任意機能の GA には conformance tests が求められる。 KEP テンプレート これはプロジェクト内部の成熟度であり、個々の運用者の支援方針ではない。

番号付きリリースも運用責任を代行しない

Kubernetes のリリース頁は release branch、x.y.z のバージョン、パッチ、EOL を別の公開記録として示す。これは KEP の状態より強い証拠であり、公開制品とプロジェクトの支援期間を確認できる。 Kubernetes releases しかし、その期間はプロジェクトの期間である。特定の配布元が機能を梱包したか、ある管理サービスが障害を受け持つか、あるクラスターに安全に適合するかを言うものではない。

enhancements リポジトリは KEP、issue、サイクルを追う有用な地図だが、採用証明ではない。 Kubernetes enhancements KEP をリリースへ、リリースを設定へ、設定をサポートへと短絡させるたびに、次の事実を確認できる唯一の主体が消える。

必要なのは新しい承認組織ではない。KEP と不変リビジョン + 所有・影響 SIG + approver と状態 + milestone と freeze + PRR の申請・結論 + コード・試験リビジョン + gate、コンポーネント、既定値 + 番号付きリリース + 配布境界 + 運用者の有効化・サポート・rollback・version skew の明示 を結ぶ、小さな提案から運用までの証跡でよい。各主張を、その主張をした主体に戻すための記録である。

この姿勢は、参加や専門性と、存在しない包括的な委任を区別する Heng Lu の議論とも整合する。運用上の権限は、実際に運用結果を引き受ける側に残るべきである。 The Multi-Stakeholder Mirage Running-Code Primacy

この記録からは言えないこと

これらの資料は、特定の KEP の状態、特定コードの収録、特定 gate の有効化、配布版の互換性、運用者の支援約束を証明しない。特定の企業、クラスター、利用者、事故を評価していない。ここで示す証跡は Daniel Kade の編集上の提案であり、Kubernetes の要件ではない。

出典