3-shake, inc.

IDCフロンティアでやってきたこと

IDCフロンティアではRancherを利用したContainer as a Serviceの開発や、IDCフロンティアが提供するIaaSであるIDCFクラウドが提供するロードバランサーやストレージなどをKubernetesクラスターと連携させるための各種Kubernetesのコンポーネントなどの開発を行なったりしました。

その他、Kubernetesやコンテナに関するトレーニングを実施したり、Container as a Serviceに興味を持ってもらったクライアントの方々と技術的な相談を受けさせて頂いたりといったように開発以外にも色々なことにチャレンジさせて頂きました。

また、個人的にも下記のようなことにも取り組み、様々な角度でKubernetesに関わることができました。

• Kubernetesやその関連リポジトリにコントリビュート
• Kubernetesの各種実装解説をブログやセッションで行う
• Kubernetesに関する情報を同人誌や商業誌を通して発信する
• Kubernetes/Cloud Nativeに関するニュース情報の発信をYouTubeで行う
• サイボウズ社necoチームでのTopoLVMなどのKubernetesアプリケーション開発(副業)

IDCフロンティアには4年ほど在籍しましたが、入社する前は登壇して発表したりといったことにも慣れておらず、下記のような発表用のスライドを作るのも一苦労でしたが、ここ数年で色んなチャレンジを行えたので、人前で話したりと言ったこともそれなりに慣れてきました。

スリーシェイクでやること

スリーシェイクはSRE支援ソリューションの提供、セキュリティやETLに関するSaaS、フリーランスエンジニア向けの人材紹介サービスなどを行なっています。

僕の場合は、SRE支援ソリューションの提供を行う事業の中で、Kubernetesに関するソリューションの提供を行ったり、事業に関するOSSへのコントリビューションや情報発信などを行っていく予定です。
そのため前職から引き続きKubernetesやコンテナといった事が主なお仕事になります。

SRE構築総合支援サービスSreake | 株式会社スリーシェイク

SRE支援に関する業務も同時に行っていくと思うのですが、Kubernetes以外のクラウドインフラ構築や運用といった部分について本業で取り組むのは久しぶりなので、ちょっとずつキャッチアップしていきたいなと思っています。

まだ初日なのでわからない事だらけですが、ひとまずブログに自分の情報を載せてもらうところまでは持っていったので、他のお仕事もがんばっていきます！

bells17

基本はリモートワークですが、今日オフィスのある新宿御苑・四谷三丁目の付近を歩いていたらご飯の美味しそうなお店がたくさんあったので、ちょいちょい出社もしようかなと思っています。
近辺にいる方は良ければランチなどに誘ってください〜

🤝 スリーシェイクに興味を持った方 🤝

読んでいて「スリーシェイクにちょっと興味でてきたぞ..!」「どのポジションが良いか相談に乗って」という方がいれば、TwitterのDMなどで連絡ください！
（SRE支援に興味ある方も連絡お待ちしてます）

下記に新しく採用ページがオープンしてたので詳しい事が知りたい方はこちらも見てみてください。

株式会社スリーシェイク採用情報

Software Design 2022年9月号

寄稿した記事は

第2特集
「知りたい」「使いたい」「発信したい」をかなえる
OSSソースコードリーディングのススメ

という特集の中の中の一部で

• 自分なりのコードリーディング方法や使ってるツールの紹介
• Kubernetesを題材にした実際のコードリーディングの流れの具体例の紹介

を自分が執筆した第2章・第3章の2つで行っています。

第3章ではKubernetesのソースコードを題材にして自分なりのコードリーディングの流れや方法を紹介していて

• kubeletのアーキテクチャと実装に関する全体像の調査
• Kubernetesの永続ボリュームに関する機能の1つであるGeneric Ephemeral Volumeの実装調査

という2つを具体例として出しているので、Kubernetesのソースコードに興味のある方にも参考になれば良いなと思っています。

記事を寄稿してみて

今まで技術書典で技術同人誌を2つほど書いたことはあったのですが、Software Designのような商業誌で記事を書かせて頂いたのは初めてだったので、わからないことが多かったですが、学びも多くて面白い経験ができてよかったなと思います。

• 商業誌での初稿や再稿などの執筆~編集者の方のレビューの流れを知れた
• 記事と一緒に作成した図を元に出版社の方でいい感じの図に直してくれるということを知った
  (頂いた見本誌を見たらだいぶわかりやすくなってた)
• 記事を寄稿すると見本誌を献本いただけることがわかった
• 編集者の方にレビューしていただくと直す箇所がめちゃくちゃある
  (ご迷惑おかけしました…)
• 多分初めてページ数(文字数)を意識して記事を書いた

などを今回の執筆を通して学んだり体験できました。

自分の方で書ける記事だと今回のようなコードリーディング以外だと

• Kubernetes関連
• コンテナ技術関連

あたりがメインにはなると思いますが、機会があればまた執筆してみたいなと思っています。

今回執筆したSoftware Design 2022年9月号は自分を含め記事を寄稿したOSSソースコードリーディングの特集以外にもMySQLやRed Hat Enterprise Linux 9に関する特集などがあるようなので、興味がある方は是非買ってみてください！

この記事ではKubernetesのソフトマルチテナンシー管理を容易にするツール「Accurate」の内部実装について解説します。

GitHub - cybozu-go/accurate: Kubernetes controller for multi-tenancy. It propagates resources between namespaces accurately and allows tenant users to create/delete sub-namespaces.

Accurateとは？

Accurateはサイボウズ社のnecoチームが開発しているツールで、主にKubernetesのNamespaceの階層化と、階層化されたNamespace間のリソース伝播機能を提供するKubernetes Operatorになります。

Accurateがどういったツールであるかについての詳細は、以前Kubernetes Meetup Tokyo #47で発表しているので、そちらをご覧ください。

Accurateの全体像

Accurateのドキュメントは以下にあります。

Accurate Documentation

アプリケーションはGoを使って実装されていて内容としては

• Kubernetesに登録するCRD(SubNamespace)
• kubebuilderを利用したOperator(Custom Controller/Webhook)
• Accurateを利用するためのkubectlプラグイン

に区分することができます。

インストール方法としてはhelmが提供されていて、
https://cybozu-go.github.io/accurate/helm.html

kubectlプラグインの方はkrewを使ってインストールすることができます。
https://cybozu-go.github.io/accurate/install-plugin.html

また、Opeator側でwebhookが利用されているので、基本的には事前にcert-managerがインストールされている必要があります。

アプリケーションに関してはOperatorとkubectlプラグインそれぞれがcmdディレクトリ以下にエントリーポイントがありhttps://github.com/cybozu-go/accurate/tree/main/cmd

