PFN の ML/DL 基盤を支える Kubernetes における自動化 DevOpsDays Tokyo 2021 (2021/4/16) SUDA Kazuki (@superbrothers), Preferred Networks, Inc. SAKATA Masao, Preferred Networks, Inc.

SUDA Kazuki / @superbrothers ● Preferred Networks, Inc. (PFN) エンジニア ● Kubernetes Meetup Tokyo, Prometheus Meetup Tokyo ほか、共同主催者 ● Cloud Native Ambassador (Cloud Native Computing Foundation) ● 「Kubernetes実践入門」、「みんなのDocker/Kubernetes」共著書 ● 「入門 Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書 SAKATA Masao ● Preferred Networks, Inc. (PFN) エンジニア ● 2016 年 PFN 入社 ● 社内向け GPU クラスタの開発運用 ○ クラスタをスプレッドシートで運用していた時代から業務に携わる

アウトライン ● PFN の事業を支える GPU クラスタ ● Kubernetes とはなにか ● PFN における Kubernetes クラスタの利用状況 ● クラスタで発生する様々な障害 ● Kubernetes を用いた自動化への取り組み ● オペレーションの自動化を担うソフトウェア ● Kubernetes クラスタの管理自動化の取り組み ● PFN における Cluster API の利用状況 3

PFN の事業を支える GPU クラスタ

5 PFN の事業を支える計算機クラスタ 多種多様な研究 多種多様なデータ 自社開発の技術 大量の機械学習ジョブ 大勢の研究者 オンプレの GPU クラスタ

PFN の計算機クラスタの進化 6 NVIDIA GPUなどの最新技術を採用した プライベート・スーパーコンピュータ MN-2 を自社構築し、7月に稼働 Preferred Networksの深層学習用スーパーコンピュータMN-3、省電力性能の前回記録を23.3%更新

Kubernetes とはなにか

8 Kubernetes（クバネテス） ● コンテナオーケストレーションツール ● 複数のマシン（ノード）で構成されるクラスタに対して コンテナの配備、設定、管理を行う ● κυβερνήτης: ギリシャ語で操舵士 ● Google の社内システムからインスパイアされたオープンソースソフトウェア ● 初期は Google のソフトウェアだったが、その後に Cloud Native Computing Foundation（CNCF）に譲渡され、 現在は CNCF がホストするオープンソースソフトウェア（Apache License 2.0） ● 2015年7月に 1.0.0 をリリース、2021年6月時点の最新バージョンは 1.21

No content

No content

なぜ PFN は Kubernetes を選択したのか • コンテナによる実行環境の再現性/可搬性/隔離性 • セキュリティ・プライバシ機能 が充実 – Namespace, Pod Security Policy (PSP), RBAC, Network Policy • スケジューリングのポリシが柔軟 に設定可能 – Label, Taint, Affinity, PriorityClass • 拡張が柔軟かつ容易 – Device plugin, CustomResourceDefinition (CRD), CRI, CNI – Custom scheduler, Admission webhook • オープンソースソフトウェアかつ巨大なエコシステム – 各種コマンドラインツール、ドキュメント、サンプル、ナレッジベース – コミュニティ 11

PFN での Kubernetes における自動化 ● ML/DL ワークロードな Pod の効率的なスケジューリング ○ プリエンプション（優先度の低い Pod を追い出す） ○ スロットリング（リソース使用の制限） ○ 公平性のあるスケジューリング順序制御 ○ ギャングスケジューリング（Pod の集合を一度にスケジュール） ● クラスタ/ノードの運用/障害対応 12 How to Schedule Machine Learning Workloads Nicely In Kubernetes

PFN における Kubernetes クラスタの利用状況

クラスタの構成概要 データセンター毎に独立の Kubernetes クラスタとして運用 ● MN-1 ○ Master : 3 台 ○ Worker ■ GPU ノード : 168 台 (1344 GPUs) ■ CPU ノード : 22 台 ● MN-2 ○ Master : 3 台 ○ Worker ■ GPU ノード : 128 台 (1024 GPUs) ■ CPU ノード : 22 台 14 ... ...

Kubernetes の構成概要 (MN-1) credits:　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 gpu by Misha Petrishchev, Cpu Chip by Vectors Market, Memory by Jugalbandi, Network Switch by Creaticca Creative Agency, Webhooks by Paul Dietzel, label by nauraicon, schedule by Pixel Lab from the Noun Project 832 (P100) 512 (V100) 56 Gbps x 2 100 Gbps x 2 2576 Core 1792 Core 24 TiB 24 TiB 64 nodes (MN-1b) 104 nodes (MN-1a) (全体では128 node) v1.17.0 NVIDIA/k8s-device-plugin everpeace/k8s-host-device-plugin custom admission webhook custom node feature discovery custom kube -scheduler InfiniBand 15

