実例から学ぶ Kubernetes Custom Controller の状態管理

1
実例から学ぶ
Kubernetes
Custom Controller の状態管理
GMO ペパボ株式会社
高橋拓也

View Slide

2
アジェンダ
- 自己紹介
- Kubernetes Custom Controller の難しさ
- 状態管理の種類と実例紹介
- まとめ
2

View Slide

3
自己紹介
3

View Slide

4
高橋拓也
自己紹介
GMO ペパボ株式会社でインフラエンジニアをやっています。
コードを書くことと Kubernetes が好きです。
自宅サーバを飼っています。
Twitter: @takutaka1220
GitHub: takutakahashi
4

View Slide

5
宣伝: GMOペパボでは CNDT 2022 で 5セッション登壇しています！
自己紹介
- 11/21 (すべて終了)
- Dynamic VM Scheduling in OpenStack by Kazuhiko Yamashita
- k8s Operatorで運用負担減&ハイブリッドクラウドのコスト最適化をした話 by
Chiaki Sugawara
- 実例から学ぶ Kubernetes Custom Controller のステータス管理 by Takuya
Takahashi
- 11/22 Track F
- [13:20-] ペパボのSREが生産性の向上を目指しCloud Nativeなチーム作り実践し
た話 by Ryuichi Watanabe
- [13:40-] しきい値監視からの卒業！ Prometheus による機械学習を用いた異常検
知アラートの実装 by Takuya Takahashi
5

View Slide

6
Kubernetes
Custom Controller の難しさ
6

View Slide

7
みなさん
7

View Slide

8
カスタムリソース
使ってますか？？
8

View Slide

9
カスタムリソースとは？
カスタムリソース使ってますか？
- Kubernetes の自作リソースを作成できる機能
- その機能で作られたサードパーティーなリソースのこと
- `kubectl list|get|delete` などで操作できるようになる
- 身近なクラスタで `kubectl get crd` を実行してみるとどうなりますか？
9

View Slide

10
カスタムリソースとは？
カスタムリソース使ってますか？
10
気づかぬうちに
たくさん使っています

View Slide

11
作ったことありますか？
11

View Slide

12
カスタムリソースを作る
カスタムリソース作ったことありますか？
- kubebuilder を使うとかんたんに作成できる
- zoetro さんの「つくって学ぶKubebuilder」がとても参考になる
- https://zoetrope.github.io/kubebuilder-training/
- `kubectl get myresource` するだけでもテンション上がる
12

View Slide

13
きちんと実装できますか？
13

View Slide

14
カスタムリソースとコントローラをセットで実装する
カスタムリソースをきちんと実装できますか？
- リソース単体だと etcd に格納されたデータでしかない
- コントローラにより操作対象をリソースに沿った状態へ収束させる
- とてもたいへん
14

View Slide

15
コントローラ大変ポイント
- テストを書くのが大変
- 複雑な処理を実装するのが大変
- 監視のためのメトリクスを実装するのが大変
15

View Slide

16
コントローラ大変ポイント
- テストを書くのが大変
- 複雑な処理を実装するのが大変
- 監視のためのメトリクスを実装するのが大変
16

View Slide

17
複雑な処理を実装するのが大変
- 状態遷移が多い処理
- 様々な対象からデータを取得して目的の状態に収束する処理
17
A A’ B
C
目的

View Slide

18
複雑な処理を実装するのが大変
- Reconciliation Loop を実装する必要がある
- 何度もループを回して理想状態に収束させる動作
- 今回は詳しい説明を割愛します
18

View Slide

19
Reconciliation Loop
- リソース内容に更新があるたびに Reconcile() が実行される
- Reconcile の中でリソースの状態を更新する
19
controller.Reconcile()
Resource
変更を検知
状態を更新

View Slide

20
Deployment の挙動から見る
状態管理の難しさ
20

View Slide

21
Deployment の挙動から見る実装の難しさ
- ローリングアップデート難しすぎる
- Pod の全体の一部の割合を順繰りに更新していくやり方
21

View Slide

22
22
Deploy Deploy
Pod A が
アップデートされた

View Slide

23
23
Deploy Deploy
次のアップデート対象が
Bなのでアップデートする

View Slide

24
24
Deploy Deploy
B が消えちゃった！

View Slide

25
25
Deploy Deploy
B を作る？
その場合バージョンは
何を使う？？

View Slide

26
- Pod の更新有無の管理
- 更新中の成否の管理
- イレギュラー時の処理の決定
- etc…
26

