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

Slide 1

Slide 1 text

Kubernetesクラスターを引き継ぐ技術 2023/12/12 しぶい

Slide 2

Slide 2 text

自己紹介 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

Slide 3

Slide 3 text

● 発売中！ ● https://www.amazon.co.jp/dp/4798173401/ ● https://github.com/shibuiwilliam/building-ml-system ● 発売中！ ● https://www.amazon.co.jp/dp/4798169447/

Slide 4

Slide 4 text

技術評論社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についてあまり他では取り上げられないようなテーマを中心に記事を書いています！

Slide 5

Slide 5 text

本日の目次 ● インフラ基盤の技術選定 ● 技術、プロダクト、メンバー ● Kubernetesクラスターを誰かから引き継ぐ技術 ● 誰かにKubernetesクラスターを引き継ぐ技術

Slide 6

Slide 6 text

インフラ基盤の技術選定

Slide 7

Slide 7 text

コンピューティング基盤の歴史概略と私 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個）

Slide 8

Slide 8 text

数年おきにトレンドの変わるインフラ技術クラウドの登場以降、コンピューティング基盤のトレンドは数年おきに地殻変動が起こっている。ここ数年のトレンド： - サーバレス(AWS Lambda) - コンテナオーケストレーション (Kubernetes) - Kubernetes的なサーバレス (CloudRunやApp Runner) 物理や仮想マシンから離れ、 Dockerに代表されるコンテナをベースとした開発が定着。 DockerイメージやIaCを非インフラエンジニアが開発することが増えている。・・・次の地殻変動は？

Slide 9

Slide 9 text

● 一度選定したインフラをやり直すことは難しいが、決めないとプロダクト開発が進まない。 ● プロダクトの起ち上げ期： PMFを目指すため早急に PDCAを回し始めたい。 ● プロダクトの成長期：増え続けるトラフィックと機能に対応する基盤が必要。 ● 技術選定は常にギャンブル。当てる努力は重要だが、当たらなくても誰かを責めるものではない。 ● それでも、初期に誰かが作った Kubernetesクラスターを運営しないとプロダクトが止まることも事実。今日も誰かがKubernetesクラスターを作る市場調査買い手を探す作りつつ採用 MVPを作るビジネスモデル化 PoCと改修方向性を模索拡張性を検討どのタイミングでインフラを選定する？・・・

Slide 10

Slide 10 text

選定のタイミング市場調査買い手を探す作りつつ採用 MVPを作るビジネスモデル化 PoCと改修方向性を模索拡張性を検討どのタイミングでインフラを選定する？・・・枯れたor手慣れたインフラならここプロダクトの規模を鑑みて選定できる移行が必要になるが、手堅い選定が可能技術的チャレンジのタイミングは？

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

AWS 事例. 技術的チャレンジのKubernetes ECS Fargate （メインインフラ） EKS on Fargate S3 ALB Cloud Formation WebUI Pod データ Job GitHub Repository データ Job データ Job データ Job データ Job データ Pod Python Kubernetes 仕組みはコードを読めばわかる技術選定はコードを読んでもわからない

Slide 14

Slide 14 text

事例. 技術的チャレンジのKubernetes ● 意思決定 ○ EKS on FargateはEKSに移行する。 ○ コードは変更しない。 PythonからKubernetesリソースを起動する箇所は維持。 ○ インフラだけ刷新して、業務ロジックは変更しない。

Slide 15

Slide 15 text

事例. 技術的チャレンジのKubernetes 計画移行方法：EKS on FargateはEKSに作り直す。作り方：インフラはマニフェストを定義し、eksctlからデプロイ。関連リソースはCloudFormationに寄せる。実行作業はダブルチェックしつつ、録画。可能な限りGitHubにIssueとPRで記録する。 JobとPodの監視を追加し、不要なリソースを検知。レビュー移行手順：EKS on Fargateを EKSクラスターに移行する作業手順。 eksctlの使い方ドキュメント。意思決定：今回の技術選定の背景を説明。今後改めて意思決定するときに参考する。メンバー主担当：自分ダブルチェック：チームリーダー

Slide 16

Slide 16 text