CRDについてはkubebuilderのデフォルト通りapiディレクトリ以下に定義があります。
https://github.com/cybozu-go/accurate/tree/main/api

CRDの定義だけ知りたいときはドキュメントに記載があるのでそちらを読んだ方が楽です。
https://cybozu-go.github.io/accurate/crd_subnamespace.html

CI/CDに関してはGithub Actionsを利用しており
https://github.com/cybozu-go/accurate/tree/main/.github/workflows
のワークフローを見れば詳細がわかりますが主に

• ユニットテスト
• envtest
• E2Eテスト(3つのKubernetesバージョンでのテスト)
• 自動生成されたコードなどの差分チェック
• helm chartのlinter

あたりがcommit毎にチェックされるようになっています。
(このあたりのテスト密度の高さによる品質担保が本当にすごい)

Operator

前述の通りOperator側は

• Custom Controller
• Webhook

があります。

Operatorは起動時に設定ファイルを引数で渡す必要があり、設定内容に応じて

• 伝播を許可するNamespaceのラベル/アノテーションのキー
• 伝播を行うリソース種別
• 作成を許可するNamespaceの名前制約

といったことが制御できます。
(設定ファイルの例は以下のような内容です)

labelKeys:
- team

annotationKeys:
- metallb.universe.tf/address-pool

subNamespaceLabelKeys:
- app

subNamespaceAnnotationKeys:
- foo.bar/baz

watches:
- group: rbac.authorization.k8s.io
  version: v1
  kind: Role
- group: rbac.authorization.k8s.io
  version: v1
  kind: RoleBinding
- version: v1
  kind: Secret
- version: v1
  kind: ResourceQuota

namingPolicies: []

Accurateは上記の設定内容に応じて

• Namespaceの階層化
• Namespaceのテンプレート化
• 作成する子Namespace名のバリデーション
• 設定に応じたNamespaceへのラベル/アノテーションの伝播
• 設定された種類(e.g. Secret)のリソースを子/テンプレート利用Namespaceへ伝播

を行います。

Custom Controller

Custom Controllerには

• SubNamespaceReconciler
• NamespaceReconciler
• PropagateController

の3種類のコントローラーがあります。

SubNamespaceReconciler

SubNamespaceReconcilerは子Namespaceを作るためのCRD「SubNamespace」リソースのためのReconcilerで、SubNamespaceリソースに応じた子となるNamespaceの作成を担当します。

NamespaceReconciler

NamespaceReconcilerはNamespaceのためのReconcilerで

• 子Namespace
• Templateを利用したNamespace

に対して伝播元となるNamespaceのラベル/アノテーションの伝播を行うためのNamespaceです。

また、Namespaceが子Namespaceでなくなったり、Templateの利用を止めた際に伝播されていたリソースを削除したりといった処理も行います。

PropagateController

PropagateControllerは

• 子Namespace
• Templateを利用したNamespace

に対して、伝播元となるNamespaceで作成された各種リソースから、伝播する設定が行われているリソースの伝播を行います。

コードを読んでいて面白かったのが、伝播してリソースを作成する処理について以下のようになっており、unstructured.Unstructuredインターフェイスを利用することで各種Kubernetesリソースに対する伝播処理を1つのControllerで実装されている点でした。
unstructured.Unstructuredはこんなふうに使うんだなというのが勉強になりました。

func (r *PropagateController) propagateCreate(ctx context.Context, obj *unstructured.Unstructured) error {
 logger := log.FromContext(ctx)
 children, err := r.getChildren(ctx, obj.GetNamespace())
 if err != nil {
  return err
 }

name := obj.GetName()
 for _, child := range children.Items {
  cres := r.res.DeepCopy()
  err := r.Get(ctx, client.ObjectKey{Namespace: child.Name, Name: name}, cres)
  if err == nil {
   continue
  }
  if !apierrors.IsNotFound(err) {
   return fmt.Errorf("failed to look up %s/%s: %w", child.Name, name, err)
  }

if err := r.Create(ctx, cloneResource(obj, child.Name)); err != nil {
   return fmt.Errorf("failed to create %s/%s: %w", child.Name, name, err)
  }

logger.Info("created a child resource", "subnamespace", child.Name)
 }

return nil
}

accurate/propagate.go at v0.3.0 · cybozu-go/accurate

Webhook

Webhookは

• SubNamespace
• Namespace

に対して設定されています。

SubNamespace

SubNamespaceに対するWebhookは

• mutatorによるfinalizerの自動設定
• SubNamespaceリソースの設定値バリデーション
• Nameing Policyに違反してないかのチェック

などを行います。

Namespace

Namespaceに対するWebhookはAccurateに関するNamespaceの操作に問題ないかのバリデーションを行います。

Accurateは”accurate.cybozu.com/”から始まるラベルやアノテーションをNamespaceなどのリソースに埋め込むことにより、Accurateから見たNamespaceやその他伝播するリソースの属性や設定を管理しています。

バリデーション処理ではリソースの作成や変更内容時に上記の設定などに問題が無いかどうかのチェックを行っています。

kubectlプラグイン

Operator側に比べるとkubectlプラグインの実装はかなりシンプルなので、簡単にまとめます。

kubectlプラグインはgit-style プラグイン機構と言われるPATH の通ったディレクトリに配置された実行ファイルの名前がkubectl-で開始しているものを呼び出すというものです。

ですので、kubectlプラグイン自体の実装は通常のCLIツールの実装と同じです。

Accurateの場合はKubernetesの様々なコマンドラインツールで使われているのと同様にcobraが使われています。

GitHub - spf13/cobra: A Commander for modern Go CLI interactions

コマンドのusageは以下のようになっています。

$ kubectl accurate
accurate is a subcommand of kubectl to manage Accurate features.

Usage:
  accurate [command]

Available Commands:
  completion  generate the autocompletion script for the specified shell
  help        Help about any command
  list        List namespace trees hierarchically
  namespace   namespace subcommand
  sub         sub-namespace command
  template    template subcommand

...

completionとhelpを除くとその他は

• list
• namespace
• sub
• template

というサブコマンドの構成となっています。

Namespaceの階層化を行ったり、Template機能を利用する際は

• kubectl accurate sub create
• kubectl accurate template set

といったコマンドを利用していくことになりますが、これらは内部では

• SubNamespaceの作成や削除
• Namespaceへのラベルやアノテーションの設定

といった操作を実行するという処理が行われています。

まとめ

ということで最後に全体のイメージを図にするとこんな感じです。
(サッと作ったので雑な感じです)