View Slide

27
- Pod の更新有無の管理
- 更新中の成否の管理
- イレギュラー時の処理の決定
- etc…
27
これらをまとめて、
リソースの状態管理と呼ぶことにします

View Slide

28
状態管理の種類と
実例紹介
28

View Slide

29
既存プロダクトはどうやって実装している？
状態管理の種類と実例紹介
- 以下の OSS の状態管理から実装を確認します
- Deployment
- https://github.com/cert-manager/cert-manager
- https://github.com/rook/rook
29

View Slide

30
Deployment の状態管理
30

View Slide

31
Deployment はどうやっているのか
- Deployment は ReplicaSet を子リソースとして持つ
- Deployment が直接 Pod を操作しているわけではない
31
Deploy
Deployment
RS
同一設定の Pod を複数起動する
Pod の個数を制御する

View Slide

32
- ReplicaSet が個数の管理を実行する
32
replica: 3
1個消えた

View Slide

33
- ReplicaSet が個数の管理を実行する
33
replica: 3 replica: 3
1個立て直す

View Slide

34
- ReplicaSet 内は同じ設定の Pod が動いている
34
replica: 3
全部 v0.1.0

View Slide

35
- ローリングアップデートは ReplicaSet (rs) をうまく使って実現している
- アップデート前(old) と後(new) の設定の rs を持っている
35
Deployment
old
replica: 3
new
new
replica: 0

View Slide

36
- new rs の replicas を 1にする
36
Deployment
old
replica: 3
new
new
replica: 1

View Slide

37
- new rs の replicas を 1にする
- rs が更新中の状態に遷移するので更新完了 (Ready) まで待つ
37
Deployment
old
replica: 3
new
new
replica: 1 Not Ready

View Slide

38
- old rs の replicas を 2にする
- old rs のステータスが Ready になるまで待機する
38
Deployment
old
replica: 2
new
new
replica: 1

View Slide

39
- 以下繰り返し
39
Deployment
old
replica: 1
new
new
replica: 2
old
replica: 2

View Slide

40
40
Deployment
old
replica: 1
new
new
replica: 2

View Slide

41
41
Deployment
old
replica: 0
new
new
replica: 3
old
replica: 1

View Slide

42
42
Deployment
old
replica: 0
new
new
replica: 3

View Slide

43
- RollingUpdate 中に Pod の削除が発生したら？
43
Deployment
old
replica: 1
new
new
replica: 2

View Slide

44
- 削除された Pod が所属する rs が復旧を行う
- old, new 両方が Ready になるまで RollingUpdate を中断する
44
Deployment
old
replica: 1
new
new
replica: 2
Ready
Not
Ready

View Slide

45
- もとどおりになったら処理を再開する
45
Deployment
old
replica: 1
new
new
replica: 2
Ready
Ready

View Slide

46
単一責務パターン
- 責務の異なるリソースの階層構造になっている
- 子リソースに責務を委譲しているといえる
46
Deployment ReplicaSet Pod
App の更新を管理する指定個数 Pod を作成するワークロードを動かす

View Slide

47
単一責務パターンのメリット
- Deployment は想定する ReplicaSet が作成できるかに特化すれば良い
- 実装がシンプルに保てる
- リソースのテストを記述しやすい
47

View Slide

48
単一責務パターンのメリット
- 自作カスタムリソースに応用しやすい
- ワークロードは Deployment を作成すれば状態管理に悩まない
- 複雑な状態管理は得意な他リソースを選定してやらせてしまえる
- ロードバランシングが必要なら svc を作る
48

View Slide

49
単一責務パターンのデメリット
- 結合テストは難しくなる
- 作成した子リソースの設定は本当に想定した動きをするのか？
- Pod に渡したコマンドライン引数でプロセスは起動するのか？
- Pod が起動しなかった際のフォールバックはうまくいくのか？
49

View Slide

50
単一責務パターンのデメリット
- 状態管理の実装の仕方を学習できない
- 難しいところを他リソース任せにしてる
- 実際どうやって状態を管理していくの？
50

View Slide

51
Deployment まとめ
- 1リソースにつきひとつの責務を管理する単一責務パターン
- 子リソースの通知する状態を監視することで状態を管理できる
51

View Slide

52
cert-manager
52

View Slide

53
cert-manager
- 証明書を管理、運用するプロダクト
- ACME プロトコルを利用して Let's Encrypt の証明書を作りがち
53

View Slide