Kubernetes の構成概要 (MN-2) credits:　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 gpu by Misha Petrishchev, Cpu Chip by Vectors Market, Memory by Jugalbandi, Network Switch by Creaticca Creative Agency, Webhooks by Paul Dietzel, label by nauraicon, schedule by Pixel Lab from the Noun Project 1024 (V100) 100 Gbps x 4 5760 Core 56 TiB 150 nodes v1.20.2 NVIDIA/k8s-device-plugin everpeace/k8s-host-device-plugin custom admission webhook custom node feature discovery custom kube -scheduler Ethernet 16 v1.15.0 絶賛移行中 NEW!!

17 Kubernetes リソースとしての GPU ● Device Plugin Framework ○ ベンダ独自の初期化などが必要なハードウェアを Kubernetes のリソースとして認識させるための フレームワーク ● Nvidia Device Plugin ○ https://github.com/NVIDIA/k8s-device-plugin ○ 各 GPU ノード上で動作 (Daemonset) ○ ノードに搭載された GPU を認識、リソースとして公開 ○ Health Check も行い、問題のある GPU は公開しない ● Pod がリソースとして要求することで、排他的に GPU を利用可能

共有ストレージ PFN では主に以下をユーザーの様々なデータ置き場として利用 ● NFS (Network File System) ○ 全ノードに NFS をマウント ○ Pod はノードのファイルシステム上の NFS パス (hostPath)をマウントして利用 ● HDFS (Hadoop Distributed File System) ○ Pod で HDFS アクセスに必要なクレデンシャル (Secret) をマウント ○ Pod からネットワークを介して HDFS を利用 18

クラスタで発生する様々な障害

障害の例 - ノード ● ノードに Pod を配置できる状態にない ○ kubelet (各ノードで実行される k8s エージェント) が 正常に動作していない ● メモリの空き容量がひっ迫 ● ローカルディスクの空き容量がひっ迫 ● プロセスの大量生成による利用可能な PID のひっ迫 ● 原因 : ユーザーのワークロードによる過負荷、OS の不具合、ネット ワークやノードの障害など、様々な原因が考えられる ● 対応 : kubelet, docker エンジン等のシステム系プロセスの再起動、 もしくはノードの再起動で復旧する場合もある 20

障害の例 - GPU ● 熱や電力供給の問題などの理由により、特定の GPU ボードが利用できない ● GPU メモリで Single Bit ECC Error, Double Bit ECC Error が多発 ● GPU がビジー状態で利用できない ● 原因 : GPU の一時的な状態異常のほか、物理的な故障が原因の場合も ● 対応 : 一時的な状態異常でも多くの場合、復旧にノードの 再起動が必要。物理故障の場合、GPU 交換が必要。 21

障害の例 - ネットワーク ● Pod から通信や名前解決ができない ● ノードのネットワークがリンクダウンしている ● ノードのネットワークアドレスが設定されていない ● ノードの対外（インターネット）ネットワークの輻輳 ● クラスタ間 (MN-1,2間) ネットワークの輻輳 ● 原因 : NIC やケーブルなどハードウェア故障のほか、CNI Plugin の 動作の不具合、設定不備など様々な原因が考えられる ● 対応 : CNI Plugin の再起動や、設定不備の修正で復旧する場合もある が、NIC や スイッチの物理故障は交換対応が必要 22

障害の例 - NFS ● NFS サーバーへの疎通がない ● ノードに NFS がマウントされていない ● 原因 : 過負荷などにより NFS サーバー自体がダウン している場合の他、ネットワークや、クライアントの ノード自体の障害が原因の場合もある ● 対応 : 個々の原因に応じて、NFS サーバーへの負荷の低減、NFS サー バーの再起動、ネットワークやノード自体の障害の復旧といった対応 が必要 23

障害の例 - Pod ● Pod 内のコンテナが再起動を繰り返す ● Pod を削除 (kubectl delete pod) したが、実際にはコンテ ナやプロセスが正常に終了せず、削除できない ● Pod 内のプロセスが D state (Disk I/O 待ちなどの割り込 み不可の Sleep 状態) になったまま、ノードに残存 ● 原因 : 単純な Pod の設定 (Manifest) ミスのほか、ノー ド、GPU、NFS などの障害により、Pod が正常に起動、も しくは終了しないことがある ● 対応 : Pod の設定ミスであれば見直しをユーザーに促す。 インフラ側の障害であればそれを復旧 24