事例. 技術的チャレンジのKubernetes 期間：合計1ヶ月程度調査：1週間検証、ドキュメンテーション： 2週間作業：1日結果データの破損なく EKS on FargateからEKSに移行。 ECS Fargateに移行したかったが、ロジックが Kubernetesに依存していたため断念。 1年ほどEKSクラスターを運用。

Slide 17

Slide 17 text

塩漬けクラスター引き継ぎ&移行課題運用されていないKubernetesクラスターはクラスターバージョンやノードバージョンが更新されていないことが多い。対策クラスターリソースを調査し、可能な限り最新バージョンに更新する。アクション ● クラスターリソースの調査 ● Out datedなAPIやリソース、マニフェストの更新 ● クラスターバージョンおよびノードバージョンの更新 ● ここまでの作業を記録に残す Workaround ● 工数があれば、このタイミングでKubernetesクラスターを他のインフラに移行することも検討する。

Slide 18

Slide 18 text

技術的チャレンジの意義 ● 技術的チャレンジのメリット ○ 新しい技術は使ってみないと有用性がわからない。 ○ エンジニアの学習機会や楽しみ。 ● デメリット ○ 作っただけで終わることがある。 ○ 新しい技術が継続されるとは限らない。 ○ なぜその技術が選ばれたのか、なぜそう作ったのか、「技術的チャレンジ」以外の理由がない。 ● 作るだけならWhatとHowがあれば良いが、運用するためには Whyが必要。

Slide 19

Slide 19 text

Kubernetesクラスターを引き継ぐ技術 ● 引き継ぐときに意思決定を明確にする。 ● インフラの要件と、業務ロジックのためのインフラを分けて整理する。 ○ インフラ要件：コンテナを動かす。 ○ 業務ロジックのためのインフラ：ユーザの操作に対してコンテナを動的に起動する。 ● これらの選定背景をドキュメントに残す。

Slide 20

Slide 20 text

技術、プロダクト、メンバー

Slide 21

Slide 21 text

プロダクトと技術の寿命 ● プロダクトの寿命ビジネスの終了、会社の閉鎖。 ● 技術の寿命ライブラリやモジュール、OSのEoS。メジャーバージョンアップによる破壊的変更で短期的に生まれ変わることもある。メンテナ不在になるライブラリもある。 ● 失敗するプロダクトはプロダクトの寿命＜技術の寿命成功するプロダクトは技術の寿命＜プロダクトの寿命 ● 新しい技術は破壊的変更が頻繁。 ○ AI系のライブラリ ○ コンテナやKubernetes （最近落ち着いてきたけど・・・） ● プロダクトの寿命よりも技術が先に寿命を迎えたら、プロダクトは移行・更新・終了する必要がある。

Slide 22

Slide 22 text

● フロントエンドに限らず、開発頻度が高い技術だと寿命が短いものが多い傾向。 ● コンテナ黎明期に登場した各種基盤（Docker Swarm、Mesos、Cloud Foundry・・・）も同様に寿命が短かった覚えがある。 ● AIは未だに短いものが多々ある。

Slide 23

Slide 23 text

技術、プロダクト、メンバーの期限メンバープロダクト技術初期メンバー枯れた技術：期限が長い当たれば長生きする新しい技術：頻繁に変わる　　　・・・転職者短期で離職継続ほとんどが短命・・・

Slide 24

Slide 24 text

事例. 技術、プロダクト、チームの時間軸当初は5クラスターを最大16名で運営。機械学習のための学習、推論基盤（CRD）が稼働。学習クラスター2個：GKEとEKS 推論クラスター3個：開発、ステージング、本番 GKE EKS 学習学習推論開発推論ステージング推論本番理想：担当チームを分けつつ全体で運営

Slide 25

Slide 25 text

事例. 技術、プロダクト、チームの時間軸チーム再編成、異動、退職により、メンバーが散り散りになる。唯一チーム横断でEM（自分）がクラスター管理者になる。 GPUを使ったEKSクラスターが残る。 GKE EKS 学習学習推論開発推論ステージング推論本番現実：EMが運営

Slide 26

Slide 26 text

