Kubernetes Internal #9 Minikube

Minikube 概要 2

Minikube とは？ https://minikube.sigs.k8s.io/docs/ ● ローカル上で Kubernetes を動かせる OSS. Windows/Mac/Linux などの OS に対応しています 3

Minikube 機能概要 ● ローカル Kubernetes ● Multi drivers, Multi CRI ● Multi Nodes ● Service, Type: LoadBalancer ● Addons ○ Ingress ○ Dashboard ○ Istio ○ CSI driver, volume snapshots ○ etc... 4

Minikube 機能概要 ● ローカル Kubernetes ● Multi drivers, Multi CRI ● Multi Nodes ● Service, Type: LoadBalancer ● Addons ○ Ingress ○ Dashboard ○ Istio ○ CSI driver, volume snapshots ○ etc... 本日のポイント 5

ローカル上で Kubernetes を動かす仕組み ● Minikube は driver と呼ばれるものを使って、VM または コンテナ を起動します ● 立ち上げた VM または コンテナを Node として利 用し、その Node 上に kubeadm を使って Kubernetes を構築します Local VM or Container 6 Kubernetes クラスタ

Minikube - Cross Platform & drivers ● Minikube は OS ごとに対応した、さまざまな drivers を持っています 7 KubeCon EU2020 - Minikube - Rohit Anand, NEC Corporation＆Medya Ghazizadeh, Google より引用

Minikube の位置づけ 8

kubernetes/kubernetes ● Kubernetes は 2014 年に登場し、2021 年現在は巨大な OSS プロジェクトのひと つとなっています。Kubernetes 本体だけでなく、関連プロジェクトも同時に成長し ています。 ● GitHub のリポジトリとして、大きく次のふたつのリポジトリがあります。 ○ https://github.com/kubernetes ○ https://github.com/kubernetes-sigs ● Kubernetes Org には多くのリポジトリがあり、Kubernetes 本体は kubernetes/kubernetes（a.k.a k/k）にあります。 ● Minikube は Kubernetes プロジェクトの一つ ○ kubernetes/minikube 9

Minikube の良さ ● コードがシンプル ○ kubernetes/kubernetes の巨大なコードベースと比べると、コードがシンプル ○ Minikube は簡単に動かせる（バイナリをダウンロードして、 minikube start） ○ バイナリが一つ！ ※Kuberentes は動かすのに最低でも etcd と api-sever が必要 ○ シングルバイナリなので、テストやデバッグがしやすい ○ GoLand や IntellliJ などでデバッグ可能！ 10

Minikube コード解説 11

CLI のコマンドが cmd, ロジックが pkg に書かれている コードを直すときは、cmd, pkg, test に手を入れることが多い Minikube リポジトリ構造 （一部省略） ├── Makefile ├── README.md ├── cmd ├── deploy ├── go.mod ├── go.sum ├── out ├── pkg ├── site ├── test └── test.sh 12

minikube/deploy には Addons や VM Image や Container Image（KIC base）が配 置されています。 Minikube リポジトリ構造 - Addon/Machine Image 13

Minikube は Cobra ライブラリを使っています。 デバッグしたいコマンド（例: minikube start）から読むべきパッケージを逆算します。コ マンドは cmd, 主要処理は pkg パッケージにあります。 Minikube Code Reading のコツ 14

minikube start をターゲットに実装を追ってみます。コマンドの定義は cmd パッケージ にあり、コマンドごとにファイルが分かれています。 minikube start を追ってみる（1）- cmd 15 https://github.com/kubernetes/minikube/blob/v1.20.0/cmd/minikube/cmd/start.go

minikube start を追ってみる（2）- cmd 16 https://github.com/kubernetes/minikube/blob/v1.20.0/cmd/minikube/cmd/start.go#L93-L143

minikube start を追ってみる（3）- Node Provisioning 17 https://github.com/kubernetes/minikube/blob/v1.20.0/cmd/minikube/cmd/start.go#L188-L205 provisionWithDriver で driver を使って、Node Provisioning を行います。

minikube start を追ってみる（4）- Node Provisioning 18 https://github.com/kubernetes/minikube/blob/v1.20.0/cmd/minikube/cmd/start.go#L328-L341 node.Provision から Node Provisioning を行う Function を呼び出します。

minikube start を追ってみる（5）- Node Provisioning 19 startMachine -> startHost -> machine.StartHost -> machine.createHost を経由します。 https://github.com/kubernetes/minikube/blob/v1.20.0/pkg/minikube/node/start.go#L260-L288

minikube start を追ってみる（6）- kubeadm 20 https://github.com/kubernetes/minikube/blob/v1.20.0/cmd/minikube/cmd/start.go#L263-L271 startWithDriver で minikube driver を使って、kubeadm による Kubernetes の構築を 行おうとします。

minikube start を追ってみる（7）- kubeadm 21 https://github.com/kubernetes/minikube/blob/v1.20.0/cmd/minikube/cmd/start.go#L93-L143 startWithDriver から呼ばれる node.Start（starter, true）で kubeadm を使って、 Kubernetes クラスタの構築を始めます。

