Kubernetesクラスターを引き継ぐ技術

CloudNative Days Tokyo 2023『Kubernetesクラスターを引き継ぐ技術』の登壇資料です。
https://event.cloudnativedays.jp/cndt2023/ui

Transcript

1. Kubernetesクラスターを 引き継ぐ技術 2023/12/12 しぶい
2. 自己紹介 shibui yusuke • もともと文学部の大学院卒。 • いろいろ → 12月からStability AI Japan • MLOpsとかデータ基盤とかバックエンドとか いろいろエンジニア • もともとクラウド基盤の開発、運用 • ここ6年くらいMLOpsとバックエンドとインフラとデータ関 連で仕事 • Github: @shibuiwilliam • FB: yusuke.shibui • 最近の趣味：ルービックキューブ cat : 0.55 dog: 0.45 human : 0.70 gorilla : 0.30 物体検知 2
3. • 発売中！ • https://www.amazon.co.jp/dp/4798173401/ • https://github.com/shibuiwilliam/building-ml-system • 発売中！ • https://www.amazon.co.jp/dp/4798169447/
4. 技術評論社Software & Designで MLOpsについて連載中！ • 2023年8月号　MLOpsの概要 • 2023年9月号　MLOpsのためのスキルセットとチーム構成 • 2023年10月号　方針策定とMLOpsのためのツール • 2023年11月号　MLOpsのための技術選定 • 2023年12月号　LLMのためのDevOps • 2024年1月号　MLOpsと評価（予定） • 2024年2月号　推論システム（予定） MLOpsについてあまり他では取り上げられないようなテーマを 中心に記事を書いています！
5. 本日の目次 • インフラ基盤の技術選定 • 技術、プロダクト、メンバー • Kubernetesクラスターを誰かから引き継ぐ技術 • 誰かにKubernetesクラスターを引き継ぐ技術
6. インフラ基盤の技術選定
7. コンピューティング基盤の歴史概略と私 2007 AWS EC2 2013 Docker 2008 MS Azure 2008 Google App Engine 2009 Mesos 2014 Kubernetes 2011 OpenShift 2014 AWS Lambda 2014 AWS ECS 2014 GCP GKE 2018 AWS EKS 2021 AWS App Runner 2018 GCP CloudRun 2018 Azure AKS 2009 働き始める 2011 自社でIaaSを リリース 2012 自社でPaaSを リリース 2013 Dockerと出会う 2015 Kubernetesと 出会う 2016 機械学習を 仕事にする 2018 Kubernetesで ML基盤を作る 2020 Kubernetes クラスターを 引き継ぐ（5個） 2021 引き継ぐ （2個） 2022 引き継ぐ （3個）
8. 数年おきにトレンドの変わるインフラ技術 クラウドの登場以降、 コンピューティング基盤の トレンドは数年おきに 地殻変動が起こっている。 ここ数年のトレンド： - サーバレス(AWS Lambda) - コンテナ オーケストレーション (Kubernetes) - Kubernetes的なサーバレス (CloudRunやApp Runner) 物理や仮想マシンから離れ、 Dockerに代表される コンテナをベースとした 開発が定着。 DockerイメージやIaCを 非インフラエンジニアが 開発することが増えている。 ・・・次の地殻変動は？
9. • 一度選定したインフラをやり直すことは難しいが、決めないとプロダクト開発が進まない。 • プロダクトの起ち上げ期： PMFを目指すため早急に PDCAを回し始めたい。 • プロダクトの成長期：増え続けるトラフィックと機能に対応する基盤が必要。 • 技術選定は常にギャンブル。当てる努力は重要だが、当たらなくても誰かを責めるものではない。 • それでも、初期に誰かが作った Kubernetesクラスターを運営しないとプロダクトが止まることも事実。 今日も誰かがKubernetesクラスターを作る 市場調査 買い手を 探す 作りつつ 採用 MVPを 作る ビジネス モデル化 PoCと 改修 方向性を 模索 拡張性を 検討 どのタイミングで インフラを選定する？ ・・・
10. 選定のタイミング 市場調査 買い手を 探す 作りつつ 採用 MVPを 作る ビジネス モデル化 PoCと 改修 方向性を 模索 拡張性を 検討 どのタイミングで インフラを選定する？ ・・・ 枯れたor手慣れた インフラならここ プロダクトの規模を 鑑みて選定できる 移行が必要になるが、手 堅い選定が可能 技術的チャレンジの タイミングは？
11. AWS 事例. 技術的チャレンジのKubernetes 技術的チャレンジとして構築した Kubernetesクラスター。 データ抽出・整形ジョブを実行する 基盤として稼働するKubernetes クラスター（EKS on Fargate）。 メインインフラはECS Fargate。 しかしこのジョブだけ独立してKubernetesクラ スターで稼働。 Kubernetesに詳しい人は皆無。 ECS Fargate （メインインフラ） EKS on Fargate S3 ALB Cloud Formation WebUI Pod データ Job GitHub Repository データ Pod Python Kubernetes
12. AWS 事例. 技術的チャレンジのKubernetes 調査 EKS on FargateではJobから起動したPodは消えない。 大量のJobを実行するため、大量の野良 Podを発見。 月額XX万円を浪費。 Web UIがPythonのKubernetesライブラリを使って Jobを起動する仕組み。 AWS Consoleから構築。 TerraformやCloudFormationはなし。 社内ツール。ユーザも社内。 ECS Fargate （メインインフラ） EKS on Fargate S3 ALB Cloud Formation WebUI Pod データ Job GitHub Repository データ Job データ Job データ Job データ Job データ Pod Python Kubernetes
13. AWS 事例. 技術的チャレンジのKubernetes ECS Fargate （メインインフラ） EKS on Fargate S3 ALB Cloud Formation WebUI Pod データ Job GitHub Repository データ Job データ Job データ Job データ Job データ Pod Python Kubernetes 仕組みはコードを 読めばわかる 技術選定は コードを読んでも わからない
14. 事例. 技術的チャレンジのKubernetes • 意思決定 ◦ EKS on FargateはEKSに移行する。 ◦ コードは変更しない。 PythonからKubernetesリソースを起動する箇所は維持。 ◦ インフラだけ刷新して、業務ロジックは変更しない。
15. 事例. 技術的チャレンジのKubernetes 計画 移行方法：EKS on FargateはEKSに作 り直す。 作り方：インフラはマニフェストを定 義し、eksctlからデプロイ。 関連リソースはCloudFormationに 寄せる。 実行 作業はダブルチェックしつつ、 録画。 可能な限りGitHubにIssueとPRで 記録する。 JobとPodの監視を追加し、 不要なリソースを検知。 レビュー 移行手順：EKS on Fargateを EKSクラスターに移行する 作業手順。 eksctlの使い方ドキュメント。 意思決定：今回の技術選定の背景 を説明。今後改めて意思決定すると きに参考する。 メンバー 主担当：自分 ダブルチェック：チームリーダー
16. 事例. 技術的チャレンジのKubernetes 期間：合計1ヶ月程度 調査：1週間 検証、ドキュメンテーション： 2週間 作業：1日 結果 データの破損なく EKS on FargateからEKSに移行。 ECS Fargateに移行したかったが、ロジックが Kubernetesに依存していたため断念。 1年ほどEKSクラスターを運用。
17. 塩漬けクラスター引き継ぎ&移行 課題 運用されていないKubernetesクラスターは クラスターバージョンやノードバージョンが 更新されていないことが多い。 対策 クラスターリソースを調査し、可能な限り 最新バージョンに更新する。 アクション • クラスターリソースの調査 • Out datedなAPIやリソース、 マニフェストの更新 • クラスターバージョンおよび ノードバージョンの更新 • ここまでの作業を記録に残す Workaround • 工数があれば、このタイミングでKubernetesク ラスターを他のインフラに 移行することも検討する。
18. 技術的チャレンジの意義 • 技術的チャレンジのメリット ◦ 新しい技術は使ってみないと有用性がわからない。 ◦ エンジニアの学習機会や楽しみ。 • デメリット ◦ 作っただけで終わることがある。 ◦ 新しい技術が継続されるとは限らない。 ◦ なぜその技術が選ばれたのか、なぜそう作ったのか、 「技術的チャレンジ」以外の理由がない。 • 作るだけならWhatとHowがあれば良いが、運用するためには Whyが必要。
19. Kubernetesクラスターを引き継ぐ技術 • 引き継ぐときに意思決定を明確にする。 • インフラの要件と、業務ロジックのためのインフラを分けて整理する。 ◦ インフラ要件：コンテナを動かす。 ◦ 業務ロジックのためのインフラ：ユーザの操作に対してコンテナを動的に起動する。 • これらの選定背景をドキュメントに残す。
20. 技術、プロダクト、メンバー
21. プロダクトと技術の寿命 • プロダクトの寿命 ビジネスの終了、会社の閉鎖。 • 技術の寿命 ライブラリやモジュール、OSのEoS。 メジャーバージョンアップによる 破壊的変更で短期的に生まれ変わる こともある。 メンテナ不在になるライブラリもある。 • 失敗するプロダクトは プロダクトの寿命 ＜ 技術の寿命 成功するプロダクトは 技術の寿命 ＜ プロダクトの寿命 • 新しい技術は破壊的変更が頻繁。 ◦ AI系のライブラリ ◦ コンテナやKubernetes （最近落ち着いてきたけど・・・） • プロダクトの寿命よりも技術が先に 寿命を迎えたら、プロダクトは 移行・更新・終了する必要がある。
22. • フロントエンドに限らず、開発頻度が高い技術だと 寿命が短いものが多い傾向。 • コンテナ黎明期に登場した各種基盤 （Docker Swarm、Mesos、Cloud Foundry・・・）も 同様に寿命が短かった覚えがある。 • AIは未だに短いものが多々ある。
23. 技術、プロダクト、メンバーの期限 メンバー プロダクト 技術 初期メンバー 枯れた技術：期限が長い 当たれば長生きする 新しい技術：頻繁に変わる　　　・・・ 転職者 短期で離職 継続 ほとんどが短命・・・
24. 事例. 技術、プロダクト、チームの時間軸 当初は5クラスターを最大16名で運営。 機械学習のための学習、推論基盤 （CRD）が稼働。 学習クラスター2個：GKEとEKS 推論クラスター3個：開発、 ステージング、本番 GKE EKS 学習 学習 推論開発 推論ステージング 推論本番 理想：担当チームを分けつつ全体で運営
25. 事例. 技術、プロダクト、チームの時間軸 チーム再編成、異動、退職により、 メンバーが散り散りになる。 唯一チーム横断でEM（自分）が クラスター管理者になる。 GPUを使ったEKSクラスターが残る。 GKE EKS 学習 学習 推論開発 推論ステージング 推論本番 現実：EMが運営
26. 事例. 技術、プロダクト、チームの時間軸 • 課題 ◦ EKSクラスターは2018年のEKSリリース初期に作られたもの。 ◦ CloudFormation、TerraformによるIaCはない。eksctlで構築されたものでもない。 コンソールからクラスターをデプロイ。 ◦ ドキュメントなし。マニフェストは管理されているが、主なリソースはCRDから起動。 ◦ 稼働しているのは機械学習の学習パイプライン。 自作CRD（開発者は退職済み）で、GolangバージョンもKubernetes APIバージョンも 2018年以前のもの。 ◦ EKSクラスターおよびノードはデプロイ以降、バージョン更新されず。 ◦ 2020年中旬にクラスターバージョンのEoSが迫っている・・・！
27. 事例. 技術、プロダクト、チームの時間軸 AWS IAM EKS Namespace EC2 GPU Disk VPC Repository k8s manifest Pod PVC CRD S3 コンソールか ら構築 Out dated 4種類の 定期ジョブ Out dated
28. 技術やプロダクト First Penguine 急増！ 淘汰… 生き残り このタイミングで 独自開発しすぎる と・・・ Winner takes allで 独自プロダクトが 負ける
29. 事例. 技術、プロダクト、チームの時間軸 事業調査 メンテナンス：メンテナンス停止 しても問題ない。 メンテナンスは時間を決めて 2時間以内に完了する必要あり。 月初、週初めは NG。 クラスター調査 eksctl：最初からeksctlで構築する必 要あり。 kubectl：使用可能。 リソース: CRDが動的にデプロイ。 GPU インスタンスを使用。 CuDA/CuDNNバージョンが古い。 CRD調査 ソースコード：CRDはGitHubの コミットハッシュで遡れる。 CRD 機能：機械学習パイプラインを 定義し、ジョブを起動。
30. 事例. 技術、プロダクト、チームの時間軸 CRD Operator Custom Resource watch reconcile control pod svc deploy rs job … role cluster role role binding cluster role binding group … $ kubectl get crds すると意外とたくさん出てくる。 CRDそれぞれに権限と操作が定義されている。 権限はIAMと紐づいていることもある。 独自CRDの正常系を知らないと移行できない。 version
31. 事例. 技術、プロダクト、チームの時間軸 CRD Operator Custom Resource watch reconcile control ここで作られる リソースと・・・ Podのログを残す ここを変更することで ・・・ 正常系を知るために
32. 事例. 技術、プロダクト、チームの時間軸 計画 移行方法：更新するのではなく、 クラスターを作り直す。 作り方：インフラはマニフェストを定 義し、eksctlからデプロイ。 CRDはバージョン更新のみ。 実行 6月中旬の水曜日午後に実施。 作業はダブルチェックし録画。 コマンドとログを記録に残す。 レビュー 移行手順：既存クラスターを 新クラスターに移行する 作業手順。 eksctlの使い方ドキュメント。 意思決定：今回の技術選定の背景 を説明。今後改めて意思決定すると きに参考する。 メンバー 主担当：自分 レビュー：各チームのTL ダブルチェック：TL
33. 事例. 技術、プロダクト、チームの時間軸 期間：合計1ヶ月程度 調査：1週間 検証、ドキュメンテーション： 2週間 作業：1週間 結果 無事故・無停止で切り替え作業完了。 EKSバージョンは最新に更新。 意思決定含めてドキュメント化され、 インフラ構築手順の不明点を解消。
34. 技術、プロダクト、メンバーの期限 メンバー プロダクト 技術 初期メンバー 枯れた技術：期限が長い 当たれば長生きする 新しい技術：頻繁に変わる　　　・・・ 転職者 短期で離職 継続 ほとんどが短命・・・ 選ぶ 作る 成長 させる EoL 移行 引き 継ぐ 破壊的 変更 リファクタ リング
35. Kubernetesクラスターを引き継ぐ技術 • Kubernetesをプログラミングする（CRDやKubernetes SDKの使用）場合、開発時に想定している Kubernetes APIバージョンと更新後KubernetesクラスターのAPIバージョンが一致しないことがある。 • 発生する障害： ◦ デプロイできずにエラー ◦ デプロイできるけどPodでエラー ◦ エラーは出ないけど想定外の挙動 • 独自開発したリソースが正しく稼働しているときの状態（Kubernetesとプログラムのログ）を残し、 更新時に同等の状態を保つようにテストする。
36. Kubernetesクラスターを 誰かから引き継ぐ技術
37. 見知らぬKubernetesクラスターを解剖する • クラウドのマネージド Kubernetes（GKE, EKS, AKS）で 作ったクラスターであれば kubectlで接続する権限は クラウドのIAMの設定等から得られるはず。 • 解剖手順 ◦ マニフェストの有無を調べる。 ◦ ネームスペースを調べる。 ◦ デフォルトのネームスペース（ default, kube-system, kube-public等）に配備された リソースを調べる。 ◦ 独自にデプロイされたネームスペースを調べる。 ◦ CRDや管理のためにデプロイされていそうな ネームスペース（ monitoring, network, 等）を 調べる。 ◦ マニフェストがあれば、デプロイされたリソースと比 較する。 GCP IAM GKE Namespace GCE Disk Network GitHub Repository Terraform manifest $ kubectl … $ gcloud … $ terraform … Pod Svc PVC Ingress CRD SA
38. Kubernetesクラスターのリソース管理 • インフラ、中間、アプリケーションで整理。 • インフラ：インフラやクラスター。 ◦ IaCがあれば実態を比較する。 ◦ コンソールからデプロイされている場合はド キュメント化。 • 中間：外部リソースと関連するもの。 ◦ マニフェストがあれば実態と比較する。 ◦ コンソールからデプロイされている場合はド キュメント化。 ◦ PV, Ingress, SA・・・。 • アプリケーション：アプリケーションリソース。 ◦ マニフェストがあれば実態と比較する。 ◦ プログラムや CRDからにデプロイされる。 ◦ Pod, Deploy, Job, Svc・・・。 インフラ 中間 アプリ 各リソースがどこから デプロイされているか 特定する。 GCP IAM GKE Namespace GCE Disk Network Repository TF manifest k8s manifest Pod Svc PVC Ingress CRD SA
39. GCP IAM GKE Namespace GCE Disk Network Repository TF manifest k8s manifest Pod Svc PVC Ingress CRD SA 謎のKubernetesクラスター、 謎のPod、謎のCRD、謎のマニフェスト クラスターやリソースの 作られ方が残っていないことも 少なくない。 CRDの ソース コード 一致 しない 手動で 変更 Docker Imageの ビルド Out Dated
40. GCP IAM GKE Namespace GCE Disk Network Repository TF manifest k8s manifest Pod Svc PVC Ingress CRD SA 謎のKubernetesクラスター、 謎のPod、謎のCRD、謎のマニフェスト CRDの ソース コード 一致 しない 手動で 変更 Docker Imageの ビルド Out Dated ソースコードが あれば自分で ビルドする。 マニフェストが あればdiff。 なければ kubectl get -o yaml マニフェストから 読み解く。 API Deprecationに 気をつけながら アップデート。 kubectl get -o yaml しながらdiffを 解消する。
41. 失われた意思決定を求めて • ないものは作る。これはソフトウェアでも運用ドキュメントでも同じ。 • 引き継ぐときに作る。引き継いだ後だと作るモチベーションが失われる。 • しかし意思決定の理由や文脈は明瞭にドキュメントに残していないと絶対にわからない。
42. 事例. 作った人は退職済みのクラスター EKSクラスター3個。 　本番とステージング 　学習 エンジニア10名。 ただしインフラエンジニアは退職済み。 AWS 学習EKS ステージングEKS 本番EKS
43. 事例. 作った人は退職済みのクラスター AWS 学習 ステージング 本番 Web RDS API Pod API Pod Workflow Pod Job Ingress Ingress AWS Addons AWS Addons AWS Addons GitHub Repository k8s manifest CloudFormation EBS
44. 事例. 作った人は退職済みのクラスター AWS 学習EKS ステージングEKS 本番EKS 調査 EKSクラスターおよび AWSリソースは全て CloudFormationで構築。 リソースはk8s manifestで構築。Kustomizeを使用。 一部AWS Addonsのみコンソールから設定。 独自CRDなし。 プログラムから Podを起動することもなし。 意思決定は全てドキュメント化。 変更履歴はGit Blameで引ける。 引き継ぎ人生初の当たり Kubernetesクラスターと 歓喜する！
45. 深掘り調査 2年ほどクラスターバージョンは未更新。 k8s 1.19。 同様に各種リソースも未更新。 AWS Addonsはコンソールから更新不可能。 Ingress ControllerやCert Manager等マニフェストを 刷新しないと最新バージョンに更新できない。 Webからコピーしたマニフェストのうち、独自に 書き換えた箇所を最新のマニフェストにも適用する 必要があるが、オリジナルのマニフェストや 当時のAPI仕様が不明・・・。 事例. 作った人は退職済みのクラスター AWS 学習EKS ステージングEKS 本番EKS
46. 事例. 作った人は退職済みのクラスター AWS 学習EKS ステージングEKS 本番EKS 出所不明の マニフェストが 定義されたリソース Old Latest 書き換えてあることは わかるけど、 どこを書き換えたのか わからない マニフェスト ソリューション：マニフェストを diffしつつgrepしつつ修正する。
47. 事例. 作った人は退職済みのクラスター AWS 学習 ステージング 本番 Web RDS API Pod API Pod Workflow Pod Job Ingress Ingress AWS Addons AWS Addons AWS Addons GitHub Repository k8s manifest CloudFormation EBS 更新 できない Addons 要更新 マニフェスト 要更新 v1.22で大量にAPI deprecation オリジナルの マニフェストが 不明 24/365 稼働 IAM, SA, Secret, RBAC で ピタゴラスイッチ
48. 事例. 作った人は退職済みのクラスター 計画 v1.19 -> v1.22更新調査： 学習クラスターで検証。 Ingress等のマニフェストは最新版に 更新。既存リソースのパラメータと 矛盾を確認しながら書き換え。 AWS Addonsは既存リソースから マニフェストを出力し、更新。 実行 クラスターバージョン更新ごとにページを 用意し、実行コマンドと ログはすべてドキュメントに残す。 エラーも残す。 1日1クラスター更新とし、利用中の 障害を見落とさない。 計画 更新順：学習、ステージング、本番。 以下の順番で更新： - マニフェスト - クラスターバージョン - ノードバージョン - AWS Addons移行 メンバー 主担当：自分
49. 事例. 作った人は退職済みのクラスター AWS 学習 ステージング 本番 Web RDS API Pod API Pod Workflow Pod Job Ingress Ingress AWS Addons AWS Addons AWS Addons GitHub Repository k8s manifest CloudFormation EBS EBSが 使えない 更新 できない Apply できない マニフェストのApplyは順番が必要な場合がある（依存するリソースの順番にApplyする必要がある）。
50. 事例. 作った人は退職済みのクラスター 期間：合計2ヶ月程度 調査：2週間 検証、ドキュメンテーション、マニフェスト作成： 4週間 作業：2週間 結果 作業中に発生した障害： - kubectl apply がエラーになる。 SA, RBAC, CertMngの所 為。 - EBSを認識しなくなる。 EBS Controllerのバージョンが 不一致。 - AWS Addonsを更新できない。結局 GitHubで公開 されているマニフェストを修正して当てた。 マニフェストは出処の URLをコメントに残す。 自分で修正した箇所はマニフェストにコメントを 残す。
51. 誰かに Kubernetesクラスターを 引き継ぐ技術
52. 将来を見据えて意思決定する、 意思決定を残す、意思決定を覆す • 技術選定はその時点の技術やチーム、プロダクトの文脈によって決まる。 文脈は時間とともに変わるし、技術とチームとプロダクトの時間の早さは違う。 • 意思決定を残す。意思決定には文脈と重要な制約条件を記す。 制約条件が変わっていたらその意思決定は覆して良いことを後世に伝える。 • インフラやコンピューティング基盤そのものの技術選定が現状にそぐわないことがある。 移行できるように作ることが重要。
53. ありがとうございました！ Kubernetesクラスターを引き継ぐ技術