Kubernetes Upstream Training に参加してきました!
Kubernetes Upstream Traing
どうもrenjikariです。 めちゃ久しぶりに記事書きます。
2020/9/7(月)にCNDT(Cloud Native Days Tokyo 2020)のサブイベント?としてオンラインで開催されていた、 Kubernetes Upstream Traingに参加してきました。してきました、という書き方ですがonlineです。
メインは技術的トピックというよりもKuberentesコミュニティについての話とそこにcontributeする際のやり方や心構えという話でしたが、非常に面白く有意義でしたので共有します。
資料はこちらで公開されていて読めるので、資料だけでは伝わりづらそうなところをまとめていきます。
いつの間にが内容が馬鹿長くなってたので、以降ここだけ読めばいいってとこだけ太字にしておきます。それだけなら5分もかからず読めますたぶん。
はじめに
- kubeconではこういうeventを前からやっているとのこと
- kubeconで前回(2019.11)にやったやつを日本語バージョンでやってくれる(優しい、感謝しかない)
- k8sのupstreamにcontributeできる人を増やす
kubernetes コミュニティについて
このセッションの感想
sessionのまとめ
- contributeについて
- Kubernetesコミュニティは誰でもcontribute可能
- K8sに貢献する理由は様々だが、仕事の中で、仕事に沿った形で貢献すればよい
- 自身でどこに貢献できるかをさぐる冒険をしてほしい
- コミュニティについて
- コミュニティのあり方
- 集中よりも分散
- プロセス全体の自動化
- プロダクトや会社を超えたコミュニティ
- 排他的よりも包括的
- 進化は停滞よりもよい
- "文化が戦略を喰らう"
- コミュニティの構成
- SIGs(Special Interest Groups)
- メインのグループ
- そのほかはSIGsをサポートする役割
- SIGsの中でsubprojectsが別れていて、subprojectがK8sの特定の場所のコードオーナーになっている
- WGs(Working Groups)
- あらかじめ期日がきめられているグループ
- 特定の期間活動する
- コードオーナーはもってない
- UGs(User Groups)
- end userが特定の機能を推進する場所
- コードオーナーはもってない
- Committees
- code of conductやsecurityや機密的なセンシティブ内容をあつかう
- steering commeetie(K8sコミュニティの偉い人)とかから選出される
- SIGs(Special Interest Groups)
- コミュニティのあり方
- コミュニティの細かい話
- SIGs
- K8sは2000以上のcontributersがいて、巨大なので階層化されている
- ざっくり説明すると、SIGsは"charter"と呼ばれる約定のようなものを持っていて(なんと訳せばいいかわからなかった)それの中で、SIGsのガバメントや、コードのオーナーシップ、subproject、working groupについての情報を定義しています。
- SIGもさらに複数のタイプ(がありますが結パット見でむずかったので、例とともに書いておきます)
- Vertical: Network, Storage, Node, Scheduling
- Horizontal: Scalability, Architecture
- Project: Testing, Release, Docs, PM, Contributor Experience
- project SIGsにおもろいのが一個あったので紹介します
- sig-contribx(上で言うContributor Experienceになります)
- contributerの健康とか貢献しやすさみたいなところをみるらしい
- sig-contribx(上で言うContributor Experienceになります)
- SIGにどう入るか
- https://github.com/kubernetes/community/blob/master/sig-list.md
- ここにSIGだけでなくWGについてもcontact先が書いてある
- ここのmeetingsに勝手に入って、聞いていてもいいらしい(めちゃ開かれてる…)
- コミュニケーションについて
- これはSIGsだけじゃなくて全部同じようなものだと想像されますが、以下のようなものでコミュニケーションされています。
- mailing list
- slack
- google groups
- 相互のリスペクトが健全なコラボレーションに必要だと信じられている
- これはSIGsだけじゃなくて全部同じようなものだと想像されますが、以下のようなものでコミュニケーションされています。
開発について
- githubのレポジトリについて
- 当然ですが、K8sのgithub organizationの中には複数のrepositoryがあり、K8s本体のものだけでなくいろいろなものがあります。わかりやすそうなやつを列挙してみます
- kubernetes/kubernetes
- kubernetes/community
- kubernetes/website
- 当然ですが、K8sのgithub organizationの中には複数のrepositoryがあり、K8s本体のものだけでなくいろいろなものがあります。わかりやすそうなやつを列挙してみます
- 開発環境について
- localでbuildするなら結構リッチなものが必要
- ビルドするの結構重い
- CPU8コア/ memory32GBでも15分かかるとのこと
- すくなくとも6GBのメモリを専有する
- 開発のサイクル
- repositoryにより様々ではあるが、大体は以下
- 3month(12weeks)で1イテレーション
- 仕様決定 => 開発(~Weeks 8) => code freeze(Weeks 9~11) => Post-Release(Weeks 11+)
- code freezeはバグを修正したり、機能についてのdocumentがちゃんと整備されているか(少なくとも誰が責任をもってdocを書くか)を精査する時間
- testについて
- 以下にどういう流れでPR上のtestを実行すべきかの話がかいてある
- test自体は細かく何をするとは書いてないが、以下のようなことをするとセッション中で言及されていた
コントリビューション実践(心構え的な話)
OSSで貢献する心構えの話
何がコントリビューションなのか
- なんでもコントリビューションになりえる
- コードを書くのだけでなく、docを書いたり翻訳したり、自分のほしい機能やバグについてissuesを書くだけでも貢献になる
- また、今回CNDTにて開いていただいたこういう新contributor育成もコミュニティ貢献の一つ(そういう意味ではこのブログも遠回しな貢献になると願って:pray:)
- First PR Ideas
- いろんなlabelsがissueに貼ってある
- good first issue とhelp wantedがついているものはおすすめ
- reviewalbe codeにすること
- reviewerのやることを簡単にしてあげる
- 特にcommit massageは重要
- contributeのプロセス
- 時間がかかることを認識する
- quality vs speed
ハンズオン
- 最後にKubernetesにPRを出す練習をハンズオンでやりました
- 今回はkubernets-sigs/contributor-playgroundというrepsitory
- Kubernetes communityのrepositoryにPRを出すには事前準備として、以下が必要になります
- 実際のPR
- https://github.com/kubernetes-sigs/contributor-playground/pull/540
- testが走って、code ownerに書かれたapproverにapproveされるとmergeまで進んだ
まとめ
こういったcontributor育成の機会を開いていただいてすごくためになりました。開催してくれた方たちに大変感謝してます。
冒頭でも触れましたが、たくさんあるSIGsやWGsについて紹介していただいて(あとこれを書くために自分で調べて)なんとなく全体感がつかめた気がします。