54
cert-manager
- 複数の CRD (Custom Resource Deﬁnition) が連携している
54
Certificate CertificateRequest
Issuer
ClusterIssuer
Order Challenge

View Slide

55
cert-manager
- Certiﬁcate は証明書の情報を持つリソース
- Issuer から証明書作成に必要となる情報を参照する
55
Certificate
Issuer
ClusterIssuer

View Slide

56
cert-manager
- Certificate は CertificateRequest を作成する
- CertificateRequest が完了するまで待機し、完了したら Secret を作る
56
Issuer
ClusterIssuer

View Slide

57
Status.Conditions パターン
- 状態の確認には Status.Condition を使う
- ↓Certiﬁcate の Condition の例
57

View Slide

58
- Condition は「特定の状態を確認する」目的で使う
58

View Slide

59
- 「カレー作り」を Condition で表現してみる
59
Type: にんじんが切られている
Status: True
Type: いもが切られている
Status: True
Type: 肉に火が通っている
Status: True
Type: 鍋に水が入っている
Status: False
59
Type: 具材が煮込まれている
Status: False
Type: カレーが完成している
Status: False
ex: カレーを作るコントローラ
カレー作りの工程を
表現する状態

View Slide

60
- 各状態を表す Condition を見て次の行動を決定する
60
Status: True
Status: True
Status: True
Status: False
60
Status: False
Status: False
Next Action:
鍋に具材と水を入れて火にかける

View Slide

61
- 状態が変更されたら
61
Status: True
Status: True
Status: True
Status: True
61
Status: False
Status: False
Next Action:
水を入れた
Next Action:

View Slide

62
- 次の行動も状態を見て再度決定される
62
Status: True
Status: True
Status: True
Status: True
62
Status: False
Status: False
Next Action:
水を入れた

View Slide

63
- Certiﬁcate リソースはふたつの Condition Type を持つ
- Ready … 処理が完了しているかどうか
- Issuing … 処理中かどうか
63
CertificateConditionReady CertificateConditionType = "Ready"
CertificateConditionIssuing CertificateConditionType =
"Issuing"
https://github.dev/cert-manager/cert-manager/blob/e7ed5c491be93b3c93ea236d02a455aa2d6cd00a/pkg/apis/certmanager/v1/types_certiﬁcate.go#L498-L516

View Slide

64
cert-manager
- Issuing が True = 処理中である場合、新しい CertiﬁcateReuest を作る
64
if !apiutil.CertificateHasCondition(crt, cmapi.CertificateCondition{
Type: cmapi.CertificateConditionIssuing,
Status: cmmeta.ConditionTrue,
}) {
return nil
}
// 省略
return c.createNewCertificateRequest(ctx, crt, pk, nextRevision,
nextPrivateKeySecret.Name)
https://github.dev/cert-manager/cert-manager/blob/e7ed5c491be93b3c93ea236d02a455aa2d6cd00a/pkg/controller/certiﬁcates/requestmanager/requestmanager_controller.go#L152-L229

View Slide

65
cert-manager
- Certiﬁcate は証明書の再作成 (re-issue) も責務とする
- 証明書の再作成が必要かどうかを監視している
65
Issuer
ClusterIssuer
Controller

View Slide

66
cert-manager
- 証明書の再作成をする必要が出たら、Issuing = True にする
- 状態収束に必要な処理がすべて動作する
66
log.V(logf.InfoLevel).Info("Certificate must be re-issued",
"reason", reason, "message", message)
crt = crt.DeepCopy()
apiutil.SetCertificateCondition(crt, crt.Generation,
cmapi.CertificateConditionIssuing, cmmeta.ConditionTrue, reason,
message)
if err := c.updateOrApplyStatus(ctx, crt); err != nil {
return err
}
c.recorder.Event(crt, corev1.EventTypeNormal, "Issuing", message)
return nil
}
https://github.dev/cert-manager/cert-manager/blob/e7ed5c491be93b3c93ea236d02a455aa2d6cd00a/pkg/controller/certiﬁcates/trigger/trigger_controller.go#L200-L201

View Slide

67
cert-manager
- Certiﬁcate は CertiﬁcateRequest (CR)を作成する
- CR.Status.Conditions が Ready = True になっていたら Secret を作る
67
Issuer
ClusterIssuer

View Slide

68
cert-manager
- CR は Order を作成する
68
Certificate CertificateRequest Order
Issuer
ClusterIssuer

View Slide

