はじめまして、LINEヤフー株式会社でKubernetes as a ServiceのPlatform Engineerを務めている小林と申します。
私は業務で使っているという都合もあり、 kustomize（※）というOSSの開発者もしています。
※ kustomize：kustomizeは、KubernetesのYAMLマニフェストファイルをテンプレート化せずに管理するためのツールです。ベースとなるマニフェストに対して、パッチやオーバーレイといった方法で変更を加えることができます。これにより環境ごとの設定差分を管理し、再利用可能なマニフェストファイル群を作成することが可能となります。
前回 のKubeConにて、OSSへの貢献から Kubernetes Contributor Awards という賞を受賞させて頂きましたので、私のLINEヤフー株式会社でのKubernetesやOSSとの関わり方と受賞するまでの経緯について紹介したいと思います。
また、最後にOSSへの貢献をやってみるにあたって私がこれまでの個人的な経験から得たアドバイスを書いたので、OSSに貢献に興味がある方はぜひ最後までご覧ください。
社内のKubernetes利用状況
LINEヤフー株式会社は社内にいくつものサービスを抱えていまして、それらの実行基盤となるIaaS,KaaSなどの技術を積極的に活用しています。
私は主に Kubernetes as a Service(KaaS) を担当しているのですが、歴史的経緯があり明示的にユーザーがKubernetesとして使えるplatformだけで少なくとも4つのplatformがあります。
私が担当しているのはその中でも旧ヤフー株式会社で稼働していたPlatformです。これはおそらく社内でも最大規模のもので、約1,200のクラスタが稼働しています。
参考資料: https://cloudnativedays.jp/cndt2023/talks/1977
なぜOSSへcontributionを始めたか
私が担当しているKaaSでは、利用者に提供したクラスタにlog転送やメトリクス監視などを行う管理用のコンポーネントがデフォルトで導入されていまして、それらの管理コンポーネントの運用もPlatformチームが行っています。
つまり、Platformチームは1200のクラスタに対してこれらのコンポーネント群のデプロイやアップデートを行う必要があり、そのプロセスにkustomizeを活用しています。これはかなりヘビーな使い方と言えます。大規模な環境で利用していたのでどうしてもほしい機能やバグの修正などを行いたくなり、業務外でPRを送るようになりました。
補足として、kustomize を使用するという意思決定をしたのは（おそらく）私です。しかし、環境が大規模すぎてクラスタに固有の設定を管理するのが難しく、Helmのようなテンプレートエンジンやコードによるyaml生成は、manifestsの適用に関する問題を防ぐのが難しいと考えました。そのため、kustomizeとクラスタ追加時のyaml生成を組み合わせて使用しています。
kustomizeへの貢献を始める
kustomizeへの貢献と言っても、使用している過程でhelpメッセージに削除された機能が表示されることを発見し、それを修正することから始めました。また、便利そうな小さな機能が提案されているのを見つけたので、それを実装するなどの活動も行いました。
ちなみにkustomizeはgolangで実装されているのですが、その当時は1つのgit repo内に複数のmodule packageがあるというmulti moduleの構成でした。これが実はやっかいでgolangは基本的に1つのgit repoに1つのmoduleという構成なので周辺ツールが対応していなくて、実際に私が触っていた時にはkustomizeのリポジトリのrootを直接VSCodeで開くとgoplsがまともに動かなくて開発できた物ではなかったという問題がありました。
そして、ついに耐えられなくなり、その当時golangの新しめの機能だったgo workspaceという複数のmoduleをまとめて扱える設定をkustomizeのリポジトリに入れるPRを、一応proposalという名前を付けて投げました。
メンテナもkustomizeの開発でmulti moduleをうまく扱うための方法を求めていたようでmergeされまして、またこのPRを実装してmergeしたことでkustomizeの開発に参加しないかメンテナに誘われました。
余談ですが上記のgo workspaceのPRですが、修正が非常に大変で、go workspaceというのは簡単に説明すると配下のmoduleの依存関係をversionでの参照から現在のfileの状態への参照に変更させるのですが、リポジトリが巨大であったので同じリポジトリにあるmoduleの古いversionに依存してupdateされていない場所もありました。さらに実装をほぼまるごと変えないとupdateできない箇所があり、かなり大変な作業になりました。またkustomizeのrepoで使っているgolangのversionが古くてworkspaceに対応できずupgradeしましたが、golangの特性上各moduleでgolangのversionを指定しており、これも修正箇所が多くて大変だった記憶が あります。
作業中にこのレベルのdiffがあるPRをOSSに送って大丈夫か、かなり不安になりましたが、機能的には完成したPRを用途ごとに3つに分割したりしてなんとかmergeすることができました。
reviewerになる
reviewerとは、Kubernetesの中でも特定のprojectで積極的な貢献とレビューをしている人がメンテナの推薦を受けて昇格するrole（※）です。memberとの差分としてはGitHub上でレビュー依頼が飛んでいく対象になる位でできることはそんなに増えません。
※ role：KubernetesにおけるContributorの分類にはいくつかあります。https://github.com/kubernetes/community/blob/master/community-membership.md
メンテナに対して、Slackでkustomizeの開発への参加意向を伝えたところ、kustomizeの機能改善に関するissueを進めるよう提案され、それを実装しました。並行してkustomizeに出されているPRをいくつかレビューした所で正式にreviewerに昇進させて頂きました。
またOSSコミュニティで正式な役割を頂いたこともあり、この辺りの時期からは会社から業務時間を週8hまでOSSに使えるサポートを得られるようになりました。
この時期にdeprecatedなfieldを使っていたらbuild時にwarningを出す機能や、バイナリリリースの自動化とフローのリファクタリングなど、projectの健常性に関わるような作業をしていました。
また、kustomizeではこの辺りの時期に training cohort と呼ぶ新規コントリビュータのMentoring Programをしており、どちらかというと新規メンバーへのアドバイスやPRレビューなどのメンティーとしての役割が増えていきましたね。
approverへ
approverとは、reviewerになってからも積極的に活動している人が昇格します。権限としてはupstreamへのmerge権があるのでここから上が一般的に言う committer と呼ばれるpositionです。
ところで、kustomizeの開発では英語が使われているのですが、PRのレビューではissueやPRを送る側とは別の英語スキルが要求されてかなり苦労しました。
レビューなので他人の出したPRについてコメントするわけですが、時にはネガティブなことを書かないといけないので、そういったことをあたりさわりがない英語で書くためにかなり苦労してました。実際には英語の文面を大丈夫かチェックするためにその都度翻訳エンジンに通して表現の問題がなさそうか確認したり、検索エンジンでマイルドな良い替えができないかを毎回調べていました。
コードレビューする中で気を付けているのは、互換性を保つために機能が壊れないように気にしていました。そのためにPRのレビューでは既存の機能を壊さないように、またここで変更した部分が将来の変更で壊されないように十分なテストがあることを求めるようにしていました。
ちなみにkustomizeではapproverに独自の基準があって、”kustomizeの目的を深く理解した上で行動すること” 的な文面を追加で追いているのですが、この辺りのkustomizeの設計に対する議論をしていたので推薦してもらえました。
- https://github.com/kubernetes-sigs/kustomize/issues/5140
- https://github.com/kubernetes-sigs/kustomize/pull/4558
Approverへ昇格して以降、OSSに対する主な役割がPRの作成などよりもコードレビューや設計に対する議論になっていきました。committer、つまりmaster branchへのmerge権を持つということは私が良いとした物はそのままkustomizeとしてリリースされてしまいます。PRをレビューするのにかなりのプレッシャーがありますし、挙げられた機能要望についても本当にprojectの目的に沿っているのかを考えて議論しなければならないので、OSSを管理する側の苦労を感じました。
また、この時期にKubernetes projectへの貢献を表彰する Kubernetes Contributor Awards という賞もいただくことができました。kustomizeはKubernetesの開発組織の中でも kubectl などのコマンドラインツールを管理して いる SIG-CLIのprojectなのですが、この賞のを SIG-CLI 部門でいただくことができました。
leadへ
leadとは、特定のSubprojectの意思決定を行う人物でprojectのroadmapや方向性の決定をする、といった感じです。
2024年の2月に、これまでleadの役割をやっていた方がOSSから離れるという事情があり、kustomizeのsubproject leadに昇格しました。
kustomizeの開発方針の最終決定をする立場なので、かなりプレッシャーを感じています。
leadという立場はprojectの方向性だったり、将来すべき点について議論をする立場とだけされています。またたぶん各projectでどういった行動をしているのかは異なるので、この辺りはたぶん project ごとにやり方が違います。
kustomizeでは週次でreviewer以上のメンバーを集めたミーティングをやるのですが、その場で出る議論(たとえばこのissueで提案されている機能を実装するべきかどうか)を結論に導いたり、他のメンバーからの技術的な疑問に対して答えたりしています。
また、より具体的な行動としてはsubcommandの仕様を統一してUXを向上させる計画の提案を出したり、現在の実装上の問題を抱えているが人気が高い機能のサポート段階を上げる決定をしたりしていました。
ただ、方針の変更を含む大きい技術的変更がk8s上の他のprojectに影響してくる場合があるので、その時は別projectにも私が相談を持っていくというような働きをしています。上記の議題の1つは変更点が大きく、kustomizeを同梱しているkubectlという別のツールを管理しているメンバーが出席しているミーティングに持っていって合意を取るなどの運営をしています。
おわりに
私の経緯ですが、これまでのOSSでやってきたこと、昇進する上で苦労したことなどを紹介してきました。これを読んだ方がOSSに貢献する際やコミュニティと関わる際の参考になれば幸いです。
OSSの管理側まで昇格してしまったのですが、Kubernetesのマニフェストに構造化した変更をシンプルに加えるという思想が気に入っていますし、やはりこのprojectには思い入れやここまでやってきた経験とか知見もあるので、今後もOSSを続けていきたいですね。
最後に: OSSへの貢献に興味がある人へ
もしOSSについて貢献を始めたいという方が居れば、有名なprojectを見るよりはまずはそのprojectの目標や方向性と自分のやりたい方向が一致するprojectを探してみるのが、モチベーションも保ちやすいので良いと思います。
貢献を始める場合は good first issue が付けられているissueやドキュメントの修正などの、実装に難しい判断が必要ない課題が何かしらあるはずなのでこの辺りから手をつけることをお勧めします。interfaceの変更や既存の挙動を変更しかねないような取り込むか否かの判断の難しい問題だと、実装方法によってはメンテナが受け入れられない物になってしまう場合があるのでprojectの作法に慣れてからの方が良いと思います。
もしお気に入りのOSS projectが見つかって、またもしそんなprojectに継続的に貢献し続けたいと考えているなら、そのprojectが解決したい課題や目的をよりよく理解してみることをお勧めします。(補足ですがKustomizeはproject固有のapproverへの昇格基準として、Demonstrate deeper understanding of kustomize goals. という文面を持っています。)
projectの目的を理解できたのなら、その目的に進むために課題となっている点が見えてくることがあります。そういった課題を発見や解決していくことができれば開発コミュニティに認められてOSSにより深く関わっていくことができるでしょう。