ストレングスファインダーの分析は以下から購入して受験することができます。

ストレングス・ファインダー 2.0

僕はここにあるクリフトンストレングス34というやつを購入してみました。
大体6000円くらいでした。

クリフトンストレングス34 | ja-jp - Gallup

きっかけ

受けたきっかけはtopotalの方達が毎週水曜日夜に行なっている「SRE雑談」というTwitter Spaceでお話ししていて、ストレングスファインダーの話がきっかけでした。

菱田健太@トポタル📌 on Twitter: "ストレングスファインダーの話になってます https://t.co/ZTgmG42P86 / Twitter"

ストレングスファインダーの話になってます https://t.co/ZTgmG42P86

話しの中で「ストレングスファインダーの結果が〜」という話が何度か出てきて、僕が全然知らなくて「ストレングスファインダーってなんですか？」って質問をしたところ雑談に参加していた多くの方が受けた事あるよ！って教えてくれたり、ストレングスファインダーがどんなものか教えていただいて興味が出たのでTwitter Spaceで話しをしながら受験してみました。

受診結果

話しながら受けてみたところ、こんな感じの結果でした。

僕の場合は特に

• 活発性
• 個別化
• 親密性
• 着想
• 未来志向

というのが強みとなる資質になってくるようです。

こういった図の他に強みとなる資質がどういったものなのかなどの4種類ほどのpdfで生成されたレポートが受験直後からダウンロードして見れる感じになっていました。

例えば「活発性」の場合は

「いつ始めようか?」これはあなたの人生で繰り返される質問です。あなたは動き出したくてうずうずしています。分析 が有用であるとか、ディベートや討論が貴重な洞察を生み出す場合があることもあなたは認めるかもしれませんが、 心の奥深くでは、行動だけが有意義であると知っています。行動だけが何かを起こすことができるのです。行動だけ が功績につながります。決断が下されると、あなたは行動を起こさずにはいられません。
…

のように「活発性」の資質が強い人はどういう特徴や考え方をするのか？などが書かれている感じでした。

他の強みとなる資質についてもこういった説明が書いてあり、だいたい書いてあることと自分の認識は一致している感じでした。

自分の認識と一致しているのでレポートの精度高いなと思う一方で、(字面上以上の実際の質は置いておいて)だいたい自分の認識とレポートで書かれていることが一致していたので、自分としては「だいたい知ってる、自分で思っている特徴や癖と合ってる」という感じだったので、この結果を見てストレングスファインダーをこれ以上どう活用すればいいのかがよくわからん、という感じになりました。

bells17 / べる on Twitter: "とりあえず分析結果を見て感じたこと・自分の認識してたりやってることと一致してるので分析精度が高そう・分析結果と自己認識+取り組みががだいたい一致してたので自分の認識や内省の精度もそこそこ高いのかも知れない・一致してたのはわかったんだけど、新たな発見はまだ無い ← 今ココ / Twitter"

とりあえず分析結果を見て感じたこと・自分の認識してたりやってることと一致してるので分析精度が高そう・分析結果と自己認識+取り組みががだいたい一致してたので自分の認識や内省の精度もそこそこ高いのかも知れない・一致してたのはわかったんだけど、新たな発見はまだ無い ← 今ココ

ストレングスファインダーについて調べてみる

どう活用していいかわからんという感じになったので、もう少し自分でも調べてみたところ

ストレングスファインダーをもっと活かすには？｜しん / 強みコーチ｜note

の記事が概要としてはストレングスファインダーをどのように活用していけばよいかがわかりやすかったです。

一応『さあ、才能(じぶん)に目覚めよう 新版 ストレングスファインダー2.0』という本も読んだのですが、書籍の3/4ほどがストレングスファインダーの各資質についての説明となっており、ストレングスファインダーの受験結果で手に入るレポートと重複してる箇所が多かったのであまり参考にはならなかった感じがしました。

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

上記に貼ったしんさんという方は、どうやらタイムチケットというCtoCのスキル/タイムシェアサービスで1時間単位でストレングスファインダーのコーチングをしてくださるようだったので、ブログ記事を読んだだけだとなんとなくこうかな〜くらいの認識を補完して、自分の中でどんなふうにストレングスファインダーを利用していけばよいのかをイメージを具体化して落とし込むためにこのコーチングを受けてみることにしました。

🏅公認ストレングスコーチがあなたならではの強み伸ばします✨ | タイムチケット

コーチングを受けてみて

コーチングについては以下のような内容でした

• 事前にストレングスファインダーを受験(これは受験済)
• 受験結果のレポートを元にコーチの方から事前に頂いた質問に解答(主にストレングスファインダーの診断結果の特に強みとなる資質についての納得感や理由など)
• これらの結果を元にした分析結果を事前に共有
• 当日はビデオチャットツールを使用して1時間ほど上記の事前情報を元にして、こちらが話したいテーマをベースにお話し

ビデオチャットによるコーチングに加えて、事前に分析していただいてその結果を共有してもらえることを考えると5000円はかなり安いんじゃないかなという印象です。

コーチングの中身について

コーチングは1時間で達成したい目標を始めに設定して、その目標に沿ったテーマについてお話しするという感じでした。

僕の場合は

• 受診結果と自己認識がだいたい一致してたけど、今後この結果をどう活用していけばよいのか？ということと
• 結果を元に具体的にかかえている課題に対してどのように取り組んだり付き合って行けばよいのか？

ということを目標にしてお話ししました。
(2つ目の方はちょっとふわっとした目標ですが)

これらを目標として、お話ししながら、ストレングスファインダーをどのように活用していくのがいいのか？などについて教えてもらいました。

まず教えてもらったストレングスファインダーの基本となる考え方の僕なりの解釈としてはこのようなものでした。

• 自分の資質として弱みとなる部分を改善したり、弱みとなる資質の特性を活かして何かをするよりは、自分の強みとなる資質の特性を活かしたり伸ばしたりする方が出る成果が後者の方が圧倒的に高くなる
• だから自分の弱み・強みとなる資質の特性を把握して、強みとなる資質の特性を活かして様々な課題に取り組んだ方が良い結果が出る
• そのために分析をして自分の弱み・強みとなる資質を把握する
• 把握した結果を、より自分の強みを活かして取り組む方法を考えたり工夫するためのヒントにする

これに対して、上記のようなことを行なっていくためのステップとしてストレングスファインダーの分析結果を元に

• 自分の強みを把握する
• 強みを伸ばす
• 強みを活かして物事に取り組む
• 強みがどのように物事の裏目に出るのかを把握する
• 自分の弱みを把握する、弱みを強みで補う
• 強みをどのように活かすのかをそれぞれの状況でコントローラできるようにする