69
cert-manager
- Order は Challenge を作成する
69
Certificate CertificateRequest Order Challenge
Issuer
ClusterIssuer

View Slide

70
cert-manager
- 各 CRD の責務はこんな感じ
- 子リソースの完了は子リソースの Conditions を確認する
70
Certificate CertificateRequest Order Challenge
Issuer
ClusterIssuer
CR を作成する
CR の完了を監視する
Secret を作る
renew を管理する
Order を作成する
Order の完了を監視する
Challenge を作成する
Challenge の完了を
監視する
Challenge が失敗したら再
作成する
ACME Challenge を
実行する

View Slide

71
cert-manager まとめ
71
- Certiﬁcate を頂点とする階層構造を持つ
- 状態管理は Conditions パターンを用いる
- 親は子リソースの状態を Status.Conditions から取得する
- コントローラは Condition の値を見て後続の処理を決定する

View Slide

72
rook
72

View Slide

73
rook
73
- Cloud Native なストレージクラスタオペレータ
- k8s 内で Ceph クラスタを管理する rook/ceph がメイン
- 国内ではサイボウズさんが積極的に開発している

View Slide

74
rook
74
- CephCluster リソースについて紹介します
- Ceph のクラスタバージョンやプロセス個数などを管理する
CephCluster

View Slide

75
rook
75
- CephCluster も Condition を持つがほぼ参照されない！
CephCluster
Type: Progressing
Status: True
Type: Ready
Status: False
Progressing, Ready くらい

View Slide

76
rook
76
- Message でどこまで処理が進んだかユーザーに通知する役割を持つ
- Progressing Condition の Message を都度更新している
CephCluster Type: Progressing
Status: True
Message: "Detecting Ceph version"
Type: Ready
Status: False

View Slide

77
rook
77
- じゃあ状態はどうやって管理しているのか？
CephCluster

View Slide

78
rook
78
- 状態を管理していない！！

View Slide

79
rook
79
- Operator の Reconcile 関数内ですべての手順を実行する
- 各手順が高度に冪等性が担保されており、何度実行されてもいい
1. initializeCluster()
a. configureMonitoring() // クラスタの監視を起動する
b. detectAndValidateCephVersion() // Ceph Cluster のバージョンを確認する
c. reconcileCephDaemons() // Ceph のすべてのプロセスを理想状態にする
i. mons.Start() // mon を開始する
ii. mgrs.Start() // mgr を開始する
iii. osds.Start() // osd を開始する

View Slide

80
なぜ rook では状態を管理しない？(推測)
80
- CephCluster は1つの k8s クラスタに1組を想定している
- 1リソースに使える処理時間が長い
- CephCluster はデータの耐久性を何よりも重視している
- 処理速度よりも安全な処理を選択したのでは？
- ゆっくりと状態を確認しながら処理するほうがいい

View Slide

81
なぜ rook では状態を管理しない？
81
- 状態管理しないためテストがかっこいい
r := &ReconcileConfig{
client: cl,
context: c,
config: controller.OperatorConfig{
OperatorNamespace: namespace,
Image: "rook",
ServiceAccount: "foo",
},
}
res, err := r.Reconcile(ctx, req)
assert.
NoError(t, err)
assert.
False(t, res.Requeue)
})
https://github.dev/rook/rook/blob/3744a9d79576eab748aefb53f5465cd4cad0ab24/pkg/operator/ceph/controller_test.go#L73-L87

View Slide

82
rook まとめ
82
- 状態管理しないという選択もある
- 1リソースにかかる時間が増えても整合性を保ちたい場合おすすめ

View Slide

83
まとめ
83

View Slide

84
状態管理は難しい
まとめ
84
- イチから実装するのはとても大変である
- 広く使われているリソースの肩に乗ることで楽ができる
- 既存の実装をよく観察することが大事
- Conditions パターンはとても広く使われている

View Slide

85
多くの自作コントローラを本番投入しながら学んでいます！
まとめ
85
- 一緒にコントローラを開発して状態難しい〜をやりませんか！

View Slide

86
We are HIRING !!!
https://recruit.pepabo.com/
86

View Slide

