はじめに
前回の記事を通して、Kubernetesコミュニティにおけるコントリビューションの流れが把握できたのではないかと思います。
今回は「Kubernetesコミュニティ」をテーマに、その構成やその中での役割などについて解説します。加えて、Kubernetesコミュニティに関連する他のCNCFグループやコミュニティについても触れていきます。
前回は「どのようにコントリビューションするか?」をメインに解説しましたが、今回の内容は「どこにコントリビューションしていけば良いのか?」というヒントになる情報を得ることができます。
Kubernetesコミュニティの構成
Kubernetesコミュニティは複数のグループで構成されています。Kubernetesのコミュニティはたいへん大きい(2024年時点で88,000人以上)ので、そのような集まりの中でグループが形成されるというのは自然なことだと思います。
Kubernetesコミュニティにおけるグループには、以下のようなカテゴリーがあります。
- SIG(Special Interest Group)
Kubernetesコミュニティでの基本的なグループカテゴリーです。ターゲットとする観点ごとにSIGが存在します。それぞれのSIGはCharter(憲章)を定義しており、管理プロセスや対象エリアなどが定義されています。また、Subprojectという単位で更に細かい対象エリアやコードベースのオーナーシップが決められています。 - WG(Working Group)
複数のSIGに関わる大きなタスクや機能あるいは要解決な問題があるときに作られます。時限性のグループとなっており、目的が達した場合などに解散されます。 - Committee
セキュリティやCode of Conduct(行動規範)のような慎重な判断が求められる領域を扱います。SIGのようにボランティアで自由に参加するのではなく、メンバーはSteering Committeeから選出されたり、任命されて参加することになります。
それぞれの詳細はSIGリストのページに記述されています。
さて、各グループの一覧を列挙する前に重要なことを伝えたいと思います。それは「ぜひ自分の興味や業務に則した領域のグループに参加してください」ということです。
その理由などの詳細は後述の「活動領域の見つけ方」のセクションに記述しますが、大切なことなので先に伝えさせていただきました。
それでは、グループの一覧を列挙します。ここではそれぞれの詳細を把握する必要はありません。ザザッと確認して、自分が気になるグループが目に留まったならその詳細を確認してみてください。Kubernetesコミュニティには多くのグループが形成されており、SIGのメンバー間やSIG間のコミュニケーションが行われています。
【引用】「Kubernetes Upstream Training」PDF p.39
SIG一覧
2025年11月時点で24個のグループが存在します。
| SIG名 | メイントピック |
|---|---|
| API Machinery | APIサーバー、APIオブジェクトのライフサイクル、REST APIなどのコアの仕組み |
| Apps | DaemonSet、Deployment、StatefulSet、Job、CronJobなど、アプリケーションのデプロイと管理の機能 |
| Architecture | プロジェクト全体のアーキテクチャ、設計原則、APIのレビューと整合性 |
| Auth | 認証(Authentication)と認可(Authorization)のメカニズムやセキュリティポリシー |
| Autoscaling | 水平・垂直ポッドオートスケーラーなど、リソースの自動スケーリング機能 |
| CLI | kubectlコマンドラインツールと、関連CLI機能の開発とメンテナンス |
| Cloud Provider | クラウドプロバイダー固有の機能をKubernetesに統合できるように標準化する |
| Cluster Lifecycle | クラスターのデプロイ、アップグレード、破棄や設定ツールなど |
| Contributor Experience | コミュニティへの参加体験の向上、メンタリング、ツールの提供、コミュニティイベントなど |
| Docs | Kubernetesの公式ドキュメント、ウェブサイト、翻訳の作成とメンテナンス |
| etcd | Kubernetesのコアなキーバリューストアであるetcdの全般について |
| Instrumentation | メトリクス、ロギング、イベント、トレースなど、可観測性(Observability)の機能 |
| K8s Infra | Kubernetesプロジェクトを構築・テスト・デプロイするためのインフラスラトクチャの管理 |
| Multicluster | 複数のKubernetesクラスターにまたがる機能と課題 |
| Network | ネットワークプラグイン(CNI, Container Network Interface)、Service、Ingressなどのクラスタネットワーク機能 |
| Node | Kubelet、コンテナランタイム、リソース管理など、ノードレベルのコンポーネント |
| Release | Kubernetesの新しいバージョンのリリースプロセス全体の管理・調整 |
| Scalability | 大規模なクラスターにおけるスケーラビリティ、パフォーマンス、効率性のテストと改善 |
| Scheduling | Podのノードへの配置を決定するスケジューラーの機能について |
| Security | Kubernetesプロジェクトのセキュリティ監査、脆弱性の報告と対応、セキュリティ文書など |
| Storage | PersistentVolume(PV)、PersistentVolumeClaim(PVC)、Container Storage Interface(CSI)などのストレージ機能 |
| Testing | Kubernetesに対するCI、ワークフロー、テストフレームワークなどの維持と改善 |
| UI | KubernetesダッシュボードやWeb UIなど |
| Windows | WindowsノードとWindowsコンテナ |
WG一覧
複数のSIGにまたがるトピックを議論するグループです。2025/11時点で12個のグループが存在します。
| WG名 | メイントピック |
|---|---|
| AI Conformance | AI/MLワークロードのKubernetes環境での互換性とテスト |
| AI Gateway | Kubernetes環境でのAI/MLワークロードに関してロードバランサーやゲートウェイ、プロキシを検討 |
| AI Integration | KubernetesコアコンポーネントにおけるAI/MLワークロードの統合と、AIアプリケーションをデプロイ、管理、運用するための標準化されたパターンを検討・推進 |
| Batch | バッチ処理ワークロードに関する機能と課題 |
| Checkpoint Restore | Kubernetes へのチェックポイント/リストア機能の統合について |
| Data Protection | データ保護機能の推進と設計 |
| Device Management | デバイスプラグインやノードでのデバイス管理機能 |
| etcd Operator | etcdの運用と管理をKubernetesネイティブに行うためのetcd Operatorの設計と開発 |
| LTS (Long Term Support) | Kubernetesのバージョン提供において、より長期的なサポートと安定性を提供するための戦略や仕組みを検討 |
| Node Lifecycle | ノードの退避(Drain)やシャットダウンなどのメンテナンス時におけるPodのライフサイクルとの連携強化 |
| Serving | Kubernetesでのハードウェアアクセラレーションを用いたAI/MLの推論処理の改善について検討 |
| Structured Logging | Kubernetesコンポーネントのログに対して、解析が容易な構造化された形式への統一と移行 |
Committee一覧
Code of Conduct(行動規範)やセキュリティのようなトピックを扱うカテゴリーです。他のカテゴリーに比べると新規のコントリビューターが関わるタイミングは少ないかも知れません。
2025/11時点で3個のグループが存在しますが、このグループ構成は今後も大きくは変わらないと思われます。
| Committee名 | メイントピック |
|---|---|
| Code of Conduct | コミュニティ行動規範の作成・管理(維持)、インシデントの報告と対応プロセスを管理 |
| Security Response | セキュリティ脆弱性に関する報告の受け先となり、迅速な対応と調整を実施 |
| Steering | プロジェクトの全体的な統治、戦略、財務計画、コンフリクト解決、意思決定 |
活動領域の見つけ方
「Kubernetesコミュニティのどこの領域で活動をすれば良いのか」という点ですが、先述したとおり「自分の興味や業務に則した領域のグループに参加してください」ということになります。以下のポイントから、長期的に活動を継続する上で有利になりやすいためです。
- 継続性が求められ、成果が出るまでに時間がかかる:
OSSコミュニティでの活動は、一定の成果が出る(例えばPRがマージされる)までに時間がかかり普段の業務や研究よりも長引く、あるいは予定通りにいかない場合があります。そのような場合でも興味が深ければ、活動へのモチベーションを保ちやすいと考えます。 - 周囲からの理解と支援が得やすい:
業務で行う場合は業務内容に則した領域の方が同僚や上司など企業内のメンバーに対して事情を説明しやすいと思います。業務時間内での取り組みの理解や、必要なリソース(時間、環境など)の支援が得やすいと言えるでしょう。 - 個人の実績として評価される:
OSSコミュニティでの活動は、人に紐付いた活動として記録が残ります。所属する企業名なども記録として残りますが、誰が行ったコントリビューションなのかという点が評価される側面が強いと思います。結果として、活動の記録は将来的なキャリア形成など、個人の実績として大きな価値を持つことになります。
以上を踏まえて、SIG一覧やWG一覧を眺めて領域を決定してもらえれば良いのですが、コントリビューション入門としてのおすすめがあります。前回でも述べていますが、ドキュメント系(新ページの作成や日本語翻訳など)ですね。バグ修正や機能追加などのコントリビューションに比べると取り組みやすく、コミュニティの作業フローに慣れることにもつながると思います。
グループへの参加方法
各SIGがメーリングリストを持っているので、その購読を行うだけです。それだけでグループへ形式的に参加したことになります。とても始めやすいですよね。こういったところのハードルの低さもOSSコミュニティが大きくなる要素の1つなのかも知れません。
コントリビューターラダー(役割の説明)
グループの中には役割が存在します。参加したあとにコントリビューションを重ね、Kubernetesコミュニティ内で一定の役割となることで、実施できる作業に違いが出てきます。また、同時にコミュニティ内のメンバーから一定の評価を受けることにもなります。
Kubernetesコミュニティでは、コントリビューターラダー(Contributor Ladder)として、はしごを登るようにグレードの高い役割になっていくというスタイルになっています。
【引用】「Kubernetes Upstream Training」PDF p.49
上図の通り、ノンメンバーコントリビューター、メンバー、レビュアー、アプルーバー、オーナーなどの役割が定義されています。前回では、作成したPRに対してレビュアーが内容を確認し、アプルーバーが承認するというフローが説明されていましたが、その役割の人たちのことですね。
グループに参加した直後はノンメンバーコントリビューターということになり、次はメンバーという役割を目指すことになります。メンバーの利点を1つ挙げると、作成したPRに対して自動的にテストが実行されるようになり、効率的なレビューが期待できます(ノンメンバーコントリビューターが作成したPRのテスト実行には、メンバー以上の役割の人から/ok-to-testのラベルを付与してもらう必要があります)。
各役割になるための基準はドキュメント化されているので詳細はそちらを確認してもらう必要がありますが、上位の役割では定量的な活動はもちろんのこと、コミュニティ上での振る舞いもより多く判断されるようになっていきます。
コミュニティで役割が上がっていくことは自身のスキル向上にも繋がりますが、同時にコミュニティがあなたを認知してコミュニティから信頼を獲得したということでもあります。影響力を得ることであなたがコミュニティで実現したいことの効率化が見込めますし、コミュニティとしてもあなたの振る舞いに期待していると言えるでしょう。
その他の関連コミュニティ
最後に、Kubernetesコミュニティに関連するCNCFのその他のグループ・コミュニティを紹介します。
CNCF Technical Advisory Groups (TAGs)
https://contribute.cncf.io/community/tags/KubernetesだけでなくCNCFの全般に渡り、より広範なクラウドネイティブコミュニティのトピックを監督・調整するためのグループです。品質の維持やクラウドネイティブコンピューティングを身近なものにするというCNCFのミッションを推進しながら、技術的な取り組みをスケールさせる役割を果たします。
TAGsのミッションは、エンドユーザーとコントリビューターのニーズを満たすために、以下のような活動を通してエコシステムを強化していくことと記述されています。
- 技術的な専門知識を提供する
- CNCFのプロジェクト全体を見て、カバーできていない課題を明らかにする
- ユーザーに対して公平で実用的な情報を提供する
- エコシステム全体のプロジェクトの成熟を促進する
- プロジェクト間の橋渡し役となり共通の問題を表面化させる
なお、TAGsは2025年05月に再編されており、構成や名称が変わっています。旧グループと新グループとのマッピングはTAGsのページの「Historical Context」から把握できます。
CNCF End User Community
https://www.cncf.io/enduser/CNCFのエンドユーザーコミュニティは、クラウドネイティブ技術を実際に内部で利用している企業や組織を「エンドユーザー」として定義し、そのメンバーで構成されるコミュニティです。内部利用が要件のため、ディストリビューター・商用製品の販売企業・トレーニングの提供企業・コンサル・Slerなどの企業は参加できません。
このコミュニティは、CNCFの活動やクラウドネイティブエコシステムの進化において、ユーザー側の視点とフィードバックを提供するという非常に重要な役割を担っています。
参加することで、以下のような価値が提供されます。
- クラウドネイティブのエコシステムを把握し、適切なツールやテクノロジーの採用サポートを受けることができる
- クラウドネイティブ技術の最適なユースケースを特定し、実装計画の策定と導入サポートを受けることができる
- CNCFがホストするプロジェクトやエコシステム全体に対して、実際に技術を使用している立場からの課題や要望をCNCFへフィードバックし、技術開発の方向性に影響を与えることができる
- クラウドネイティブ技術に精通したエンジニアリング人材の採用や、社内チームのスキル向上の支援を受けることができる
これら以外にも、例えばCNCFがホストする各OSSごとのコミュニティも存在します。一般的にKubernetesは他のOSSと一緒に使うことになるので、自然と他のOSSコミュニティに参加することも多いかと思います。
まとめ
今回は、Kubernetesコミュニティの構造やグループについて解説しました。Kubernetesコミュニティは巨大なので、今回の内容はコントリビューションを開始する際の参考になるのはもちろんのこと、KubernetesのIssueや今後の機能追加などの情報を収集する際にも役立ちます。
また、関連コミュニティについても紹介しました。OSSコミュニティでの活動は、最初のコミュニティから徐々に参加コミュニティが増えていくことが一般的だと思います。ぜひ色々なコミュニティをのぞいてみてください。
OSSコミュニティでの継続的な活動は、あなたに大きなメリットをもたらします。
- スキルアップ:領域の広さと深さが増し、経験と実績になります
- 信頼の獲得:コミュニティに継続的な貢献者として認知されます
- 役割の拡大:新しい関わり方や、より重要な役割へとステップアップできます
ぜひ、自分が決めた領域で活動を続けて行ってください。次回は「Kubernetes開発環境」と題して、Kubernetesの概要やリポジトリ構成、開発環境構築方法などを取り上げる予定です。
- この記事のキーワード