といったことステップとして行なっていくようです。
(ここの表現はコーチングの時に頂いた資料を元に自分なりの表現に置き換えてます)

個人の感覚としては、質は置いておいてこのステップの上記3つはすでに日常的に取り組んでいて、下3つはそれぞれ検証したり意識的にできるようにコントロールする訓練をしてる段階かなと理解をしていました。

ただ、個人的にはこの「自分の強みを把握する」という部分が一番大事かなと思っていて、この強み(というか特性だと理解してる)には

• どういう解釈ができるか
• どういう見方ができるか

の幅を広げることで、自分の取れる有用なアクションの幅を広げることができるかなという気がしてました。

今回のコーチングでは、結果としてここの解釈や見方を増やすことのきっかけになってとても良かったかなという気がしています。

例えば僕の上位資質の分析で

着想 x 未来志向 x 戦略性 = ユニークな未来を見つめて、そこへの道筋を描く

活発性 x 目標志向 x 達成欲 = 目標に向かってエネルギッシュ突き進む

などの分析をコーチングの中でしてくれました。

この「ユニークな未来を見つめて、そこへの道筋を描く」という部分をどう解釈するかによって、自分には実際にそういうところがありそうかという自己認識の度合いは変わりそうですが、単体の資質の特徴だけでなく、資質の組み合わせによってこういう方向性の強みや特徴があるのではないか？という分析をすることによって、xのケースではyのようなやり方も自分には合ってるのかもしれない、というような考える材料をいくつか手に入れた気がしました。

ちょっと文章でうまく説明できてる感じがしないですが、こういったことを実際にコーチとお話ししながら考えることで、僕個人としてはストレングスファインダーの分析結果やそれぞれの資質の特性、資質の掛け合わせによって自分により合ってるやり方を探したり、捉え方を模索するツールとして利用できそうだなという感じがあったので、このコーチングを受けてよかったなという感じです。

また、具体的な自分の課題を題材として分析結果をどのように使うのか？という話しをさせていただいたので、ストレングスファインダーをどのように活用していくのか？という観点の具体的な考え方の基礎がだいぶ出来た気がしていて、ストレングスファインダーの結果を使って取り組み方・考え方の幅を広げるための第一段階が出来た気がしています。

今後、ストレングスファインダーの分析結果をベースにして様々な物事に対して試行したり捉え方を変えて見ることで、ストレングスファインダーをベースにして考えたり試行錯誤する回数を増やし、考え方・捉え方・取り組み方の幅を広げていければ良いなと思っています。

出した本はこれで、タイトルは『Kube API Server ~ Kubernetes API Serverの内部実装を見てみよう ~』という割とそのまんまなタイトルです。

技術書典とBoothのそれぞれで販売していて、リンクはこちらになります。

• Kube API Server ~ Kubernetes API Serverの内部実装を見てみよう ~ - bells17 - BOOTH
• Kube API Server ~Kubernetes API Serverの内部実装を見てみよう~：Kubernetes Internal

表紙はこんな感じで、表紙のイラストはSKIMA経由で https://twitter.com/confidential_y/ さんに書いていただきました。

書籍の内容について

書籍の内容についてですが、タイトルのまんまKubernetesのAPI ServerであるKube API Serverの内部実装について

• どのようなアーキテクチャになっているのか？
• どのような機能があり、それはどのように実装されているのか？
• 何をどのように拡張する方法が提供されているのか？

といったことを調べてまとめたものになりますので

• Kubernetesに興味がある方
• Kubernetesのコンポーネントに興味がある方
• Kubernetesの内部実装に興味のある方

は読んでいただけると良いなと思っています！

July Tech Festaでのセッション

実は書籍は昨日(2021/07/18)にリリースしたのですが、昨日はJuly Tech Festaというカンファレンスでもセッションを行いました。

セッション内容は出した書籍と同じくKube API Serverについての話しでした。

内容としては書籍で書いたKube API Serverについての内容の中で概要レベルの話しを中心にしてお話しした感じになりますので、スライドの方を見ていただいて興味ありそうであれば書籍の方も是非買っていただけると！

ちなみに何故か当日までセッション時間が40分だと勘違いしていて(実際は20分だった)、本来のスライドからだいぶ内容を削っているので、削る前の内容をどこかで発表できると良いなと思ってます。

どうしてKube API Serverの本を書いたの？

前回の技術書典10ではKubeletについての本を書きました。

• Kube API Server ~ Kubernetes API Serverの内部実装を見てみよう ~ - bells17 - BOOTH
• Kubeletから読み解くKubernetesのコンテナ管理の裏側：Kubernetes Internal

そのため残りのKubernetesのコアコンポーネントは

• Kube API Server
• Kube Controller Manager
• Cloud Controller Manager
• Kube Scheduler
• kube-proxy

となっていてました。

そのうち

• Cloud Controller Managerはコードレベルの解説こそしていないが、大体の内部実装についてはすでに話している
• Kube Schedulerはチェシャ猫さんなどがすでに内部実装についてそれなりに解説された記事やスライドがある
• kube-proxyも同様にRyuSaさんなどがすでに内部実装についてそれなりに解説された記事やスライドがある

という状態で、情報が薄くて優先度が高かったのがKube API ServerとKube Controller Managerでした。

Kube Controller ManagerはKubernetesの様々なロジックを実行するKubernetes Controllerの塊のコンポーネントで、話が色んな機能に波及しそうだったため、先にKube API Serverの方をまとめようかなと思った感じです。

今回Kube API Serverの本を書くことで、僕自身

• 公式ドキュメントなどにはまとまっていないKube API Serverのアーキテクチャが整理できた
• 調べた内容を図や文章にまとめることで、Kube API Serverのアーキテクチャがどのようになっているのか？を具体的なイメージに落とし込めた
• アーキテクチャを表現する実際の実装には、アーキテクチャ図などには現れない、また違った複雑さがあることが把握できた
• 今度Kube API ServerについてのPull Requestを出そうかなと思った時に、あまり調査に時間をかけること無くどこをどう変えれば実装できるのかがわかる程度には実装を把握できた

というメリットがあったように思います。

こんな感じで本を書く、セッションで発表するといったことをアウトプット目標にすることで、Kube API Serverの実装を把握するといったような個人の時間を使って取り組むには少し重めのタスクも、うまくスケジュールとモチベーションコントロールをして取り組むきっかけになるので、今後も似たようなテーマで本を書いたりしてこうと思っています。

多分だけど次はKube Controller Managerについて本を書くことでまとめて、その後自分の理解のために

