設定記述言語 CUE で YAML Hell に立ち向かえ #k8sjp / Kubernetes Meetup Tokyo 29th

Kubernetes Meetup Tokyo #29 で使用したスライドです。

扱う環境やアプリケーションごとに Kubernetes Manifest の内容を変えたいとき、代表的な方法が二種類あります。

ひとつは Helm のように「穴」が空いたテンプレートを用意しておき、必要に応じて値を当てはめて最終的な YAML を生成する方法。この方法はわかりやすいですが、カスタマイズできるポイントが最初から決まっており、さらに共通した構造を持つテンプレートを階層化することもできないため、全体として自由度が乏しくなるという欠点があります。

もう一つは Kustomize のようにベースとなる YAML を用意して、必要に応じて部分的に上書きしていく方法。こちらの方法ではカスタマイズできるポイントは限定されず、さらに作成した YAML をベースにして追加カスタマイズを加えることも可能ですが、出力される YAML は合成の順番に依存するため最終的な結果がわかりづらいのが欠点です。

これらに対して今回紹介する CUE では、型を「値が取りうる範囲」と捉え、値に対する制約の階層構造を考えます。拡張の柔軟性は残したまま、合成の順番に依存せず最終的な結果を得ることができるのが特徴です。

イベント概要：https://k8sjp.connpass.com/event/170099/

Transcript

1. 設定記述言語 CUE で YAML Hell に立ち向かえ チェシャ猫 (@y_taka_23) Kubernetes Meetup Tokyo #29 (2020/03/26) #k8sjp
2. Manifest をどう管理するか？ #k8sjp
3. Manifest の差分管理の難しさ • Kubernetes のアーキテクチャ ◦ Fine-grained な分散システム ◦ リソース数が多くなり、しかも一貫性が必要 ◦ 少しだけ違うファイルが多数必要 • 組織に応じた責務の分担 ◦ K8s に詳しい基盤側とそうでもないアプリ側 ◦ どこまで任せるか・いかにして統制をとるか #k8sjp
4. https://cuelang.org #k8sjp
5. apiVersion: "apps/v1" kind: "Deployment" metadata: name: "myapp" spec: { replicas: 3 selector: matchLabels: app: "myapp" template: { metadata: labels: app: "myapp" spec: containers: [{ name: "myapp" image: "repo/myapp:v1.0" ports: [{ containerPort: 8080 }] }] } } #k8sjp 子要素が一つのみのパスは圧縮可能
6. CUE によるテンプレーティング #k8sjp
7. deployment: <Name>: { apiVersion: string kind: "Deployment" metadata: name: Name spec: { replicas: *1 | int selector matchLabels app: Name template: { metadata: labels: app: Name spec: containers: [{ name: Name ]} } } } #k8sjp パラメータの利用 デフォルト値
8. deployment: "myapp": { apiVersion: "apps/v1" spec: { replicas: 3 template: spec: containers: [{ image: "repo/myapp:v1.0" ports: [{ containerPort: 8080 }] }] } } #k8sjp パラメータへの代入 属性の追加
9. CUE による差分管理 #k8sjp
10. defaultQoS: { limits: memory: "200Mi" requests: memory: "100Mi" } criticalQoS: defaultQoS & { requests: memory: "200Mi" } #k8sjp 継承先での値の上書き（？）
11. 一度確定した値は上書きできない！ #k8sjp
12. 型かリテラルしか書けないなら JSON Schema と同程度では？ #k8sjp
13. moscow: { name: "Moscow" pop: 11.92M capital: true } municipality: { name: string pop: int capital: bool } Data Schema Concrete Data #k8sjp
14. moscow: { name: "Moscow" pop: 11.92M capital: true } largeCapital: { name: string pop: >5M capital: true } municipality: { name: string pop: int capital: bool } Data Schema Concrete Data CUE Instance #k8sjp
15. moscow: { name: "Moscow" pop: 11.92M capital: true } Data Schema largeCapital: { name: string pop: >5M capital: true } municipality: { name: string pop: int capital: bool } Concrete Data CUE Instance 包含関係 包含関係 int 全体 5M を超える int の全体 11.92 M のみ #k8sjp
16. 「Types are Values」 #k8sjp
17. 類似ツールと CUE の戦略の違い • Kustomize や Jsonnet : 継承ベース ◦ ベースの値を上書きすることでカスタマイズ ◦ 最終的に有効な値がわかりづらい • CUE：制約ベース ◦ 複数の条件を重ねがけしてゆくことで合成 ◦ 確定値は「ちょうどその値になる」という制約 ◦ 結果は合成順序によらず「一番厳しいもの」 #k8sjp
18. https://cuelang.org/docs/concepts/logic #k8sjp
19. https://cuelang.org/docs/concepts/logic 与えられている制約 #k8sjp
20. https://cuelang.org/docs/concepts/logic OK #k8sjp
21. https://cuelang.org/docs/concepts/logic #k8sjp Error
22. CUE の自動化関連機能 • import / export / trim コマンド ◦ 既存の YAML を読み込み、不要部分を削除 • Go との滑らかな連携 ◦ 構造体から CUE の定義読み込みや SDK • CUE 内蔵のカスタムコマンド機構 ◦ 雑多なツール類の増殖を防ぐ #k8sjp
23. まとめ • Kubernetes Manifest 管理の難しさ ◦ カスタマイズ性と制約の統制のバランス • CUE による設定ファイルの管理 ◦ 制約の強さによる包含関係を管理 • 自動化と相性が良い仕組み ◦ ツーリングや既存の資産を利用した導入の重視 #k8sjp
24. Yet Another Manifest Life! Presented by チェシャ猫 (@y_taka_23) #k8sjp