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

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 を
使って行われている