rights reserved. 1 Kenta Goto P L A T F O R M E N G I N E E R I N G M E E T U P O N L I N E # 4 ISV/SaaS Solutions Architect Amazon Web Services Japan G.K. KRMOps Dive Deep kro を活⽤した Kubernetes の新たな抽象化
rights reserved. 6 6 Kubernetes マニフェスト増加による管理負荷 6 ü サービスや環境が増えるとマニフェストファイルが増加 ü 似たような内容の YAML ファイルを管理することの煩雑さ ü 本番/開発/検証など複数環境向けに細かい差分が必要な場合、 差分の吸収や上書きする設定が複雑化 ü 環境ごとの想定外の影響やミスを招く ü 開発チーム向けのナレッジシェア、オンボーディングの負荷 の増⼤を招く ü 結果として開発者体験の低下につながるリスクがある ü Platfrom Team による推奨構成の適⽤が困難 ü テンプレートを展開した場合、変更への追従が難しい 設定/環境差分の管理負荷 YAMLファイル増加 による複雑性 認知負荷の増⼤ 開発者体験の低下 Platform Team による ガバナンスの適⽤
rights reserved. 7 7 抽象化を実現する様々な選択肢 7 ツール 概要 特徴 Helm ü Chart を構成するマニフェストは Template によって⽣成される ü 変数やアクションによって抽象化を実現 ü 変数の設定や条件分岐を容易に実現 ü Go Template を理解する必要がある Kustomize ü base マニフェストに対して override す ることにより環境差分を表現 ü 標準ツールとして kubectl に統合され ている ü 複雑なテンプレート機能は提供されて いない CUE ü 宣⾔的な記述をする設定記述⾔語 ü 構造の定義や制約の設定 ü CUE に対する学習コスト CDK8s ü YAML ファイルを TypeScript や Python などを⽤いて定義/⽣成 ü TypeScript 型システムによる品質向上 ü CDK に対する学習コスト KubeVela ü OAM (Open Apllication Model) の実装 ü 複雑な Kubernetes リソースを抽象化 ü KubeVela ⾃体の運⽤負荷
rights reserved. 13 13 AWS Controllers for Kubernetes (ACK) https://aws-controllers-k8s.github.io/community/ ü AWS サービスリソースを定義・管理す る Kubernetes カスタムリソース/コン トローラー ü AWS リソースを宣⾔的に定義 ü AWS API を介して管理
rights reserved. 15 15 Kubernetes Resource Model (KRM) Kubernetes API と通信する際に⽤いられるリソースの宣⾔的管理モデル 特徴 ü API-centric ü 宣⾔的な制御 ü リソース管理の⼀貫性 ü 拡張性 user-declared desired state observed currens state KRM による AWS リソースの管理 ü Kubernetes API ベースでの AWS リソース管理 ü Kubernetes エコシステムの活⽤ 変更 観測 Reconciliation Loop
rights reserved. 20 20 ResourceGraphDefinition (RGD) ü 複数のリソースをまとめてデプロイするための Kubernetes API 拡張を実現する Custom Resource (CR) のこと ü ResourceGraphDefinition (RGD) CR を作成すると、 kro は定義した情報に基づいてクラスター内に新しい Custom Resource Definition (CRD) を⽣成 schema: 新 API の構造を定義 ü ユーザーが設定できるフィールド ü ユーザーが閲覧できる Status の情報 ü 型のバリデーションやデフォルト値 resource: 作成される Kubernetes のリソースを定義 ü リソースのテンプレート ü 依存関係 ü 作成する条件
rights reserved. 21 21 RGD: 依存関係の解決 ü ResourceGraphDefinition はリソースを有向⾮巡回グ ラフ (DAG) として扱う ü RGD を作成後、いくつかのステップを経て必要なコン ポーネントをセットアップ ü そのステップの中で、すべてのリソースが適切な順序で デプロイ可能な健全な依存関係構造になっているかを検 証 ü status.topologicalOrder フィールドでリソース間の依 存関係とそれらの適⽤順序を把握可能 https://kro.run/docs/concepts/resource-group-definitions
rights reserved. 23 23 Simple Schema スキーマや型を定義する⽅法を Simple Schema (※1) として提供 型定義 ü string, integer などの基本型 ü 配列や Map なども定義可能 制約 ü 複数の制約を指定可能 ü 例えば required=true でフィールド指定を必須にする Status フィールド ü CEL 式を活⽤してリソースから値を参照 ü ”Conditions” と “State” はデフォルトで注⼊ ※1 https://kro.run/docs/concepts/simple-schema
rights reserved. 25 25 Instance: Best Practices ü Version Control: Instance の定義はアプリケーションコードと⼀緒に Git のようなバージョン管理 システムで管理する。これにより、変更の追跡、必要な時のロールバック、設定履歴の維持が可能に なる。 ü Use Label Effectively: Instance に意味のある Label を追加することで、適切な整理、フィルタリ ング、他のツールとの統合が可能になる。kro はサブリソースに Label を伝播させる。 ü Active Monitoring: Running の状態だけでなく、定期的に Instance の status を確認する。潜在 的な問題を早期に発⾒し、アプリケーションの健全性を理解するために、条件、リソースステータス、 イベントを監視する。 ü Regular Reviews: Instance の設定が現在の要件とベストプラクティスを反映しているか定期的に レビューする。アプリケーションのニーズの変化に応じて、リソースの要求、制限、その他の設定を 更新します。 ※ https://kro.run/docs/concepts/instances
kennygt51
tammyeverts
jacobian
michaelherold
maltzj
sonatard
trishagee
rmw
bryan
trallard
aarron
chrisshort
sferik