クラスタは常にどこかが壊れている 25

26 クラスタは常にどこかが壊れている 分散システムは、完全な意味で「アップ（up）」になることはない。* ● 障害の発生しうる要素 ○ ハードウェア ■ CPU, GPU, Memory, Disk, Network (NIC, Cable, ...), FAN, 電源,… ○ ソフトウェア ■ OS, ドライバ, システムプロセス (k8s 含む), Pod (ユーザーのワー クロード) , … ● 各要素で障害となりうる故障・不具合の種類も複数存在 ● クラスタの規模に比例して、どこかが壊れているのが定常的な状態 ● 繰り返される定型的な障害の検知と復旧の自動化が必須 * Ops: It's everyone's job now | Opensource.com

Kubernetes を用いた 自動化への取り組み

Kubernetes におけるノードの Condition 28 ● Kubernetes ではノードに Pod が配置可能かどうかなど、ノードの状 態を表す Condition と呼ばれる概念が存在 ● Condition はデフォルトで存在するいくつかのタイプに加えて、独自 に定義することが可能 ● PFN では Node Problem Detector を使い、独自の Condition を定義 し、障害検知に利用している $ kubectl describe node minikube ... Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- NetworkUnavailable False Tue, 13 Apr 2021 ... Tue, 13 Apr 2021 ... CalicoIsUp Calico is running on this node MemoryPressure False Tue, 13 Apr 2021 ... Tue, 13 Apr 2021 ... KubeletHasSufficientMemory kubelet has sufficient memory... DiskPressure False Tue, 13 Apr 2021 ... Tue, 13 Apr 2021 ... KubeletHasNoDiskPressure kubelet has no disk pressure PIDPressure False Tue, 13 Apr 2021 ... Tue, 13 Apr 2021 ... KubeletHasSufficientPID kubelet has sufficient PID ... Ready True Tue, 13 Apr 2021 ... Tue, 13 Apr 2021 ... KubeletReady kubelet is posting ready status

ノード コンディション タイプ ● Ready ○ ノードに Pod を配置できる状態にあるか？ ● MemoryPressure ○ メモリ空き容量がひっ迫していないか？ ● DiskPressure ○ ローカルディスクの空き容量がひっ迫していないか？ ● PIDPressure ○ プロセスの大量生成により、ノードで利用可能な PID がひっ迫し ていないか？ ● NetworkUnavailable ○ ノードのネットワークが適切に設定されているか？ 29

30 PFN での障害検知から復旧までの流れ 1. メトリクス収集 ○ Prometheus と各種 exporter によるメトリクス収集 ○ ノードの Condition も Prometheus でメトリクスとして収集 2. アラート発報 ○ メトリクスが閾値を超えると Alertmanager を介してアラート発報 3. チケット起票 ○ alertmanager-to-github でアラート発報と共に Github イシューを作成 ○ Github 上で自動的に担当者をアサイン 4. 復旧対応 ○ 自動化済みの場合 ■ node-operation-controller で復旧オペレーションを Pod で自動実行 ■ 自動オペレーションに失敗した場合は担当者が手動対応 ○ 手動対応の場合 ■ イシューに対応履歴を残し、知見を蓄積 ■ 定型化できそうなものは自動化を進める

オペレーションの自動化を 担うソフトウェア

Prometheus ● https://github.com/prometheus/prometheus (Apache 2.0) ● クラウドネイティブの世界で事実上の標準となっている メトリクス管理ソリューション ● オープンソースのメトリクスベースモニタリングシステム ○ プル型で単純なテキストのメトリクス形式 ○ 柔軟なクエリ⾔語 ○ サービスディスカバリ機構との連携で動的な環境の モニタリングが得意 ○ ダッシュボードとアラート通知 (Alertmanager) ● 2016年に CNCF の2番⽬のプロジェクトのメンバーに ○ 2018年8⽉に “卒業” (Graduated) プロジェクトとなる ● 既に Prometheus にメトリクスをエクスポートするさまざまな exporter が存在 ○ https://prometheus.io/docs/instrumenting/exporters/ 32