• Kube Scheduler
• kube-proxy

などについても調べられたらなと思っています。

どういうモチベーションで本を書いてる？

僕の場合Kubernetesの実装調査系については

• Kubernetesに興味があって実装レベルで色々知りたい
• Pull Request色々送れるようになりたい
• 仕事の関係でKubernetesの実装理解は実務にも役立つ

というのがベースにあって、それを本に書いたりセッションとかで登壇してるのは

• パブリックに公開する気でやったほうがクオリティが高いアウトプットになる
• xxのイベントで本を出す/セッションをするという期限を設けることで、ここまでに調べてアウトプット出さなきゃというスケジュール管理とモチベーションコントロールがしやすくなる
• がんばって調べたり書いたりしたのでどうせだったら色んな人に見て欲しい

あたりだと思ってます。

本を書くにあたってやったこと

Kube API Serverの実装調査

Kube API Serverの実装調査は↓のzennのスクラップに全部メモを取っていった感じです。

Kube API Server

ここでメモを取ったものをベースにして、全体のアーキテクチャに関わるものや、個々の機能や実装を把握するための情報をGoogle Drawingで図を書いていって、スライドにまとめていった感じになります。

本当はメモレベルのものを別の何かにまとめ直して整理してからスライドにして行きたかったのだけど、今回はJuly Tech Festaでのセッションも時間がなかったこともありいきなり図を書いてスライドにまとめていったという流れでした。

それでスライドにまとめていったものを更に色々深堀りしていって書籍の原稿に落としていった感じです。

ただ今回本当に時間がなかったのもあって、書籍の方は文章全体を見直したり、他にも気になる項目を追加したりといったアップデートは前回と同じくやっていけたら良いなとは思ってます。

なので前回も募集させてもらったけども、本書も内容をレビューしていただける方がいると嬉しいなという感じなので、どなたか興味ある方入ればTwitterなどで連絡いただきたいです！

執筆の準備

執筆を行うにあたって表紙は先に用意しようと思ってSKIMA経由でイラストレーターさんに表紙のイラストを依頼していました。

スキマ - スキルのオーダーメイドマーケット - SKIMA

また、依頼を出す際には

https://docs.google.com/presentation/d/e/2PACX-1vSNWzx9cW3ohynxKcRa5lgn8zXllMjq6VqkswQadCQEClHqRb-vxoJZbgZC4MPTls_ZkDrn6JfOen4L/pub

のような形をスライドを作成して依頼を出してました。

元々技術書典11は4月頃の開催と聞いていたので、前回の技術書典直後くらいにイラストを依頼していたのだけど、ちゃんと描いて頂いたイラストを使って本を出せてよかったです。

執筆環境は前回に引き続き

GitHub - TechBooster/ReVIEW-Template: TechBoosterで利用しているRe:VIEWのテンプレート（B5/A5/電子書籍）を公開しています

を使わせて頂いて、gitpodを使ってブラウザ経由で執筆してました。

Gitpod: Always ready-to-code.

前回使ってたときと違ってgitpodでpdfを表示できなくなっていたので、書いてビルドするたびにpdfをダウンロードして確認してたのがちょっと面倒でした。

TeXとかの記法については正直あまり理解できてないまま使ってるけど、前回書いた時に使ってた記法を元に最低限の書き方は理解してたので、表示崩れがあったこと以外はそこまでは困らなかったという記憶です。

本当はこれをGithub Codespaceとかに移植できると手元のVSCodeから執筆できて便利そうなんだけど、調べたりする時間があまりなかったのでスキップという感じです。

ここらへんは今度時間あったら調べたい。

イベントページはこちら

July Tech Festa 2021 winter (2021/01/24 10:00〜)

運営スタッフってどんなことやったの？

僕の場合12月から運営スタッフとして参加したのですが

• 毎週の定例MTGに参加
• 応募していただいたCFPをチェック
• イベント開催のための各種準備作業
• 担当の登壇者の方への連絡
• イベント当日は1つのトラックの司会(2人体制でセッションもあったので僕は登壇者の方への質問のみ担当)

という感じのことをやってました

やっていて良かったこと/大変だったこと

良かったこと

運営スタッフとして参加してみて良かったこととしては

• 規模が大きめのカンファレンスの運営がどんな感じになっているのか体験できた(1Day 5セッション×7トラック)
• OBSなどの配信ツールをどんなふうに組み合わせたりしてるのか知ることができた(OBSのスタジオ機能初めて使った)
• CFPを見たりするのがどんな感じでやってるのかを知ることができた
• 運営として1日中イベントに参加してたので、久々にオフラインイベントのライブ感に近いものを感じることができて楽しかった

といったことになります

大変だったこと

逆に大変だったことはこんな感じです

• MTGが毎週あったので、そこは少し大変だった(特にイベント開催1ヶ月ちょっと前くらいから参加したので特に)
• イベント当日の集合が朝早かったのでめっちゃ寝不足だった(前日深夜まで発表用の資料直してたのも原因)
• 司会(質問など)が割とぶっつけ本番に近かったので(一応一人練習はした)かなり緊張した & いくつか凡ミスした(でも質問そのものはは結構いい感じできたかなという印象)
• 司会があるのでask the speakerに参加できない & 担当セッション以外を同時視聴する余力はない

最近だとこういうオンラインカンファレンスだとDiscordやZoomを使ってask the speakerに参加して登壇者の方と雑談してることも多かったのだけど、それができないのは少し残念だったかな

発表はどんなことやったの？

自分自身のセッションではKubeletの話をしました
(ちなみにカンファレンステーマの”推しテク総選挙”というコンセプトは完全スルーした内容になってますw)

スライドはこちらです

ちなみに発表練習してるときは60分話さなきゃいけないのに50分未満で終わってしまったりしてたんだけど、当日緊張していたせいかほぼピッタリ60分使い切ることができました

あと60分のセッションって発表練習するのがめっちゃ疲れるし時間かかる

ここ最近はKubelet関連の情報発信ばかりしていて、自分でやっている Kubernetes Internal #4ではKubeletが起動するまでのコードリーディングをテーマにお話してました

また、クリスマスから年末年始にかけてやっていた技術書典10ではKubeletの技術同人誌を書きました

Kubeletから読み解くKubernetesのコンテナ管理の裏側：Kubernetes Internal

ちなみにイベントが終わったのでBoothでも出しました
https://bells17.booth.pm/items/2649601

この本は技術書典10のイベント中も何度かアップデートしたのですが、最近もう少し追記したり修正したりする内容があったのであんまり期限を空けないようにしてアップデートしたい気持ち

内容的に

