引いては引き直す Kubernetes運用における境界設計とその見直し

Kubernetes運用では、最初に引いた「境界」が実態とずれていくことがあります。本セッションでは、ALB / Ingress、Helm chart、Secret管理の3事例をもとに、責務・認知負荷・変更頻度・ライフサイクルの観点から、どこでつらみが出て、どう見直しているのかを紹介します。完成形ではなく、Platform Engineeringの現場での試行錯誤のアレコレを共有します。 2:19 P

1. 引いては引き直す ~ Kubernetes運用における境界設計とその見直し ~ Kubernetes祭り #1
2. 自己紹介 じぇまき(牧 純平) ギフティ株式会社 Platform Engineeringチームの立ち上げを 推進 2
3. 今日はKubernetes祭りですが、 みなさん、祭りといえば何を思い浮かべますか？ 3
4. 祭りといえば...? 4
5. そう、祭りといえば、神社ですよね！ そして神社といえば、鳥居です 5
6. 鳥居の定義（wikipediaによると） 鳥居（とりい）とは、神社などにおいて神域と人間が住む場所を区画する結界であ り、神域への入口を示す一種の門 「とおりいる（通り入る） 」が転じたとする説がある → 鳥居は境界であり入口と言えます 　 今日は、Kubernetes運用における「どこに鳥居を立てるか」の話をします 6
7. Kubernetesプラットフォームで議論になる境界 何を入口にするか AWS リソースとして扱うか、Kubernetes リソースとして扱うか 変更をどの流れに乗せるか Terraform / Atlantis か、manifest / Helm / ArgoCD か 誰がその変更を持つか Platform Engineering(以降PE)が持つか、アプリチームが持つか 7
8. 今回見る3つのケース ALB / Ingress 入口とルーティング変更をどこで扱うか Kubernetes manifest 生成・所有の責務とアプリごとの自由度をどう分けるか Secret 箱・値・同期の責務をどう分けるか ※ いずれも、いわゆる「キラキラ事例」ではなく、現場での試行錯誤を共有するものです。どうぞ気軽にお聞きください。 8
9. 前提: 今回話すプラットフォームと責務境界 EKS 上に構築 AWSリソースはTerraformで管理しつつ、Atlantisによるapply KubernetesリソースはArgoCDで管理・デプロイ ## イメージ Terraform (Atlantis / PE) └─ PE 管理: AWSリソース Kubernetes manifest (ArgoCD) ├─ PE 管理（ArgoCD application/ 各種Controller / 監視設定など ） └─ アプリチーム管理（各アプリの Helm chart / values） 9
10. 事例1: ALB / Ingress ライフサイクルで境界を引いたが、新たなつらみが発生した話 10
11. ALB / ルーティングの管理責務をどこに置くか問題 前提: ALB 自体は Terraform でも Ingress Controller 経由でも作成できる。 そのうえで、ルーティング変更をどちらの変更フロー・責務に置くかが議論のポイント 観点 Ingress Terraform 変更の置き場所 比較的アプリのデプロイ単位に近い インフラ構成の一部 主な変更主体 アプリチームが変更しやすい PE / インフラチームの変更フローに乗り やすい 周辺リソースとの 連携 Annotation 経由で参照・制御 Terraform の依存関係として管理 ライフサイクル クラスタ / Kubernetes リソースに 連動 クラスタ外の AWS リソースとして維持 11
12. 引いた境界: AWS リソースは Terraform、Pod への接続は Kubernetes AWS の世界 PE / Terraform が管理 Kubernetes の世界 App Team / Helm が管理 ACM / WAF / Security Group ALB Listener Rule (host/path) Target Group 責務の境界 PE / アプリチームの責務はここで分かれる TargetGroupBinding で k8s に接続 TargetGroupBinding Service この境界にした理由: AWSリソースのライフサイクルに寄せたかった ALBとその関連リソース(SG, WAF, ACM)などをTerraformで一体管理したい → 初期構築としては妥当な判断で、一定うまくいったものの... 12
13. 運用して見えてきた課題 アプリチームからルーティング変更の依頼が発生し、その都度PEの作業が発生 アプリ都合の変更なのに、変更対象が PE 側の境界に入り込んでいる → ライフサイクルで引いた境界が、関心事という観点でうまく切れていない 境界の引き直し（検討中） 責務の切り直しを検討中 ライフサイクルの境界は残しつつ、ルーティング周りの切り出し予定 Gateway API 等も視野に入れ調査 13
14. 事例2: Kubernetes manifest manifest の所有と、変更できることは別だった話 14
15. アプリの Kubernetes manifest の生成・所有をどこに置くか 今回の例は Helm chart を使っているが、論点は manifest を生成する責務の置き場所 PE に寄せる 共通テンプレート 差分だけ書く 中間 リファレンス実装 雛形から始める アプリに寄せる 各アプリで定義 生成ロジックも所有す る 見る軸: 変更主体: 変更したい人が、自分で変更できるか 自由度: アプリごとの差分をどこまで許容するか 認知・保守負荷: Kubernetes manifest 生成の複雑さを誰が持つか 15
16. Kubernetes manifest の生成・所有をアプリチーム側に寄せる 引いた境界: manifest を生成する責務を各アプリ側に置く 各アプリのリポジトリに Helm chart を置く Helm template / values をアプリチームが管理する PE は ArgoCD などデプロイの仕組みと、クラスタ側の土台を管理する この境界にした理由: アプリごとの自由度を優先 PEを介在せずに、アプリ側で変更できる範囲を広げたかった 共通テンプレートに落とすべき構成パターンが、初期時点では見えていなかった 16
17. 運用して見えてきた課題 manifest を生成する責務をアプリケーションチームに寄せたことで replicasの変更や環境変数の追加等はアプリ側で自律可能 一方、既存の構成から外れるような変更の場合、PEチーム側に依頼が発生 セルフサービス化が進みにくい・PEがボトルネックに →　拡張性と開発スピードを上げる狙いが裏目になっている部分もある 境界の引き直し（検討中） アプリケーションの構成パターンを整理し抽象化 PEチームで共通テンプレートの作成を検討 ドキュメントの整備等 17
18. 事例3: シークレット 初期構築のスピードを優先したが、結果的に境界を引き直した話 18
19. Secrets Manager の箱と値を、同じチームが管理するか分けるか AWSのSecrets Managerを使う前提も、複数の責務に分解できる 箱を作る Secrets Manager / IAM 値を入れる・変える その値を知っているチームがいる Kubernetes に渡す ECS等とは違いクラスタ内にシークレットを持ち込む手段が必要 19
20. 引いた境界: まずは Terraform で一気通貫に作成 構築のスピード優先で、箱・値・Kubernetes への反映をまとめて PE 側に寄せていた Terraform apply ├─ Secrets Manager の箱 ├─ Secret の値 └─ Kubernetes Secret 運用の流れと見えてきた課題 初回はダミー値を入れ、本物の値で再度 apply アプリ固有の値でも、追加・変更のたびに PE 依頼になる PE は、その値が正しいか判断できない → 値を知っている人と、変更できる人がズレていた 20
21. 境界の引き直し（実施済み）: External Secrets Operator を導入 切る場所 当初の境界 引き直した境界 Secrets Manager の箱 PE が Terraform で作成 PE が Terraform で作成 Secret の値 PE が Terraform で投入（ダミー→再 apply） 値を知るチームが管理 Kubernetes への反映 PE が Terraform で k8s Secret を作成 ESO で自動的に同期 判断軸: その値を知っている / 知るべきなのは誰か 結果 → 責務と実態のずれによるPEへの無駄な依頼がなくなった 21
22. 紹介した3つの事例のまとめ 事例 引いた境界・理由 見えてきた課題 教訓（抽象化） 引き直しの方向 ALB / Ingress ライフサイクルでAWS 側へ寄せる ルーティング変更が都 度PE作業に 変更頻度の高い関心事 は、変更しやすい側に置 く ルーティングを切り出し （Gateway API等を調査） Kubernetes manifest manifest 生成の責務を 各アプリ側で所有 初期構成外の変更は PE依頼でボトルネッ クに 所有を渡しても、認知負 荷が高いと実装は移らな い 構成パターンを抽象化し共通 テンプレを検討 Secret スピード優先でPEに一 元化 値を知る人と変える人 がズレる 変更権限は、その値を知 っている人に一致させる 箱=PE・値=知るチーム・ ESOで同期（実施済） 22
23. 境界は一度では引けない 精度が高い境界を一度で引き切るのは困難 結果的につらみが出てきても、それは失敗ではなく プラットフォームを育てて、組織に根付かせていくために必要なプロセス 実体に合わせて境界を、見直し引き直し続けることが大切 23
24. おまけ: 式年遷宮のスコープは全て Kubernetes では、クラスタを丸ごと作り直し移行する取り 組みを「式年遷宮」になぞらえることがあります。 ただ、その文脈ではクラスタのバージョンや内部のコントロ ーラ・アドオンの更新ばかりに着目されがちな印象です。 (個人の感覚) しかし本来の式年遷宮のスコープは全てを含みます。 式年遷宮は20年に一度、社殿をはじめ全てを新しくして、大御神 に新宮（にいみや）へお遷りいただくわが国最大のお祭りです — [伊勢神宮]https://www.isejingu.or.jp/sengu/the63rd/ Kubernetesを運用していく上でも、社殿(クラスタ)だけでな く鳥居（境界）も、日々見直し・引き直していきたいもので す。 https://iseshima.keizai.biz/headline/2142/ 24
25. ご清聴ありがとうございました