事例. 技術、プロダクト、チームの時間軸 ● 課題 ○ EKSクラスターは2018年のEKSリリース初期に作られたもの。 ○ CloudFormation、TerraformによるIaCはない。eksctlで構築されたものでもない。コンソールからクラスターをデプロイ。 ○ ドキュメントなし。マニフェストは管理されているが、主なリソースはCRDから起動。 ○ 稼働しているのは機械学習の学習パイプライン。自作CRD（開発者は退職済み）で、GolangバージョンもKubernetes APIバージョンも 2018年以前のもの。 ○ EKSクラスターおよびノードはデプロイ以降、バージョン更新されず。 ○ 2020年中旬にクラスターバージョンのEoSが迫っている・・・！

Slide 27

Slide 27 text

事例. 技術、プロダクト、チームの時間軸 AWS IAM EKS Namespace EC2 GPU Disk VPC Repository k8s manifest Pod PVC CRD S3 コンソールから構築 Out dated 4種類の定期ジョブ Out dated

Slide 28

Slide 28 text

技術やプロダクト First Penguine 急増！淘汰… 生き残りこのタイミングで独自開発しすぎると・・・ Winner takes allで独自プロダクトが負ける

Slide 29

Slide 29 text

事例. 技術、プロダクト、チームの時間軸事業調査メンテナンス：メンテナンス停止しても問題ない。メンテナンスは時間を決めて 2時間以内に完了する必要あり。月初、週初めは NG。クラスター調査 eksctl：最初からeksctlで構築する必要あり。 kubectl：使用可能。リソース: CRDが動的にデプロイ。 GPU インスタンスを使用。 CuDA/CuDNNバージョンが古い。 CRD調査ソースコード：CRDはGitHubのコミットハッシュで遡れる。 CRD 機能：機械学習パイプラインを定義し、ジョブを起動。

Slide 30

Slide 30 text

事例. 技術、プロダクト、チームの時間軸 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

Slide 31

Slide 31 text

事例. 技術、プロダクト、チームの時間軸 CRD Operator Custom Resource watch reconcile control ここで作られるリソースと・・・ Podのログを残すここを変更することで・・・正常系を知るために

Slide 32

Slide 32 text

事例. 技術、プロダクト、チームの時間軸計画移行方法：更新するのではなく、クラスターを作り直す。作り方：インフラはマニフェストを定義し、eksctlからデプロイ。 CRDはバージョン更新のみ。実行 6月中旬の水曜日午後に実施。作業はダブルチェックし録画。コマンドとログを記録に残す。レビュー移行手順：既存クラスターを新クラスターに移行する作業手順。 eksctlの使い方ドキュメント。意思決定：今回の技術選定の背景を説明。今後改めて意思決定するときに参考する。メンバー主担当：自分レビュー：各チームのTL ダブルチェック：TL

Slide 33

Slide 33 text

事例. 技術、プロダクト、チームの時間軸期間：合計1ヶ月程度調査：1週間検証、ドキュメンテーション： 2週間作業：1週間結果無事故・無停止で切り替え作業完了。 EKSバージョンは最新に更新。意思決定含めてドキュメント化され、インフラ構築手順の不明点を解消。

Slide 34

Slide 34 text

技術、プロダクト、メンバーの期限メンバープロダクト技術初期メンバー枯れた技術：期限が長い当たれば長生きする新しい技術：頻繁に変わる　　　・・・転職者短期で離職継続ほとんどが短命・・・選ぶ作る成長させる EoL 移行引き継ぐ破壊的変更リファクタリング

Slide 35

Slide 35 text

Kubernetesクラスターを引き継ぐ技術 ● Kubernetesをプログラミングする（CRDやKubernetes SDKの使用）場合、開発時に想定している Kubernetes APIバージョンと更新後KubernetesクラスターのAPIバージョンが一致しないことがある。 ● 発生する障害： ○ デプロイできずにエラー ○ デプロイできるけどPodでエラー ○ エラーは出ないけど想定外の挙動 ● 独自開発したリソースが正しく稼働しているときの状態（Kubernetesとプログラムのログ）を残し、更新時に同等の状態を保つようにテストする。

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

見知らぬ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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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を解消する。

Slide 41

Slide 41 text

失われた意思決定を求めて ● ないものは作る。これはソフトウェアでも運用ドキュメントでも同じ。 ● 引き継ぐときに作る。引き継いだ後だと作るモチベーションが失われる。 ● しかし意思決定の理由や文脈は明瞭にドキュメントに残していないと絶対にわからない。