PFN で利用している exporter ● kube-state-metrics ○ https://github.com/kubernetes/kube-state-metrics ○ Kubernetes の様々なオブジェクト (node, pod, ...) のメトリクスをエクスポート ● node exporter ○ https://github.com/prometheus/node_exporter ○ ノードの CPU, メモリ, Disk, Network などの様々なメトリクスを エクスポート ● NVIDIA dcgm-exporter ○ https://github.com/NVIDIA/gpu-monitoring-tools#dcgm-exporter ○ GPU の利用率, 電力消費量, 温度などのメトリクスをエクスポート ● blackbox exporter ○ https://github.com/prometheus/blackbox_exporter ○ 監視対象に対する HTTP, HTTPS, DNS, TCP , ICMP によるシンプルな外形監視に利 用可能 ○ PFN ではネットワークの疎通確認や NFS の死活監視に利用 33

Node Problem Detector (NPD) ● https://github.com/kubernetes/node-problem-detector ● DaemonSet として各ノードで実行し、ノードの問題を検知した場合、 独自の Condition の変更や Event を作成可能 ● 検知方法 ○ システムログモニタ ■ 各種ログファイルを監視 ● filelog プラグイン: 任意のログファイル ● journald プラグイン: journald のログ ● kmsg プラグイン: カーネルログ(/dev/kmsg) ○ カスタムプラグインモニタ ■ custom プラグイン: 任意の監視スクリプトの標準出力と終了 コードで問題を通知する 34

NPD の Custom Plugin (1/2) GPU ● nvidia-smi コマンドで出力されるログをもとに、障害の有無を判断 Pod (プロセス) ● ノード上のプロセスの State (Running, Sleep, Stopped, ...) 、Docker コンテナ、Pod の情報を取得 ● どの Pod のどのプロセスが、どんな State にあるかを監視 ● 削除済みの Pod のプロセスが D state の場合、異常と判断 35 $ nvidia-smi ... Unable to determine the device handle for GPU 0000:1C:00.0: GPU is lost. Reboot the system to recover this GPU

NPD の Custom Plugin (2/2) ネットワーク ● 各ネットワークインターフェースの IP アドレスとリンクの状態を定期 的に監視 NFS ● NFS がマウントされているかの確認 ○ stat コマンドによりマウントポイントのファイルシステムを監視 ● ノードから NFS の死活監視 ○ ping, rpcinfo コマンドにより NFS サーバーへの疎通確認 36

Node Operation Controller (自社開発) ● https://github.com/pfnet-research/node-operation-controller ● ノードの Condition の変化により任意のオペレーションを実⾏ ○ ノードの Condition を監視 ○ 条件を満たすとそのノードのメンテナンス処理を実⾏する Pod を 作成するコントローラ ● PFN では Condition の変更には Node Problem Detector とそれと連携 する内製のツール (custom プラグイン) を使⽤ ● Condition に応じてノードの再起動、NFS のマウントなどの復旧処理 を行う Pod を作成 37

alertmanager-to-github (自社開発) ● https://github.com/pfnet-research/alertmanager-to-github ● Alertmanager からの Webhook を受け取って GitHub イシューを作成 ○ 新しいアラートから GitHub イシューを作成 ○ アラートが resolved ステータスになるとイシューをクローズ ○ アラートが再度 firing ステータスになるとイシューをリオープン 38

kube-janitor (1/2) ● https://codeberg.org/hjacobs/kube-janitor ● Kubernetes のリソース (pod, job, deployment,etc...) を特定の条件で 自動的に削除してくれる OSS ● 条件の指定は Pod に annotation を付与することで行う ● annotation は以下の 2 種類 ○ janitor/ttl : 指定された一定時間経過後に削除 ○ janitor/expires : 指定された日時を過ぎたら削除 39

kube-janitor (2/2) ● PFN では node-exporter, dcgm-exporter のメトリクスから CPU, GPU がアイドル状態の Pod や Pending のままの Pod を検知 ● アラートを独自の webhook で受け、kube-janitor の annotation を付 与し、自動削除に利用 ● 自動削除前に Slack でユーザーに通知 40

Kubernetes クラスタの 管理自動化の取り組み

42 Kubernetes クラスタの管理も自動化したい ワーカノードや Pod の障害や問題への対処は自動化できてきたが、 Kubernetes を使っていくうえでの大きな課題にはクラスタ自体の管理もある！ ● Kubernetes クラスタの管理とは? ○ 実マシンを使ったクラスタを新たに構築したい ○ 検証用に一度のノードをクラスタから外したい ○ 検証が終わったらノードをクラスタに戻したい ○ クラスタをアップグレードしたい！ オンプレミスでもマネージド Kubernetes サービスのようにクラスタの管理をいい感じ にやりたい。そこで Cluster API が使えます。 (そもそもオンプレでのバニラ Kubernetes の使用は相当な覚悟でやってください)

