Kubernetesのコントローラーに入門してみる

社内で開催した、Kubernetesのコントローラーに関しての勉強会資料です。
Kubernetesのコンポーネントに関するおさらいや、コントローラーの仕組みに関して解説した後、実際にReplicaSetコントローラーの実装を追っていきます。

Transcript

1. Kubernetesのコントローラーに入門してみる 株式会社WinTicket 24卒　谷口公輔
2. Agenda • 今日のゴール • Kubernetesに関しておさらい • Podがデプロイされるまで • コントローラーとは？ • ReplicaSetコントローラーの実装を覗いてみる • カスタムコントローラーを作る時は ...?
3. 今日のゴール • Kubernetesの基本的なコンポーネントと役割を知る • コントローラーの役割をふんわり理解する • コントローラーの実装をなんとなく読めるようになる
4. Kubernetesに関しておさらい
5. Kubernetesに関しておさらい 「Kubernetesは宣言的である」
6. Kubernetesに関しておさらい https://kubernetes.io/ja/docs/concepts/overview/ 公式ドキュメントを見てみても ...
7. Kubernetesに関しておさらい kubectl apply … Podが立ち上がる
8. Kubernetesに関しておさらい kubectl apply … Podが立ち上がる yamlで定義した値を 正としてリ ソースの状態が保たれる
9. では、どうやって Podはデプロイされる？
10. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/
11. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/ ①kubectl apply -f deployment.yaml
12. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/ ①kubectl apply -f deployment.yaml ②オブジェクトを永続化
13. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/ ①kubectl apply -f deployment.yaml ②オブジェクトを永続化 ③リソースの更新を検知 ＆ Podを生成
14. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/ ①kubectl apply -f deployment.yaml ②オブジェクトを永続化 ③リソースの更新を検知 ＆ Podを生成 ④PodをNodeへ割り当て
15. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/ ①kubectl apply -f deployment.yaml ②オブジェクトを永続化 ③リソースの更新を検知 ＆ Podを生成 ④PodをNodeへ割り当て ⑤kubeletがPodを起動
16. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/ ①kubectl apply -f deployment.yaml ②オブジェクトを永続化 ③リソースの更新を検知 ＆ Podを生成 ④PodをNodeへ割り当て ⑤kubeletがPodを起動 ⑥kubeletがPodの状態など をapiserver 経由で etcdに 永続化
17. Podがデプロイされるまで https://kubernetes.io/ja/docs/concepts/overview/components/ ①kubectl apply -f deployment.yaml ②オブジェクトを永続化 ③リソースの更新を検知 ＆ Podを生成 ④PodをNodeへ割り当て ⑤kubeletがPodを起動 ⑥kubeletがPodの状態等 をapiserver 経由で etcdに 永続化 ↓今日はここを深掘り！
18. コントローラーとは？
19. コントローラーとは？ Desired State (Deploymentなどのマニフェスト )とActual State（実際のPodなど）を常に 監視し、差分があれば Desired Stateにリソースを更新するコンポーネント
20. コントローラーとは？ Desired State （yaml） Actual State （実際のリソース） コントローラー
21. コントローラーとは？ Desired State （yaml） Actual State （実際のリソース） コントローラー ①Desired Stateを取得
22. コントローラーとは？ Desired State （yaml） Actual State （実際のリソース） コントローラー ①Desired Stateを取得 ②Actual Stateを取得
23. コントローラーとは？ Desired State （yaml） Actual State （実際のリソース） コントローラー kubectl apply … ①Desired Stateを取得 ②Actual Stateを取得 ③Desired StateとActual Stateに 差分があれば Actual Stateを更新
24. コントローラーとは？ Desired State （yaml） Actual State （実際のリソース） コントローラー kubectl apply … ①Desired Stateを取得 ②Actual Stateを取得 ③Desired Stateに変更があれば Actual Stateを更新 Reconciliation Loop（=①~③の繰り返し）
25. もうちょっと深掘り
26. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md
27. ???
28. コントローラーのコンポーネントを確認
29. コントローラーとは？ • Informer：リソースの変更を監視。変更があれば in-memoryキャッシュへ保存 ◦ Reflector：apiserverをwatch ◦ Indexer：in-memoryキャッシュ。実体はスレッドセーフな map。Reflectorがwatchした結果を保持 • EventHandler：Informerが検知したイベントを処理する。基本的に workqueueへenqueueする • WorkQueue：EventHandlerにより登録されたイベントを溜める Queue • Lister：Indexerのラッパー。これにより簡単に Indexerからリソースの状態を取得できる コントローラーのコンポーネント： apiserverへの過負荷を避けるため
30. コントローラーとは？ • Informer：リソースの変更を監視。変更があれば in-memoryキャッシュへ保存 ◦ Reflector：apiserverをwatch ◦ Indexer：in-memoryキャッシュ。実体はスレッドセーフな map。Reflectorがwatchした結果を保持 • EventHandler：Informerが検知したイベントを処理する。基本的に workqueueへenqueueする • WorkQueue：EventHandlerにより登録されたイベントを溜める Queue • Lister：Indexerのラッパー。これにより簡単に Indexerからリソースの状態を取得できる コントローラーのコンポーネント： ↑大体ここら辺のコンポーネントを抑えればなんとなくコントローラーのソースコードは読める ...! apiserverへの過負荷を避けるため
31. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md 改めて見てみると... なんとなくわかるか も...?
32. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md client-go： kubernetesの実装でも利用さ れているライブラリ。 kubernertsクラスターのリソー スをAPI経由で操作することが できる。
33. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md Custom Controller： コントローラー本体の構造。 Custom Controllerだけでなく、 Deployment Controllerなどの 構造も同じ。
34. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ①Reflectorがapiserver のイベントを watch
35. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ②イベントを検知すると Delta Fifo queuueへenqueue
36. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ③Delta Fifo queueからイ ベントを取り出し、 in-memory cacheへ保存
37. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ④イベントに応じて、 コントローラーに登録 している handler呼び 出し
38. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ⑤handlerは受け取った イベントを workqueue へenqueue
39. コントローラーとは？ https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ⑥Reconcile処理 ・cacheからdesired stateを取得 ・actual stateを取得 ・desired, actualを比較 し差分があれば desired な状態へと更新
40. ReplicaSetコントローラーの実装覗いてみる
41. ReplicaSetコントローラーの実装を追ってみよう コントローラーをエントリーポイントから追いたい人は ... https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/controller-manager.go から追うと良いですよ👌 下記が確認できます • controller managerの起動 • controller managerに複数リソース（Deployment, ReplicaSetなど）のコントローラーを登録
42. ReplicaSetコントローラーの実装を追ってみよう コントローラーをエントリーポイントから追いたい人は ... https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/controller-manager.go から追うと良いですよ👌 下記が確認できます • controller managerの起動 • controller managerに複数リソース（Deployment, ReplicaSetなど）のコントローラーを登録 →同一のcontroller managerプロセスで複数リソースのコントローラーを実行している
43. ReplicaSetコントローラーの実装を追ってみよう https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md 諸々の初期化処理は省 き、ここら辺の処理を覗い ていきます👀
44. ReplicaSetコントローラーの実装を追ってみよう https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md 諸々の初期化処理は省 き、ここら辺の処理を覗い ていきます👀 ①イベントハンドラーによる オブジェクトのenqueue
45. ReplicaSetコントローラーの実装を追ってみよう https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md 諸々の初期化処理は省 き、ここら辺の処理を覗い ていきます👀 ②実際のreconcile処理 （desired stateへ更新する処理）
46. ReplicaSetコントローラーの実装を追ってみよう https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ①イベントハンドラーによる オブジェクトのenqueue
47. ①イベントハンドラーによるイベントの enqueue やっていることは • イベントの種類（作成、更新、削除）に応じてそれぞれ登録した Functionが呼ばれる • それぞれのFunctionは簡単な前処理をした後、オブジェクトを workqueueへenqueueする これだけ...！
48. ①イベントハンドラーによるイベントの enqueue https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L161
49. ①イベントハンドラーによるイベントの enqueue https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L161 イベントハンドラーの登録 AddFunc： →リソースが作成された際に呼ばれる UpdateFunc： →リソースが更新された際に呼ばれる DeleteFunc： →リソースが削除された際に呼ばれる
50. ①イベントハンドラーによるイベントの enqueue https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L161
51. ①イベントハンドラーによるイベントの enqueue AddFunc： 受け取ったオブジェクトを workqueueにenqueueするだけ。以上！
52. ①イベントハンドラーによるイベントの enqueue https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L161
53. ①イベントハンドラーによるイベントの enqueue UpdateFunc： 新ReplicaSetと旧ReplicaSetのUID比較 →異なれば旧deleteRS呼び出す
54. ①イベントハンドラーによるイベントの enqueue UpdateFunc： workqueueへオブジェクトをenqueue
55. ①イベントハンドラーによるイベントの enqueue https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L161
56. ①イベントハンドラーによるイベントの enqueue DeleteFunc： 削除対象のReplicaSetを取得 →存在しなければtombstoneを参照
57. ①イベントハンドラーによるイベントの enqueue DeleteFunc： 削除対象のReplicaSetを取得 →存在しなければtombstoneを参照 ＊tombstoneはデフォルト値のような もの。 Add→Deleteが即時で実行されると、 キャッシュに乗る前にdeleteRSが呼ば れる可能性がある。その際に tombstoneを参照する。
58. ①イベントハンドラーによるイベントの enqueue DeleteFunc： 削除対象のReplicaSetを取得 →存在しなければtombstoneを参照 ＊tombstoneはデフォルト値のような もの。 Add→Deleteが即時で実行されると、 キャッシュに乗る前にdeleteRSが呼ば れる可能性がある。その際に tombstoneを参照する。 informerによるDeleteイベント処理時 点でtombstoneにnamespace/name は記録されているので、tombstoneを 見れば削除対象のリソースは最低限わ かる
59. ①イベントハンドラーによるイベントの enqueue DeleteFunc： DeleteExpecationsを呼び出し、 Expectationをクリアし、
60. ①イベントハンドラーによるイベントの enqueue DeleteFunc： workqueueに追加
61. ①イベントハンドラーによるイベントの enqueue Deleteイベントハンドラーに関して、ポイントは２つあります • Deleteイベントでは実際にPodの削除は行わない • Controller Expectationによる重複実行の回避
62. ①イベントハンドラーによるイベントの enqueue Deleteイベントハンドラーに関して、ポイントは２つあります • Deleteイベントでは実際にPodの削除は行わない • Controller Expectationによる重複実行の回避
63. ①イベントハンドラーによるイベントの enqueue Deleteイベントでは実際にPodの削除は行わない • →Podはガベージコレクションにより削除 • Owner Referenceのリソースが存在しない（つまり、 Podの親となるReplicaSetが存在しない）Podを 削除している • 参考 ◦ https://kubernetes.io/ja/docs/concepts/architecture/garbage-collection/ ◦ https://github.com/kubernetes/website/blob/main/content/en/docs/concepts/architecture/garbage-collection.md
64. ①イベントハンドラーによるイベントの enqueue Deleteイベントハンドラーに関して、ポイントは２つあります • Deleteイベントでは実際にPodの削除は行わない • Controller Expectationによる重複実行の回避
65. ①イベントハンドラーによるイベントの enqueue Controller Expectationによる重複実行の回避 • →コントローラーはキャッシュを参照するため、重複で削除が実行される可能性がある（下記参考） ◦ Podを5→3にしたい ◦ キャッシュを見るとPodが５つあるので２つ削除 ◦ 再び見ると、５つあるので２つ削除（キャッシュが更新されていない） ◦ →合計４つのPodが削除されてしまう
66. ①イベントハンドラーによるイベントの enqueue これを回避するための Controller Expectation Controller Expectationによる重複実行の回避 • →コントローラーはキャッシュを参照するため、重複で削除が実行される可能性がある（下記参考） ◦ Podを5→3にしたい ◦ キャッシュを見るとPodが５つあるので２つ削除 ◦ 再び見ると、５つあるので２つ削除（キャッシュが更新されていない） ◦ →合計４つのPodが削除されてしまう
67. ①イベントハンドラーによるイベントの enqueue Controller Expectationによる重複実行の回避 • Podを５→３にする • ExpectationにPodを２つ削除することを記録 • Podを２つ削除するリクエストを apiserverへ送る • 再びキャッシュを見るとまだ Podは２つあるが、Expectationのカウンタが２なので何もしない • Podを１つ削除するとExpectationのカウンタを１減らす（これを削除した分繰り返す）
68. ①イベントハンドラーによるイベントの enqueue DeleteFunc： ReplicaSetを削除すると、それに紐づく Expectationは不要になる。 →そのためExpectationによる記録を削 除する 改めて戻ると...
69. ReplicaSetコントローラーの実装を追ってみよう https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md ②実際のreconcile処理 （desired stateへ更新する処理）
70. ②実際のreconcile処理 やっていることは • イベントハンドラーにより enqueueされたオブジェクトをworkqueueから取得しReconcile処理を呼び 出す • Reconcile処理では下記をしている ◦ 対象のReplicaSetを取得 ◦ 対象のReplicaSetの管理対象のPodを取得する ◦ desiredとactualを比較しPodの数の調整 ◦ Podの数、Ready数、Terminating数を計算し、ReplicaSetのStatusを更新
71. ②実際のreconcile処理 やっていることは • イベントハンドラーにより enqueueされたオブジェクトをworkqueueから取得しReconcile処理を呼び 出す • Reconcile処理では下記をしている ◦ 対象のReplicaSetを取得 ◦ 対象のReplicaSetの管理対象のPodを取得する ◦ desiredとactualを比較しPodの数の調整 ◦ Podの数、Ready数、Terminating数を計算し、ReplicaSetのStatusを更新
72. ②実際のreconcile処理 ReplicaSet Controllerが起動すると、 rsc.workerが呼ばれる https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L231
73. ②実際のreconcile処理 workerはprocessNextWorkItemを呼び出す
74. ②実際のreconcile処理 workqueueからオブジェクトを取得
75. ②実際のreconcile処理 syncHandlerを呼び出す。 syncHandlerにはReplicaSet Controller初期化時 にsyncReplicaSetを登録している
76. ②実際のreconcile処理 やっていることは • イベントハンドラーにより enqueueされたオブジェクトをworkqueueから取得しReconcile処理を呼び 出す • Reconcile処理では下記をしている ◦ 対象のReplicaSetを取得 ◦ 対象のReplicaSetの管理対象のPodを取得する ◦ desiredとactualを比較しPodの数の調整 ◦ Podの数、Ready数、Terminating数を計算し、ReplicaSetのStatusを更新
77. ②実際のreconcile処理 https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/replicaset/replica_set.go#L702
78. ②実際のreconcile処理 namespace, nameから対象のReplicaSetを取得
79. ②実際のreconcile処理 ReplicaSetが存在しなければリソースは削除されたとみ なされ、Expectationの記録も削除する
80. ②実際のreconcile処理 対象のReplicaSetがOwnerであるPodとOrphan Podを全て取得。Orphan Podも含めることで、Podが余分に作成されることを防ぐ。 ＊Orphan PodとはOwnerReferenceの設定がされていないPodのこと。
81. ②実際のreconcile処理 ActiveなPodをフィルター ＊Activeとは、Statusが Pendingもしくは、Runningな もの
82. ②実際のreconcile処理 Orphan Podのうち、Podのlabelが、ReplicaSet のselectorに一致する場合は、Ownerとみなし取得
83. ②実際のreconcile処理 実際のPod数とReplicaSetで定義されたPod数を比較 し、差異があれば定義されたPod数へと是正 実際のPod ReplicaSet
84. ②実際のreconcile処理
85. ②実際のreconcile処理 実際のPod数とdesired stateのPod数を比較
86. ②実際のreconcile処理 desired stateより実際のPod数が少ない場合
87. ②実際のreconcile処理 Pod作成のExpectationを記録 これにより、重複して作成されることを防ぐ
88. ②実際のreconcile処理 実際にPodを作成。 大量の Pod を一度 に起動しようとして、 同じエラーですべて 失敗するようなケー ス防ぐために、１つの Podの作成を確認す ると、倍倍にPodを 作成していく
89. ②実際のreconcile処理 作成しなかった分は、 CreationObservedを呼 び、作成済みとして扱う。 （Expectationのカウンタ を減らす） スキップした分は次の Reconciliation loopで 実行する。
90. ②実際のreconcile処理 desired stateより実際のPodが多い場合
91. ②実際のreconcile処理 対象のReplicaSetの親リソースの、 全ての子ReplicaSetのPodを取得。 つまり、親リソースに紐づくPod全てを 取得している。
92. ②実際のreconcile処理 対象のReplicaSetの親リソースの、 全ての子ReplicaSetのPodを取得。 つまり、親リソースに紐づくPod全てを 取得している。 親リソースであるDeploymentのロー リングアップデート時は、新・旧 ReplicaSetが混ざる。
93. ②実際のreconcile処理 対象のReplicaSetの親リソースの、 全ての子ReplicaSetのPodを取得。 つまり、親リソースに紐づくPod全てを 取得している。 親リソースであるDeploymentのロー リングアップデート時は、新・旧 ReplicaSetが混ざる。 DeploymentのすべてのPodの状態 を見て適切に削除対象のPodを選定 するため。
94. ②実際のreconcile処理 親リソースに紐づくPod全体をみて、 削除するPodを選定する
95. ②実際のreconcile処理 Expectationのカウンタを、削除する Podの分だけ記録する。これにより重複 して削除されることを防止する
96. ②実際のreconcile処理 実際の削除処理
97. ②実際のreconcile処理 apiserverに削除をリクエスト
98. ②実際のreconcile処理 削除に失敗した場合でも、Expectationのカウ ンタを1減らす。 次のReconcile処理で再度削除を試みる
99. ②実際のreconcile処理
100. ②実際のreconcile処理 manageReplicasによる調整前の状態で ReplicaSetのステータスを計算。
101. ②実際のreconcile処理 manageReplicasによる調整前の状態で ReplicaSetのステータスを計算。 Podの作成/削除やキャッシュ更新までは時間がか かるので、次のループでReplicaSetの状態を最新 にする
102. ②実際のreconcile処理 ReplicaSetリソースの更新
103. ②実際のreconcile処理 minReadySecondsの設定がある場合は、minReadySeconds秒後に再度Reconcile処 理を実施するための予約設定。 Podの状態がReady→Availableになるまで、minReadySeconds秒かかるので、 minReadySeconds秒後に再度Podを集計しReplicaSetのステータスを更新する
104. ②実際のreconcile処理 workqueueにAddして予約する
105. おさらい ReplicaSet コントローラーがしていることは下記だった • イベントの種類（リソース作成、更新、削除）に応じてハンドラーを呼び出す • 各ハンドラーはworkqueueへenqueue • syncHandler (今回の例だとsyncReplicaSet)によりReconsile処理 ◦ 現在のdesired stateの取得 ◦ 稼働中のPodの取得 ◦ 両者の状態をみて ◦ Reconcile（Podの数の調整）する
106. では、カスタムコントローラーを作る時はどう するか
107. カスタムコントローラー作る時も ... • Informer, Reflector, DeltaFIFO, workqueueなどを意識しないといけない ...?
108. カスタムコントローラー作る時も ... • Informer, Reflector, DeltaFIFO, workqueueなどを意識しないといけない ...? • イベントハンドラーも自分で作らないといけない ...?
109. カスタムコントローラー作る時も ... • Informer, Reflector, DeltaFIFO, workqueueなどを意識しないといけない ...? • イベントハンドラーも自分で作らないといけない ...? • カスタムリソースの構造体も自前で定義 ...?
110. カスタムコントローラー作る時も ... • Informer, Reflector, DeltaFIFO, workqueueなどを意識しないといけない ...? • イベントハンドラーも自分で作らないといけない ...? • カスタムリソースの構造体も自前で定義 ...? • というか、そもそもどこから書いていけば良いんだろう ...
111. カスタムコントローラーのハードル高すぎる ...
112. でも、大丈夫。 便利なツールあります。
113. • controller-runtime ◦ https://github.com/kubernetes-sigs/controller-runtime ◦ client-goをラップした高レベルなライブラリ ◦ 開発者はキャッシュや workqueueなどの意識せず reconciliation loopのロジックに のみ集中できる • kubebuilder ◦ https://github.com/kubernetes-sigs/kubebuilder ◦ controller-runtimeを利用したスキャフォールドツール ◦ main起動のソースコード、プロジェクト全体を自動生成したり、 CRDの構造体を生成 してくれる（フレームワークに近い） ◦ また、make deployなどにより簡単にコントローラーを起動できる 便利なツールたち
114. これらを使うと結構便利にカスタムコン トローラーを作れる ...！
115. のですが...
116. カスタムコントローラー作成の詳細はまた今後 👋