Kubectlの裏側

Kubernetes Novice Tokyo #30で使用した資料です。

Transcript

1. Kubernetes Novice Tokyo #30 kubectl apply をすると何が起こるか？ ～「情報のやりとり」に注目して～
2. Kubernetes Novice Tokyo #30 自己紹介 名前: 枝村　天真（えだむら　てんま） 業務内容: 某 SIer で内製決済サービスの SRE（新卒１年目） Kubernetes 歴: （業務では）1ヶ月 初登壇です。よろしくお願いします🙇 furon-kuina Focus_Sash
3. Kubernetes Novice Tokyo #30 発表内容 Kubernetes 内部で「どういう情報が」「どうやって」 やりとりされているかに注目して整理してみた
4. Kubernetes Novice Tokyo #30 モチベーション 1ヶ月前、業務で改めて Kubernetes を触りはじめた ブラックボックスは怖いので内部動作について勉強してみる 記事を読んだり、コードを読んだり ⇒ いまいち実感がわかない……
5. Kubernetes Novice Tokyo #30 モチベーション ◎ 実感がわかない原因 具体的に「どういう情報が」「どうやって」やりとりされて いるかわからず、不安な気持ちになる • 「etcd にリソースの情報が保存される」 ⇒ 「リソースの情報」とはなに？？ • 「リソースの変更を検知して」 ⇒ どうやって検知してるの？？
6. Kubernetes Novice Tokyo #30 モチベーション ◎ 実感がわかない原因 具体的に「どういう情報が」「どうやって」やりとりされて いるかわからず、不安な気持ちになる • 「etcd にリソースの情報が保存される」 ⇒ 「リソースの情報」とはなに？？ • 「リソースの変更を検知して」 ⇒ どうやって検知してるの？？ ⇒ コードを解読して整理してみる！
7. Kubernetes Novice Tokyo #30 発表内容 Kubernetes 内部で「どういう情報が」「どうやって」 やりとりされているかに注目して整理してみた
8. Kubernetes Novice Tokyo #30 発表内容 時間の都合上、個人的に「なるほど〜」となった３つに 絞って説明する - kubectl apply から API Server に送られる情報 - API Server が etcd に保存する情報 - Controller や Kubelet が検知するリソースの変更
9. Kubernetes Novice Tokyo #30 発表内容 - kubectl apply から API Server に送られる情報 - API Server が etcd に保存する情報 - Controller や Kubelet が検知するリソースの変更
10. Kubernetes Novice Tokyo #30 kubectl apply Q. kubectl apply から API Server には「どういう情報」が「ど うやって」送られる？
11. Kubernetes Novice Tokyo #30 kubectl apply Q. kubectl apply から API Server には「どういう情報」が 「どうやって」送られる？ A. 「オブジェクトの現在の状態・前回 apply した設定・新しく apply する設定から計算された差分（strategic merge patch）」が 「PATCH リクエスト」で送られる
12. Kubernetes Novice Tokyo #30 kubectl apply Q. kubectl apply から API Server には「どういう情報」が 「どうやって」送られる？ A. 「オブジェクトの現在の状態・前回 apply した設定・新しく apply する設定から計算された差分（strategic merge patch）」が 「PATCH リクエスト」で送られる 実際に送られているリクエストを見てみる
13. Kubernetes Novice Tokyo #30 kubectl apply 例えば Deployment の replica 数を 2 ⇒ 3 に 変更してみると……
14. Kubernetes Novice Tokyo #30 kubectl apply 例えば Deployment の replica 数を 2 ⇒ 3 に 変更してみると…… まず GET で現在のオブジェクトの状態を fetch する fetch した情報の metadata.annotations には、最後に apply した設定 が記述されている 「現状の設定」「最後に apply した設定」「新しく apply する設定」か ら差分を計算し、PATCH リクエストを送っている
15. Kubernetes Novice Tokyo #30 kubectl apply 最後に apply した設定 （今回の設定）が annotations の中に 格納されている spec には差分だけ が入っている
16. Kubernetes Novice Tokyo #30 kubectl apply Q. kubectl apply から API Server には「どういう情報」が 「どうやって」送られる？ A. 「オブジェクトの現在の状態・前回 apply した設定・新しく apply する設定から計算された差分（strategic merge patch）」が 「PATCH リクエスト」で送られる
17. Kubernetes Novice Tokyo #30 kubectl apply なぜ設定を置き換えるのではなく、差分を計算して送信する のか？ ⇒ HPA が決定する replica 数など、Kubernetes 本体が管理 するフィールドを置き換えてしまわないため
18. Kubernetes Novice Tokyo #30 kubectl apply 補足： 差分計算の詳細については、 - Doc: How apply calculates difference and merges changes - GitHub: sig-api-machinery/strategic-merge-patch.md - Qiita: Kubernetes: kubectl apply の動作 - YouTube: kubectl apply, and The Dark Art of Declarative Object Management などに詳しい
19. Kubernetes Novice Tokyo #30 発表内容 - kubectl apply から API Server に送られる情報 - API Server が etcd に保存する情報 - Controller や Kubelet が検知するリソースの変更
20. Kubernetes Novice Tokyo #30 API Server から etcd Q. API Server から etcd には「どういう情報」が保存されてい る？
21. Kubernetes Novice Tokyo #30 API Server から etcd Q. API Server から etcd には「どういう情報」が保存されてい る？ A. 「公式の API Reference に書いてある情報」が保存されてい る（例えば Pod や ReplicaSet なら apiVersion, kind, metadata, spec, status）
22. Kubernetes Novice Tokyo #30 API Server から etcd etcd の中身を kube-etcd-helper というツールで覗いてみる* * 注: 新しいバージョンでは証明書まわりがうまくいかなかったので k8s v1.11.10での結果
23. Kubernetes Novice Tokyo #30 etcd には /registry/replicasets/default/<ReplicaSet_Name> のような key でリソースの情報が保存されている 各フィールドの意味は Doc: API Reference に記述されている ソースコードとしては k8s.io/api/apps/v1/types.go などに定義されている API Server から etcd metadata apiVersion, kind spec status
24. Kubernetes Novice Tokyo #30 発表内容 - kubectl apply から API Server に送られる情報 - API Server が etcd に保存する情報 - Controller や Kubelet が検知するリソースの変更
25. Kubernetes Novice Tokyo #30 リソースの変更検知 Q. Controller や Kubelet がリソースの設定の変更を検知する際 には「どういう情報」が「どうやって」送られている？
26. Kubernetes Novice Tokyo #30 リソースの変更検知 Q. Controller や Kubelet がリソースの設定の変更を検知する際 には「どういう情報」が「どうやって」送られている？ A. 「リソースの変更イベント」が「API Server の Watch API」 を通して送られている
27. Kubernetes Novice Tokyo #30 Watch API とは 変更の検知のために毎回すべての設定を GET したくはない ⇒ 変更した箇所の情報だけを得たい 各コンポーネントは API Server の Watch API に繋いでリ ソースの変更イベントを受け取っている API Server は etcd サーバの Watch API を使って、リソー スの変更イベントの度にイベントを通知している
28. Kubernetes Novice Tokyo #30 Watch API の実装 Watch API の ハンドラの実装は k8s.io/apiserver/pkg/endpoints/handlers/watch.go にある Etcd サーバから送られて くる変更を Event として 受け取る API Server の Watch API に繋いでいるコンポーネ ントにレスポンスを送る Event の型定義
29. Kubernetes Novice Tokyo #30 実際のリクエスト例 resourceVersion をパラ メータに含めて、それ以 降の変更を監視 watch=1をパラメータで 設定 変更の情報が レスポンスされる
30. Kubernetes Novice Tokyo #30 Watch API の偉いところ コネクションが切断されても、処理ができたところの resourceVersion を指定してリクエストを再送することで、 その後の変更だけを知ることができる
31. Kubernetes Novice Tokyo #30 まとめ - だいたい HTTP リクエストを送っているだけ、怖くない - 公式ドキュメントにだいたい書いてある - kubectl apply は差分（strategic merge patch）を送る - etcd に保存されている情報は API Reference で定義され ている - リソースの変更の検知は、API Server の Watch API を 使って行われている