• JFT Winter 2021: スライドのみでKubeletの概要について解説
• Kubernetes Internal #4: Kubeletのコードベースの解説
• 技術本: Kubeletの実装的な話し込みで文章と図のみで説明

なので、Kubeletに興味ある方は↑の順番でみてもらうのがわかりやすいんじゃないかなぁ〜と思ってます

Kubernetes関連について

Kubernetes関連のアウトプットについてはようやく一番大変と思われるKubelet周りの実装把握と情報のアウトプットができたという感じ

これまでに

• Cloud Controller Manager
• CSI

については調べてアウトプットしてるので、Kubernetesの主だったコンポーネントについての調査はだいぶ進んできた気がしている

ので直近では

• Kubeletと関連するコンテナランタイムとCRI周り
• コンテナランタイムが扱うLinuxコンテナ周り
• KubernetesやCNIが設定しているネットワーク周りの設定
• あとは未調査のKubernetes ComponentのAPI Serverあたり

にあたりついて調べたりアウトプットしていきたいなという感じがしています

以下サムネ用画像

今年に入ってから(正確には去年の秋頃から)個人的にKubernetesに関する取り組みみたいのを結構増やしていたり、その関連でブログやセッションをしたりといった活動も増えたので、2020年にKubernetes関連で取り組んだことについてまとめようと思います。

Kubernetesやその関連の実装に関する調査

業務でKubernetesに関するコンポーネントを書いていることもあり、Kubernetesの様々な実装について把握したくなったので、今年はそこらへんの調査に結構時間を使ってました。

Kubernetesのコードリーディング情報まとめ

Kubernetesのコードリーディングの方法というか、読む上でここらへんを抑えておくとスムーズに読めると個人的に思うことをこの記事でまとめました。

Kubernetesのコードリーディングをする上で知っておくと良さそうなこと

ブログやセッションの中で今の所この記事が一番バズったみたいなので、 Kubernetesの内部実装にはみんな興味あるのかなと思いました。

ちなみにこの記事について需要ありそうだったこともあって、秋頃から始めた「Kubernetes Internal」という勉強会の第一回目で記事で書いてたことについての解説をさせていただきました。

Container Storage Interface(CSI)

Container Storage Interface(CSI)については去年から調べてたものではあるけれど10月のKubernetes Meetup Noviceで改めてCSIについてセッションをする機会をいただいたきました。

Cloud Controller Manager(CCM)

Cloud Controller Manager(CCM)については今年はじめ辺りから

• KubernetesのServiceControllerの実装
• KubernetesのCloud Controller Managerについて

あたりで部分的にまとめてたけど、9月のCloud Native Days 2020でまとまった内容を発表することができました。

個人的にはこれくらいまとまってれば十分かなという感じでまとめられた気がしてるので良かったかなという感じです。

概要としては上記で十分だとは思うのですが、コードベースでの解説も「Kubernetes Internal」の第２回目で行いました。

Prow

Kubernetesそのものでは無いのですが、Kubernetesコミュニティが作成・使用しているProwというCIツールについても調べる機会があったので、調べた内容をセッションなどで発表を行いました。

July Tech Festa 2020で Prowについてお話しました

ProwはKubernetesのCRDを使ってアプリケーションを構築しているので、KubernetesのOperator実装の1例として勉強になるのではないかという気がしています。

また、KubernetesやCloud Native関連プロダクトにコントリビュートする際にこのProwが利用されているケースが多いので、Prowの動作について知りたい人にも見て頂けたらと思っています。

kubeadm

kubeadmについても調べる機会があったので、調べた内容についてセッションで発表しました。

ちょうど発表した翌日にKubernetes Meetup Tokyoでherietさんがkubeadmについて発表されていて、実はこのセッションの少し前にkubeadmの本を出版されてたことを知ったのを覚えてます。

その他の発表など

Kubernetesのログデータ加工

KubernetesがコンテナのログデータにどうやってPodなどについてのメタデータを付与しているのかが気になったので調べました。

fluentdのプラグインの中で別スレッドのAPI Server監視を動かしていて、結構むちゃしてデータを取ってくるなぁという印象だった記憶があります。

Kubernetes入門者向けのセッション

Kubernetesをこれから始める方向けに、僕がKubernetesを触り始めたときの事例みたいなものを紹介させていただきました。

また、CNBFという運営に関わらせて頂いている勉強会でも入門者向けのセッションを行いました。

その他の活動

Kubernetes公式ドキュメント翻訳

Kubernetes公式ドキュメント翻訳や、そのレビューをしていたので日本語翻訳プロジェクトのレビュワーにしていただきました。
今年の後半は忙しかったこともあり、取り組みが減っていたので、来年は改めて頑張りたい感じです。

勉強会の主催

記事の始めの方にも少し出た「Kubernetes Internal」というKubernetesやCloud Native関連プロダクトをコードベース中心に共有する勉強会というのを10月から開始して、これまでに3回開催しました。
(月に1回勉強会をやってる感じです)

これはYouTubeに過去のセッションがありますので興味ある方がいれば見ていただければと思います。
今月実施した第3回目はチェシャ猫さんにScheduling Frameworkについてお話しいただきました。

Kubernetes Internal

情報発信

また、勉強会とは別にKubernetseやCloud Nativeに関する情報で今週自分たちが気になったことについて雑談をする配信を、Kubernetes Meetup Noviceの運営メンバーのryさん、chagoさんのお2人と始めました。

こちらは始めたのが1ヶ月ほど前のことですが、毎週金曜日10時ごろから1時間ほど行っているのでもう4回配信を行いました。

YouTubeチャンネルは「Kubernetse Internal」のチャンネルでそのまま配信しているので、こちらも興味ある方いれば上記のリンクより動画や配信を見ていただければ嬉しいです。

技術同人誌

最後に技術同人誌です。

ちょうど今週26日からオープンする「技術書典10」というイベントでKubernetesのコンポーネントの1つであるKubeletについての本を出す予定です。

技術同人誌を書くのが初めてだったのもあり

• 表紙をイラストレーターさんに依頼したり
• Re:Viewの使い方を覚えたり

でわからないことが多く、かなり苦労しましたがなんとか仕上げることができたので、良ければ買っていただけるとありがたいです。

正直調べるのにそんなに時間かからないだろうと思ってたのですが、他のどのKubernetesコンポーネントよりも実装が複雑かつ巨大で、数十以上のgoroutineとチャネルによって動作するイベント駆動型の実装になっていたためめちゃくちゃ調べるのに時間がかかりました。

そのためちゃんとまとめきれてるか不安はあるのですが、電子版のみを出すこともあり、出した後にアップデートして行ければ良いかなと思っています。