43 Cluster API とは 複数の Kubernetes クラスタの作成やアップグレード、 そのほかクラスタをオペレーションをするための宣言的な API と ツールを提供する SIG Cluster Lifecycle のサブプロジェクト ● Kubernetes クラスタの望ましい状態を宣言的に管理し（マニフェストファイ ル）、Kubernetes コントローラが実際のインフラが望ましい状態と一致するよう に継続的に調整する（Reconcile） たとえば、MySQL Operator は MySQL の作成や削除、管理を自動化してくれる。 Cluster API は Kubernetes クラスタのそういった作業を自動化してくれるので、 「Kubernetes Cluster Operator」ともいえる。

望ましい状態を宣言的に管理するとは 44 apiVersion: cluster.x-k8s.io/v1alpha3 kind: Cluster metadata: name: my-cluster namespace: default spec: clusterNetwork: services: cidrBlocks: ["10.96.0.0/12"] pods: cidrBlocks: ["192.168.0.0/16"] serviceDomain: "cluster.local" controlPlaneRef: apiVersion: controlplane.cluster.x-k8s.io/v1alpha3 kind: KubeadmControlPlane name: controlplane namespace: default infrastructureRef: apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3 kind: DockerCluster name: my-cluster namespace: default apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.19

https://cluster-api.sigs.k8s.io/user/concepts.html

PFN における Cluster API の利用状況

47 PFN における Cluster API の使用状況 ● 2021年4月時点で、1拠点の Kubernetes クラスタを Cluster API により作成したものに移行 ○ Kubernetes バージョン: v1.20.2 ○ Cluster API バージョン: v0.3.14 ● 今後もう1拠点のクラスタも Cluster API に移行予定

データセンタ 48 PFN での Cluster API の構成 Management Cluster (EKS) Cluster API コンポーネント kubeadmControlPlane kubeadmBootstrap MAASInfrastructureProvider Machine Images GitOps (Flux v2) cluster.yaml MAAS API Packer Ansible Playbook CI ゴールデン イメージ Machine Machine Machine Workload Cluster kubectl

現状の課題とその解決案 ➔ マシンのセットアップに時間かかりすぎる ◆ セットアップの大部分をゴールデンイメージに寄せる ◆ ドライバのコンテナによるロード ➔ MachineHealthCheck でマシンの再作成ではなく、再起動させたい ◆ マシンのセットアップにかかる時間を最小化して再作成 ◆ OR 独自の Remediation（修復）を開発 ➔ MachineDeployment のレプリカ数の調整が面倒 ◆ いい感じにやってくれる Kubernetes コントローラを開発 ➔ 狙ったマシンをクラスタから外す手順が面倒 ◆ いい感じにやってくれる Kubernetes コントローラの開発 ➔ ControlPlane ノードのサイズが大きすぎる ◆ VM の導入（KubeVirt？） 49

まとめ

まとめ（1/2） ● PFN での Kubernetes における自動化 ○ ML/DL 向けの効率的なスケジューリングを実現する カスタムスケジューラ ○ クラスタ/ノードの運用/障害対応を自動化するコントローラ ● クラスタで発生する様々な障害 ○ クラスタは常にどこかが壊れている ● Kubernetes を用いた自動化への取り組み ○ Node Problem Detector (NPD) を使い、独自の Condition を 定義、障害検知に利用 51

まとめ（2/2） ● オペレーションの自動化を担うソフトウェア ○ Prometheus と exporter、NPD のカスタムプラグインを多用 ○ alertmanager-to-github: アラートから GitHub イシューを 作成して管理 ○ kube-janitor: 特定の条件を満たすリソースを自動的に削除 ● Kubernetes クラスタの管理自動化の取り組み ○ Cluster API を使うとクラスタをマニフェストとして管理できる ● PFN における Cluster API の利用状況 ○ 1拠点で Cluster API を利用したクラスタに（ほぼ）移行 ○ MAAS をインフラストラクチャとして使用したプロバイダを開発 ○ 様々な課題がみえているので、今後それらの解決に取り組む 52

Thanks / Question? ● SUDA Kazuki (@superbrothers）、SAKATA Masao ● スライド: https://www.slideshare.net/pfi 53