87
oci-image-operator
おまけ (というより没になったネタ
87

View Slide

88
oci-image-operator
88
- 拙作プロダクト
- git の更新をもとにイメージビルドをするワークフローを実行する
- 動作例:
- branch1 への Push を検知する
- branch1 の HEAD Revision をタグに持つイメージの存在チェック
- 存在しなかったらイメージを作成、プッシュする

View Slide

89
oci-image-operator
89
- Detected, Checked, Uploaded の3つの Condition Type がある
- 検査対象のブランチやタグごとに Condition を持つ
Image
Type: Detected
Target: branch1
Status: False
Type: Checked
Target: rev1
Status: False
Type: Uploaded
Target: rev1
Status: False
ブランチの変更を
検知したか？
対象のイメージが
レジストリに存在するか？
対象のイメージの
プッシュに成功したか？
git

View Slide

90
oci-image-operator
90
- Image リソースが作成される
Image
git

View Slide

91
oci-image-operator
91
- git リポジトリを監視するDeployment を作成する
Image Deployment
git

View Slide

92
oci-image-operator
92
- 変更を検知したら Detected=True, Checked=False を設定する
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Type: Checked
Target: rev1
Status: False

View Slide

93
oci-image-operator
93
- レジストリにイメージがあるか確かめる Job が作成される
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Job
registry
Type: Checked
Target: rev1
Status: False

View Slide

94
oci-image-operator
94
- 結果を見て Uploaded の Condition をセットする
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Job
registry
Type: Checked
Target: rev1
Status: True
Type: Uploaded
Target: rev1
Status: False

View Slide

95
oci-image-operator
95
- Uploaded=False だったらビルドのための Job を動かす
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Job
registry
Type: Checked
Target: rev1
Status: True
Type: Uploaded
Target: rev1
Status: False
Job

View Slide

96
oci-image-operator
96
- Check の Job がイメージの存在を確認したら Uploaded=True にする
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Job
registry
Type: Checked
Target: rev1
Status: True
Type: Uploaded
Target: rev1
Status: True
Job

View Slide

97
oci-image-operator
97
- git のブランチの変更を検知すると Deployment が Condition を作成する
Image Deployment
git
Type: Detected
Target: branch1
Status: True
registry
Type: Checked
Target: rev2
Status: False
Type: Uploaded
Target: rev2
Status: False
Type: Checked
Target: rev2
Status: True
Type: Uploaded
Target: rev2
Status: True

View Slide

98
oci-image-operator の状態管理の特徴
98
- CRD がひとつである
- Condition がイメージのリビジョンごとに存在する

View Slide

99
oci-image-operator の状態管理は成功したのか？
99
- 改善の余地がある
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Type: Checked
Target: rev1
Status: True
Type: Uploaded
Target: rev1
Status: True

View Slide

100
oci-image-operator の改善ポイント
100
- Detected の状態は必要ない
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Type: Checked
Target: rev1
Status: True
Type: Uploaded
Target: rev1
Status: True
True から
変更なし

View Slide

101
101
- Checked, Uploaded の役割が重複している
- 存在しない状態があり無駄
Image Deployment
git
Type: Detected
Target: branch1
Status: True
Type: Checked
Target: rev1
Status: True
Type: Uploaded
Target: rev1
Status: True
Checked = False
Uploaded = True
…?

View Slide

102
102
- Checked だけでよい
Image Deployment
git
Type: Checked
Target: rev1
Status: True

View Slide

103
103
- 変更を検知したら Checked=False の Condition を作成する
Image Deployment
git
Type: Checked
Target: rev1
Status: True
Type: Checked
Target: rev2
Status: False

View Slide

104
104
- イメージのワークフローは子リソースに切り出したほうがいい
Image Ensure
Ensure
Git リポジトリを監視する
変更があったら Ensure を作
成する
Check を作る
Check の結果を見て Build を作
る
Check
Build

View Slide

105
oci-image-operator まとめ
105
- 状態は少なければ少ないほどいい
- リソースの役割は少ないほうがいい
- 役割が増えたら子リソースに切り出す

View Slide

106
リソースの状態をうまく管理するには
- Reconcilation Loop の根底にある考えを参考にする
- 状態を検知し以降の処理を決定する Level Triggering を行う
106

View Slide

107
Reconcilation Loop について参照
- https://deeeet.com/writing/2018/12/13/how-kubernetes-change-our-wa
y-of-automation/
- https://zoetrope.github.io/kubebuilder-training/introduction/basics.html
- https://hackernoon.com/level-triggering-and-reconciliation-in-kubernete
s-1f17fe30333d
-
107

View Slide

実例から学ぶ Kubernetes Custom Controller の状態管理

実例から学ぶ Kubernetes Custom Controller の状態管理

Takuya TAKAHASHI

More Decks by Takuya TAKAHASHI

Featured

Transcript