🔥

Kubeflow Notebooksをちょっと理解する

2023/02/09に公開

業務でKubeflow Notebooksを使う機会がありそうなので、基本的な使い方や普通のNotebookと違う点などを調べてみる。ただ、手元にKubeflowの環境が無いため基本的にはドキュメントを要約する形になる。

TL; DR

  • Kubeflow Notebooksはクラスター内に環境を作るため共有がしやすそう
  • Notebookごとに環境を作るが、イメージを工夫することでむしろ再現性が増して良さそう
  • 「コードの管理をどうするの」などの疑問が残った
     (使ってみてどう便利か/不便かが分かったら追記することにしよう)

Kubeflow Notebooks

https://www.kubeflow.org/docs/components/notebooks/overview/

Kubeflow Notebooksは、OSSの機械学習基盤であるKubeflow上でポッドとして立てることが出来るNotebook環境のことだ。ドキュメントに記載されている主な機能は以下の通り。

  • JupyterLab, RStudio, VS Code (code-server)のネイティブサポート
  • クラスター内からのNotebook環境の作成(ユーザが作成可能)
  • 管理者によるNotebook環境のPodイメージの提供
  • KubeflowのRBAC(Role Base Access Control)による権限管理

手元の環境でNotebookを作らなくてよくて、なおかつ、権限管理によってチーム内などのNotebookの共有がやりやすそう。しかも、管理者が基本的な機械学習用ライブラリを含んだイメージを提供できるため、Notebook環境が独立していても毎回環境構築をする手間が省けそう。

ちなみにVS Codeのcode-serverはブラウザでアクセス可能なVS Code環境らしい(普段VS Code使わないから使用感とかは分からない...)

これを見ると、かなりチーム開発がやりやすそうなNotebookだな、と感じた。

実際の画面

https://www.kubeflow.org/docs/components/notebooks/quickstart-guide/

手元に環境がないため、以下はドキュメントをコピペしてるだけ...

初めにログイン画面があるはず。
そこから以下の画面に遷移し、namespaceを選択する。
(namespaceはプロジェクトごとに分けたりするのがいいのだろうか。実践で使ったことがないからまだ分からない。)

次にサイドバーから「Notebook Servers」を選択し、Notebookサーバを立ち上げる。

そのあとは起動オプションを選ぶ。
後述のイメージなどはここで指定できるらしい。カスタムイメージを選ぶ際にはレジストリ、イメージ、タグを指定できるらしい。(権限はどうやって紐づけるんだろう。そういえばArgo WorkflowのときはKubernetesのロールとGCPのサービスアカウントを紐づけられた気がしたな。)

コンテナイメージ

https://www.kubeflow.org/docs/components/notebooks/container-images

用意されたイメージ

主にベースとして使いそうなイメージは下のものだと思う。

Dockerfile 説明 備考
base ベースとなるイメージ。ubuntu20.04をベースに作られており、後述するJupyterLab、RStudio、VS Code(code-server)のベースとなっている。 JupyterLabなどのサポートされているものを使わないのであればこれをベースにするといいかも。
jupyter ベースイメージからJupyterLabをインストールし、デーモンとして起動するイメージ。 これが一番使いそう。
rstudio jupyterのRStudio版。やっていることはRStudioをデーモンとして起動しているので同じ。 Rがいい人はこれを使う...?
code-server 上二つのcode-server版。 どうでもいいことだけど、Dockerfileが短くて見やすい

これ以外に、使う場面の多いライブラリがすでに入っているイメージも用意されている。
めんどくさいので列挙はしないが、下の図のような派生になっている。(jupyterを使う人が多いだろうから、その派生が多めになっている。)

カスタムイメージ

Kubeflow Notebooksの環境はポッド単位で独立しているため、普通に環境を立て直すとライブラリのインストールをやり直す必要がある。だが、それを避けるために二つの手段が用意されている。

  1. ライブラリなどのインストール場所をPVCにする
  2. カスタムイメージの作成

PVC(PersistentVolume)とは永続ボリュームと呼ばれるKubernetesのボリュームの一種だ。
https://kubernetes.io/ja/docs/concepts/storage/persistent-volumes/

一つ目の方法では、PVCにライブラリをインストールすることで、環境を立て直しても同じPVCをマウントすることで再度インストールする手間を省くことが出来る。(dockerのボリュームのマウントと考えると分かりやすい)

二つ目の方法は、必要なライブラリをすべてインストールしたカスタムイメージを作る方法で、以下のページに詳細が書いてある。
https://github.com/kubeflow/kubeflow/tree/master/components/example-notebook-servers#custom-images

やることは単純で、上で挙げたすでに用意されているイメージに追加でライブラリをインストールし、ECRなどにプッシュしておけば多分大丈夫だと思う。(やってみたわけじゃないから確信は持てないが、そもそも上の用意されているイメージもECRに入っているからいける気がする)

あと、カスタムイメージがKubeflow Notebooks上で動くために以下のものは必須らしい。(最後の項目は必要というより、「こういう動きしますよ」ってことだと思う)

  • 8888番ポートで公開(JupyterLab, RStudioなど)
    • 実行時にNB_PREFIXに入ってる値をコンテナURLのプレフィックスとして使う(?)
      (おそらくはデフォルトのままで良さそう...?)
    • HTTPヘッダにAccess-Control-Allow-Origin: *を設定
  • jovyanというユーザで実行する
    • ホームディレクトリは/home/jovyan
    • UIDは1000
  • 初回ポッド起動時に/home/jovyanに空のPVCをマウントする
    • 再起動時は同じPVCがマウントされるため/home/jovyanの状態は保持される

疑問に思ったこと

  • コードの管理はどうするの?

Notebookは分析などがしやすい反面、Gitなどのバージョン管理と相性が悪い問題を抱えている。
差分を見ることが出来るツールなどもあるが、使っているクライアントは人それぞれだと思うのでチーム全員が見やすくないと開発しづらいと思う。しかも、Notebook環境ごとにポッドを立てるのであれば最悪の場合ポッド内のみに保存されてて、気が付いたら消えているなんてこともありそう。

Discussion