minikube start を追ってみる（8）- kubeadm 22 https://github.com/kubernetes/minikube/blob/v1.20.0/cmd/minikube/cmd/start.go#L93-L143

Contribution Flow 23

Kubernetes 関連プロジェクトに貢献するには？ Contribution に必要な大きな流れ 1. CLA（Contributor License Agreement）にサインする a. 個人としてのサイン or 組織の一員としてのサイン 2. Code of Conduct を読み、遵守する 3. Issue を立てる または Issue を探す 4. PR を出す 24

Membership for Kubernetes Community ● Membership には、member/reviewer/approver/subproject owner があります。 ● それ以外は、new contributor か contributor という扱いになります。 ● 最初は new contributor から始まり、一度以上 Kubernetes リポジトリにコミットす ると、contributor になります。 25

リポジトリにもよるが、初心者向けには good first issue/help wanted などのラベルが あります。 3. Issue を立てる または Issue を探す 26

アサインは /assign というボットへのコメ ントで可能 3. Issue への作成・アサイン 作成画面 27

1. おおまかに二通り（実際のフローは後述） 2. バグ修正 a. バグの原因を調べる → 修正したら、Unit Test と Integration Test のふたつのテストなどを動かす 3. 機能追加 a. 難易度としては総じてバグ修正よりは難しいため、はじめて Contribution する場合はバグ修正から 始めることをオススメします ※ 参考: Coding Conventions 4. PR を出す 28

バグの原因が分から なければ、 デバッグが有効 Go の文法エラーや コンパイル エラーも 警告してくれる 個人体験談）IDE によるサポート 29

Unit Test $ make test = make lint ============================================================= ok = go mod ================================================================ ok = boilerplate =========================================================== ok = schema_check ========================================================== ok = go test =============================================================== ... 30

Integration Test は実際に Minikube のプロセスを動かした上で、機能のテストを行いま す。 そのため、システムリソースを多く使います。 リソース不足が原因でテストが失敗することもあるので、そのときはテストする部分を指 定したり、意図的にコメントアウトしたりします。 Integration Test $ make integration 31

これは個人的な開発の体験談ですが、必ずローカルで動かして、直した箇所が本当に 直っているかを確認します。 人間は、テストに書いていないような使い方をすることもあり、テストはそれを網羅できて いないため、念のため Smoke Test をして問題がないか確認します。 個人体験談）Smoke Test $ make $ ./out/minikube start 32

PR 前後で何が変わるのかを書く Minikube リポジトリには決まりはない ですが ● What type of PR is this? ● What this PR does / why we need it: ● Issue Number ● Does this PR introduce a user-facing change? を書くようにしています PR フロー 33

Bot が自動で応答してくれるので従 います 「〇〇をアサインして」という指示が 出て一応従いますが、アサインして くれた人がレビューしてくれるとは限 りません。 ガチャくらいに思いましょう Kubernetes Bot 34

Reviewer or Maintainer が 「/ok-to-test」をするとテストが走りま す。 Minikube の場合は、複数 Platform 用のテストが実行されます（Jenkins で実行されます）。 CI 上でのテスト 35

Contribution Episodes 36

● 機能追加系 ○ Add addons flag to `minikube start` ○ Change tunnel cleanup flag default to true for auto tunnel cleanup ○ bump dashboard image v2.0.0 ● バグ修正系 ○ fix "minikube update-context" command fail ○ Fix lint error: File is not `goimports` -ed ● Flaky Test 修正系 ○ TestFunctional/parallel/TunnelCmd into serial subtest ● ドキュメント系 ○ Doc fix: use LC_ALL which has priority for system locale instead of LANG ○ site: Add tutorial for VolumeSnapshot to docs これまで出した PRs 37

● fix "minikube update-context" command fail 必ずコマンドが失敗 引数の順番が違うのが原因 修正は 1 行のみ！（調査時間は 3 時間くらい） 想い出深いエピソード - その① updated, err := kubeconfig.UpdateIP (ip, constants.KubeconfigPath, machineName) if err != nil { exit.WithError ("update config", err) } func UpdateIP (ip net.IP, machineName string, configPath ...string) (bool, error) { ... } 38

想い出深いエピソード - その② Fix inverted certificate symlink creation logic Corporate Root CA のインポートが機能しない 原因は、Symlink `ln -s`コマンドの引数の順番間違え 39

Tips 40

● Issue, PR のやりとりは深夜に進む ○ 日本時間で Issue や PR を上げて、朝起きたら返事が来たり PR がマージされていたりする ● 気長に待つ ○ Issue の数が数十〜数百になると、数人しかいないメンテナーが捌くのは難しい ○ 気長に待つ。あまりに待っても無視されるようであれば Ping する ○ 自分の経験だと、4 ヶ月かかった PR もあった（Conference（KubeCon）が間に来たため） ○ Issue は既存から探すのもあれば、自分で作るのもあり ○ Contribution Chance はいくらでも転がっている。転がっていなくても自分で作ってもなんなら 良い ● Issue や Slack で答えてあげるのも一つの Contribution Contribution して初めて知ったこと/気づいたこと 41

Thank you！ 42