MeetupやKubeConの発表でよくKEP(けっぷ)というワードがでてきます。
まずはこのKEPとは何ぞやの話をして、次にどう利用しているかについて紹介したいと思います。
KEPとは?
このKEPというのはKubernetes Enhancement Proposalの略のことです。その名の通りKubernetesに対する新機能の提案で、新機能を提案した時の可否/Alpha/Beta/GAまでのフローも細かく定義されています。また、このKEPはkubernetes/enhancementsリポジトリで管理されています。
コミュニティからKEPを検索するためのページも提供されています。
https://www.kubernetes.dev/resources/keps/
導入のモチベーション
KEPは変更や進捗を明確にして品質を保ち、以前は統一されていなかったalpha/beta/GAの条件を明確にするために導入されました。
現在のKubernetesコミュニティは、30のSIG1、10のWG2、2つのUG3によって構成されています。
(Kubernetes本体のコントリビュータ数だけでも2,369人!)
以前は、新機能については各グループのメーリングリストやビデオ会議、F2Fで話し合われていました。しかし、ここまでプロジェクトが大規模になるとSIGのPMやリリースマネージャが全体像を把握できないという問題が出てきます。
そんなこともあり、1つのPRやIssueを見ただけで概要を把握できて、かつ優先順位付けもできるKEPが導入されました。
より詳しい話はKEP-1を読んでみてください。これはKEP自体をKEPとして定義ものです。
どんな時に便利か?
私もKubernetesを把握するのによくKEPを見ています。(最近はChangeLogとかIssueの参照先としてリンクが貼られることが多くなってきたので見ざるをえない感じですが…)
特に次のようなときに便利です。
- 新機能の動向を知るためにkubernetes/enhancementsのIssueをwatch
- ある機能の、導入に至ったモチベーションを知る
- ある機能のGAまでのスケジュールを把握する
- コード読んでて分かりにくいところのコミットからKEPを辿る
進行中のものについてはIssueがCloseされていないので、Issueを見ると把握できます。すでに入っている機能についてはkepsディレクトリを見るとよいでしょう。またKEP導入以前の話であったり全体のアーキテクチャについては、kubernetes/community - contributors/design-propsalsを参照してください。
ちなみに最近気になっているKEPはSidecar Containersです。v1.17にalphaリリースを目指していましたが現在はv1.18にリスケされました。なので早くて2020年の3月、デフォルトで有効になるのは2020年の初夏頃でしょう。これが入るとメインアプリケーションとは別にSidecarがマークできるので、KnativeでどのコンテナにProxyするかみたいな問題が進捗することを期待しています。
Footnotes
1 Special Interest Groups(SIG)は、特定の分野(ex. API/Storage/Network)の特化した開発を進めるためのグループです。SIGの中でさらに複数のサブプロジェクトに分かれていることもあります。
2 Working Groups(WG)は、SIGをまたいだトピックを議論するための一時的なグループです。
3 User Groups(UG)は、BitDataなどKubernetesユーザに関連する長期的に情報交換が必要なトピックのためのグループです。(Kubernetesの特定のコードを担当しているわけではありません。)