Knitfab v1.3.0 をリリースしました
皆さんこんにちは。技術創発推進室の高岡です。
私達が開発している MLOps ツール “Knitfab” の最新バージョン v1.3.0 を、9月13日にリリースしました。この記事では、v1.3.0 での変更点についてご紹介します。
新機能: カスタムな Data インポート機構の追加
これまで Knitfab に Data を登録する方法は、「アップロードする」か「Run の出力として得る」か、の 2 種類しかありませんでした。v1.3.0 では、アドバンスドなユーザ向けの機能として、ユーザ側の必要に応じて Data 登録の方法を拡張できるようにする仕組みを追加します。これは、任意の Kubernetes PersistentVolume を Knitfab に Data として登録できるようにするものです。
これによって、たとえば「Amazon S3 にあるファイルを Knitfab に使わせる」とか「NFS 上にすでに存在しているファイルを、アップロードすることなく Knitfab に使わせる」とかいった機能を、ユーザ側で追加開発できるようになります。
このために、Knitfab の”バックエンドWebAPI”に以下のAPIが追加されました。
POST http://knitd_backned/api/backend/data/import/begin: インポートの開始を Knitfab に通知する
POST http://knitd_backend/api/backend/data/import/end: インポートの完了を Knitfab に通知する
バックエンドWebAPI とは、通常の Knitfab WebAPI とは異なり、Knitfab がデプロイされている Kubernetes クラスタの内側でのみ利用可能な WebAPI です。同一クラスタ・同一 Namespace 内であれば、通常は knitd_backend というホスト名でアクセスできます。
この新機構を用いた Data インポートは次の手順で行います。
POST /api/backend/data/import/begin に空のHTTPリクエストを送ります。
レスポンスとして JSON Web Token (JWT) が返されます。
返された JWT から、sub クレームを読み取ります。
この sub クレームは、Knitfab がデータインポート用に振り出した PersistentVolumeClaim(PVC) の名前です。
JWT の署名検証用の証明書は Knitfab は公開しないので、検証することなくクレームを読み取ってください。
sub クレームに指定された名前の PVC と、インポートしたい Data 内容を保持している PersistentVolume(PV) を Kubernetes 上に作成し、両者を Bind します。
POST /api/backend/data/import/end に、手順1. で受け取った JWT を送り返します。
JWT を受け取ってからおよそ 30 分以内にこの終了リクエストを送る必要があります。
インポートに成功すれば、成功(200)レスポンスとして登録された Data の情報が返されます。
手順 3. において、PV を作成する方法については制約がないので、任意の内容の PV を構成して Knitfab に自由な手法で Data を登録できる、というわけです。
実際にカスタムなインポート手順を Knitfab 拡張としてデプロイする際には、上記の手順をプログラムして、 Web サーバとして実装し、コンテナイメージにパッケージして、Knitfab と同じ Namespace に (Deployment などを介して) Pod としてデプロイし、Knitfab の拡張 WebAPI として公開するとよいでしょう。また、その拡張 WebAPI のクライアントは、CLI knit の拡張コマンドとして実装できます。
バグ修正など
インストーラについて
installer.sh --prepare を繰り返し行ったとき、一部設定ファイルの内容がリフレッシュされるのではなくて、リフレッシュすべき内容が元のファイルに追記される、という現象がありました。リフレッシュするように修正しました。
インストーラを実行した際の条件によって、正常に機能しないアンインストーラが生成されることがありました。修正しました。
インストーラのメッセージ中の誤字を修正しました。
Data Agent や Run Worker について
これらは Knitfab が必要に応じて自動的に起動する Pod ですが、 これらの Pod が Node にスケジュールされたあとで正常に起動できないことがわかることがあります(たとえば、NFS を背景にした PVC をマウントしようとしているが、NFS 側には PVC が参照しているディレクトリが存在しなくなってしまっている、というケースがこれです)。このような「スケジュールされたが、開始できない」Data Agent や Worker を検出して、停止させるようにしました。
停止させられた Worker の上で実行されていた Run は、失敗します。実行可能な条件を整えて knit run retry してください。
データベースについて:
これまで、Knitfab をアップグレードする際に、稀にデータベースが破損することがありました。これは、アップグレード前のデータベース Pod が終了する前に新しい データベース Pod が起動してしまい、データベースファイル操作が競合することに原因があるようです。アップグレード時には、データベースは古い方を終了してから新しい方が起動するようにしました。
knit data find:
処理中の Data が検索結果に上がってこない、という不具合がありました。修正しました。
その他の変更
Go コンパイラのバージョンを v1.23.1 にアップグレードしました、
admin-guide を 2 つのパートに分割しました。
“installation” 編: Knitfab をインストールする手順について述べています。
“deep-dive” 編: Knitfab の運用や拡張に関するトピックを扱っています。
おわりに
以上、v1.3.0 の変更点をご紹介しました。詳細な内容や更新手順、最新版の CLI などは、GitHub のリリースページからアクセスできます。
今後とも Knitfab をよろしくお願いします。
この記事が気に入ったらサポートをしてみませんか?