まとめ

今年のKubernetes活動をまとめたら思ったよりも長文になってしまいました。

思い返すとだいたい1月に1–2回以上はブログを書くなりセッションをするなどをしていた気がします。
これまでほとんどブログを書いたりセッションで発表をしてこなかったので、1年でだいぶ変わったなという気がしてます。
(自分で勉強会や配信も行うようになりましたし)

Kubernetesについてはコアの部分は結構把握できてきたなーという感じがあるので来年はKubernetes本体だけではなくコンテナランタイムやCNI、その他Cloud Nativeアプリケーションなどについても手を出して行ければ良いなと思います。

Kubernetes Internal #1 (2020/10/13 19:00〜)

この記事では自分で勉強会を主催するにあたって

• どんな勉強会をやったのか？
• 勉強会を開催するにあたってどんなことやったのか？
• 実際にやってみてどうだったのか？

といったことを書いています。

どんな勉強会をやったの？

主にKubernetesに関する設計や実装をコードレベルで共有する勉強会になります。

第一回目ではコードを直接読んでいく要素は少なめだったのですが、導入編として以前このブログで書いた「Kubernetesのコードリーディングをする上で知っておくと良さそうなこと」という記事

Kubernetesのコードリーディングをする上で知っておくと良さそうなこと

の内容を解説するという題材で、Kubernetesのコードリーディングをどうやって始めていけばいいか？というお話を僕の方からさせていただき、その後内容についての質疑応答やディスカッションを運営メンバーやzoomで参加してくださった参加者の方々と行いました。

YouTube Liveのアーカイブはこちらになります。

上記でKubernetesのコードリーディングに関する基本的な情報は共有できたかなと考えてますので、今後はよりコードを中心にKubernetesのコンポーネントなどの実装について共有する会をやっていけたらと考えていて、直近ではCloud Controller ManagerやScheduler周りについてお話をしていきたいと考えています。
(本当は第一回目でCloud Controller Managerについても一緒に話をする予定だったのですが、まったく時間内に収まらなさそうだったので別の会にさせていただきました)

なんでこの勉強会をやろうと思ったの？

僕の周りでKubernetesなどの内部について調べている人が少なかったので、Kubernetesの内部実装などについて共有しあえる人を増やしたかったのと、Kubernetesの仕組みについて興味を持ってくれる人が増えると良いなと思って勉強会を開催しました。

僕は普段業務でKubernetesのコンポーネントを書いたりしている都合上、Kubernetesの内部実装を調べたりすることがよくあるのですが、そういった情報を共有してディスカッションする機会が少ないので、興味がある人達で集まって色んなテーマについてディスカッションできたらいいなと思っていたのが根本的な動機です。

前々からこのような勉強会をやりたいなと思っていたのですが、Cloud Native Days Tokyo 2020の時(だった気がする)に@fujiihdaさんの

どなたか「Container Security Meetup (名前はただの思い付き)」を一緒に立ち上げたくない？？立ち上げない？？

というツイートを見つけて

そういえばKubernetesの内部実装について共有する勉強会とかやりたいな

という感じで始めたのがきっかけになります。

それでこのツイートとか、一緒に運営やってくれるのに興味ある人いませんか？みたいなツイートとかで興味持っていただいた方と一緒にやりはじめたという感じです。

最終的に現在はこのメンバーで勉強会を運営していっています。

勉強会をやるまでにやったこと

勉強会をやるまでには大まかにこんなことをやりました

• 勉強会の企画案を作る
• Discordのサーバーを立てる
• 運営メンバーで顔合わせ会を行う
• zoom/YouTube Liveでの勉強会開催~配信の環境を整える
• リハーサルをする

勉強会の企画案を作る

一番はじめに勉強会の企画をドキュメントにまとめるようにしました。

僕の勉強会のイメージが以前genbokuさんが開催された「Programming Kubernetesの輪読会」のKubernetesなどの内部実装版というイメージだったので、その方向で内容をまとめました。

「Programming Kubernetesの輪読会」の輪読会では

Programming Kubernetesの輪読会 二回目 第四章 Using Custom Resources - HackMD

のように

• 章ごとに担当者が内容をまとめてきて発表を行い
• その発表内容について質疑応答・ディスカッションを行う

という内容でしたので、これをオンラインでやるようなイメージで案を作った感じです。

実際に作った企画案がだいたいこんな感じのやつです。
(実際の企画案をだいたいそのまま出してるのでリンクで見れないのも多いです)

https://docs.google.com/document/d/1AsLD1iHItqvq47qm_o2LAJoHqgnqYLeUd9rKTEtNdtk/edit

オンラインでやるにあたっての違いとしては

• 質疑応答・ディスカッションに参加してくれている参加者にはzoomで参加してもらう
• zoom参加者以外にも興味ある人に見てほしい/アーカイブとして見直したいのでYouTube Liveでの同時配信も行いたい

といったあたりでした。

また作成した企画案の内容について運営メンバーに見ていただいて、 Google Docsのコメント機能を中心に内容についてディスカッションを行いました

Discordのサーバーを立てる

• 勉強会の主なコミュニティをDiscordのチャットで行う
• 内部実装に関するやり取りをできる場が欲しい

と思っていたため勉強会をやるにあたってDiscordのサーバーを立てました。

なんでk8sのSlack Workspaceを使わずに新たにDiscordサーバーを立てたのかというと

• k8sのSlack Workspaceでチャンネルを作成するのはコミュニティに申請して許可を取る必要があるので難しそう(既存のjpチャンネルのどこかでやるのもやっていいのかわからなかった)
• Cloud Native Days TokyoなどDiscordでサーバー立てる例を最近いくつか見ていて、特にボイスチャットでのAsk the speakerとかが結構良かった
• どうせなら自由にチャンネルとかを作成できる場を作ろう
• 運営メンバー間でのやりとりの場としても使えるし

といった理由で作成しました。

作成するにあたってちょっと前に技術書典のDiscordサーバーを見て良さそうだなーと思ったのでチャンネルとかの作りを参考にさせていただきました。

運営メンバーで顔合わせ会を行う

企画案の内容についてはここまででだいたいまとまっていたので

• お互い知らない人もいると思ったので、勉強会開催前に運営メンバーで一度顔合わせをしておきたい
• 勉強会について口頭で認識合わせをしておきたい
• 勉強会の詳細について詰めたい

などを目的に顔合わせをする会を行いました。

実施にあたっては簡単にスライドを作り、以下のようなことについて話し合いを行いました。