Slide 42

Slide 42 text

事例. 作った人は退職済みのクラスター EKSクラスター3個。　本番とステージング　学習エンジニア10名。ただしインフラエンジニアは退職済み。 AWS 学習EKS ステージングEKS 本番EKS

Slide 43

Slide 43 text

事例. 作った人は退職済みのクラスター AWS 学習ステージング本番 Web RDS API Pod API Pod Workflow Pod Job Ingress Ingress AWS Addons AWS Addons AWS Addons GitHub Repository k8s manifest CloudFormation EBS

Slide 44

Slide 44 text

事例. 作った人は退職済みのクラスター AWS 学習EKS ステージングEKS 本番EKS 調査 EKSクラスターおよび AWSリソースは全て CloudFormationで構築。リソースはk8s manifestで構築。Kustomizeを使用。一部AWS Addonsのみコンソールから設定。独自CRDなし。プログラムから Podを起動することもなし。意思決定は全てドキュメント化。変更履歴はGit Blameで引ける。引き継ぎ人生初の当たり Kubernetesクラスターと歓喜する！

Slide 45

Slide 45 text

深掘り調査 2年ほどクラスターバージョンは未更新。 k8s 1.19。同様に各種リソースも未更新。 AWS Addonsはコンソールから更新不可能。 Ingress ControllerやCert Manager等マニフェストを刷新しないと最新バージョンに更新できない。 Webからコピーしたマニフェストのうち、独自に書き換えた箇所を最新のマニフェストにも適用する必要があるが、オリジナルのマニフェストや当時のAPI仕様が不明・・・。事例. 作った人は退職済みのクラスター AWS 学習EKS ステージングEKS 本番EKS

Slide 46

Slide 46 text

事例. 作った人は退職済みのクラスター AWS 学習EKS ステージングEKS 本番EKS 出所不明のマニフェストが定義されたリソース Old Latest 書き換えてあることはわかるけど、どこを書き換えたのかわからないマニフェストソリューション：マニフェストを diffしつつgrepしつつ修正する。

Slide 47

Slide 47 text

事例. 作った人は退職済みのクラスター 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 でピタゴラスイッチ

Slide 48

Slide 48 text

事例. 作った人は退職済みのクラスター計画 v1.19 -> v1.22更新調査：学習クラスターで検証。 Ingress等のマニフェストは最新版に更新。既存リソースのパラメータと矛盾を確認しながら書き換え。 AWS Addonsは既存リソースからマニフェストを出力し、更新。実行クラスターバージョン更新ごとにページを用意し、実行コマンドとログはすべてドキュメントに残す。エラーも残す。 1日1クラスター更新とし、利用中の障害を見落とさない。計画更新順：学習、ステージング、本番。以下の順番で更新： - マニフェスト - クラスターバージョン - ノードバージョン - AWS Addons移行メンバー主担当：自分

Slide 49

Slide 49 text

事例. 作った人は退職済みのクラスター 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する必要がある）。

Slide 50

Slide 50 text

事例. 作った人は退職済みのクラスター期間：合計2ヶ月程度調査：2週間検証、ドキュメンテーション、マニフェスト作成： 4週間作業：2週間結果作業中に発生した障害： - kubectl apply がエラーになる。 SA, RBAC, CertMngの所為。 - EBSを認識しなくなる。 EBS Controllerのバージョンが不一致。 - AWS Addonsを更新できない。結局 GitHubで公開されているマニフェストを修正して当てた。マニフェストは出処の URLをコメントに残す。自分で修正した箇所はマニフェストにコメントを残す。

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

将来を見据えて意思決定する、意思決定を残す、意思決定を覆す ● 技術選定はその時点の技術やチーム、プロダクトの文脈によって決まる。文脈は時間とともに変わるし、技術とチームとプロダクトの時間の早さは違う。 ● 意思決定を残す。意思決定には文脈と重要な制約条件を記す。制約条件が変わっていたらその意思決定は覆して良いことを後世に伝える。 ● インフラやコンピューティング基盤そのものの技術選定が現状にそぐわないことがある。移行できるように作ることが重要。

Slide 53

Slide 53 text

ありがとうございました！ Kubernetesクラスターを引き継ぐ技術