実際に口頭で話し合ってみると、当たり前ではありますが個々人でイメージしている勉強会の像が異なっていたりしたし、運営メンバー同士でコミュニケーションする機会にもなったので、やってよかったなと思いました。

zoom/YouTube Liveでの勉強会開催~配信の環境を整える

• 勉強会開催: zoom
• ライブ配信: YouTube Live

で行おうと思っていたのでこれらの準備を行いました。

やり方としてはkamenekoさんの

ZoomのProアカウントでYouTube Liveに配信する方法

をだいたいそのまま参考にさせていただきました。

勉強会内容としてはセッション+ディスカッションという構成で、ディスカッションの時間が発表と同じくらい時間をとっているので、OBSで色々画面を作ってやるという感じよりはzoomのProアカウントでのYouTube Live配信そのままでも問題ないかなと思いシンプルにzoom+YouTube Liveという構成で行いました。
(kamenekoさんの記事でOBSの使い方に関する記事もあるので、OBSを使った配信などがやりたくなった場合には別途参考にしたいなと思ってます)

上記の記事で紹介されていること以外で工夫した点としては念の為

• zoomホスト+YouTube Live配信を行うマシンと
• 発表者として発表を行うマシン

を分けたくらいでした。
(リハーサルでは同じマシンで全部やっても大丈夫だったのでzoom Proアカウントだけあれば誰でも簡単に勉強会の配信とかができるなと思いました)

リハーサルをする

最後に念の為リハーサルを行いました。

Discordでリハーサル見てコメントとかくれる人がいるかを運営メンバーのDiscordチャンネルで募集して、参加可能だった方数名に見てもらいました。

第一回目は良くも悪くも

• zoomホスト+配信
• 司会
• 発表者

のすべてを僕がやっていたので、参加していただいたメンバーには実際にどんな感じで勉強会をやろうと思ったのかを伝えることができ、それに対するフィードバックをもらってディスカッションすることができたので、これもやってみてかなりよかったなという感じです。

実際に勉強会をやってみて

はじめは

• 運営メンバー: 9名
• zoom参加者: 5名
• YouTube Live参加者: 20–30名

くらいなんじゃないかなという想定をしていたのですが

と200名以上の方に参加登録していただき、とてもありがたかったです。

勉強会後のアンケートでも

のようにKubernetesのコードリーディングに興味を持っていただいた方が多かったので嬉しいです。

セッション後のディスカッションタイムについても

• 始めは僕のセッション内容に対する質疑応答だけになるかなー？とか
• そもそも参加者から質問全然でなくて運営メンバーがフォローしてくれるかなー

とか思ってたのですが、僕がほとんど喋らなくてもセッションの内容についても、それ以外についてもzoomに参加してくれたKubernetesの有識者の皆さん同士で話がかなり盛り上がってくれて、想定していた40分を超えてディスカッションが続いてくれたのですごい良かったなと思いました。
(時間を10分ぐらい過ぎたあたりで途中でディスカッションを中断してしまったのですが、むしろあのままもうしばらく中断せずに続けても良かったかなと思ってます)

あとzoomやYouTube LiveのURLをメッセージしたりなどの準備についてはもうちょっと早くお送りできればよかったなと思うので次回以降で改善できたらと思ってます。

さいごに

こんな感じで勉強会をやりたいなと思ってからちょうど1ヶ月くらいで200名オーバーの勉強会が開催できたので良かったなと思ってます。

次回以降はよりDeepなネタになっていく予定なので、ディスカッションについてもDeepめな話ができればよいかなと考えています。

内容についてはCloud Controller ManagerやScheduler以外に↓のシートのような内容を検討していたりします。
(これから調べていきたい、みたいなのも入ってます)

ただあくまで上記はまだ検討している段階のものなので、発表するのに興味ある方がいれば
https://forms.gle/6bgs37R3NUkmfBtZ6
のフォームか、もしくはTwitterのDMまでご連絡いただけたらと思っています！

まだ始まったばかりの勉強会なので

• 発表するコンテンツ(必ずしもコードレベルでの共有などでなくても)
• 発表時間

など柔軟に検討できると思います。

• 今はまだKubernetesの実装とかに詳しくないけどこの勉強会で発表するために調べてみるとか
• Kubernetes本体じゃなくて、関係しそうなCloud Nativeなソフトウェアについて

などのお話でも大歓迎です！

kubeadmはkubernetes v1.19にあるkubeadmをベースに書く
(kubeadm的には v1.10?)
https://github.com/kubernetes/kubernetes/tree/release-1.19/cmd/kubeadm/app

kubeadmの実行フロー

• エントリーポイントは cmd/kubeadm/kubeadm.goエントリーポイントは cmd/kubeadm/kubeadm.go
• kubeadmutil.CheckErr()はCLIの単なるエラーハンドリング処理なのでスキップ
• app.Run()でkubeadmを実行 https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/kubeadm.go#L31-L51
• app.Run()ではklogの初期化とpflagでコマンドライン引数などの設定を行い、最終的にcmd.NewKubeadmCommand().Execute()を実行 https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/cmd/cmd.go#L33-L97
• NewKubeadmCommand は他のKubernetesコンポーネントと同じく https://github.com/spf13/cobra が使われている
• kubeadmだとkubeadm initなど様々なサブコマンドが登録されていて、これらのサブコマンドが https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/cmd/cmd.go#L84-L92 で登録されている
• kubeadm initの場合はNewCmdInit(https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/cmd/cmd.go#L86)で登録がされている
• kubeadm initを実行した場合はRunE(https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/cmd/init.go#L140-L154)で登録した関数が実行される

kubeadmのrunner

• kubeadmではapp/cmd/phases/workflowパッケージのRunnerが利用されているよう
• これはkubeadmの各処理フェーズを分割して実行するのと(Preflight, Certsなど)、コマンドラインから特定のフェーズだけを指定して実行するために利用されているっぽい(e.g. kubeadm init phase preflight)
• このrunnnerで実行される処理(preflightなど)はAppendPhaseメソッドでそれぞれ登録されている
• kubeadm initでいうと https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/cmd/init.go#L175-L188 で登録されている
• これらの登録されたフェーズはRunメソッドでまとめて実行される(https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/cmd/init.go#L149-L151)
• ここのフェーズのみを実行するphaseサブコマンドは https://github.com/kubernetes/kubernetes/blob/release-1.19/cmd/kubeadm/app/cmd/phases/workflow/runner.go#L293-L399 で登録されている

まとめ

ここまでがkubeadmの実行にあたっての共通の実装の部分で、各サブコマンド(e.g. init, join)が個々のフェーズでどんな処理を行っているのかについては個々のフェーズで登録されているメソッドを読めば良いということになる