ホーム » Kubeflow

Kubeflow」カテゴリーアーカイブ

Kubeflow 1.0 : パイプライン : パイプラインの理解 : Kubeflow パイプラインの概要

Kubeflow 1.0 : パイプライン : パイプラインの理解 : Kubeflow パイプラインの概要 (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/13/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

 

パイプライン : パイプラインの理解 : Kubeflow パイプラインの概要

Kubeflow は Docker コンテナをベースに可搬な、スケーラブルな機械学習 (ML) ワークフローを構築して配備するためのプラットフォームです。

 

Kubeflow パイプラインとは何でしょう?

Kubeflow パイプライン・プラットフォームは以下から成ります :

  • 実験、ジョブと実行を管理して追跡するためのユーザインターフェイス (UI)。
  • マルチステップ ML ワークフローをスケジュールするためのエンジン。
  • パイプラインとコンポーネントを定義して操作するための SDK。
  • SDK を使用してシステムと相互作用するためのノートブック。

以下は Kubeflow パイプラインの目標です :

  • End-to-end orchestration: 機械学習パイプラインの編成を有効にして単純化します。
  • Easy experimentation: 多数のアイデアとテクニックを試して様々なトライアル/実験を管理することを容易にします。
  • Easy re-use: end-to-end ソリューションを素早く作成するために毎回再構築しなければならないことなく、コンポーネントとパイプラインを再利用することを可能にします。

Kubeflow パイプラインは Kubeflow の中心的なコンポーネントあるいはスタンドアロン・インストールとして利用可能です。

 

パイプラインとは何でしょう?

パイプラインはワークフローの総てのコンポーネントを含む ML ワークフローとそれらがグラフの形式でどのように組み合わされるかの記述です。(パイプラインのグラフのサンプルを示す下のスクリーンショットを見てください。) パイプラインはパイプラインを実行するために必要な入力 (パラメータ) と各コンポーネントの入力と出力の定義を含みます。

貴方のパイプラインを開発後、Kubeflow パイプライに UI 上それをアップロードして共有できます。

パイプラインコンポーネントはパイプラインの 1 ステップを遂行する、Docker イメージ としてパッケージ化された、ユーザコードの自己充足的な (= self-contained) セットです。例えば、コンポーネントはデータ前処理、データ変換、モデル訓練等々の責任を負うことができます。

パイプラインコンポーネント への概念ガイドを見てください。

 

パイプラインのサンプル

下のスクリーンショットとコードは xgboost-training-cm.py を示します、これは CSV フォーマットの構造化データを使用して XGBoost モデルを作成します。Github 上でパイプラインについてのソースコードと他の情報を見ることができます。

 

パイプラインのランタイム実行グラフ

下のスクリーンショットはサンプル・パイプラインの Kubeflow パイプライン UI のランタイム実行グラフを示します :

 

パイプラインを表す Python コード

下は xgboost-training-cm.py パイプラインを定義する Python コードからの抜粋です。GitHub で full コードを見ることができます。

@dsl.pipeline(
    name='XGBoost Trainer',
    description='A trainer that does end-to-end distributed training for XGBoost models.'
)
def xgb_train_pipeline(
    output='gs://your-gcs-bucket',
    project='your-gcp-project',
    cluster_name='xgb-%s' % dsl.RUN_ID_PLACEHOLDER,
    region='us-central1',
    train_data='gs://ml-pipeline-playground/sfpd/train.csv',
    eval_data='gs://ml-pipeline-playground/sfpd/eval.csv',
    schema='gs://ml-pipeline-playground/sfpd/schema.json',
    target='resolution',
    rounds=200,
    workers=2,
    true_label='ACTION',
):
    output_template = str(output) + '/' + dsl.RUN_ID_PLACEHOLDER + '/data'

    # Current GCP pyspark/spark op do not provide outputs as return values, instead,
    # we need to use strings to pass the uri around.
    analyze_output = output_template
    transform_output_train = os.path.join(output_template, 'train', 'part-*')
    transform_output_eval = os.path.join(output_template, 'eval', 'part-*')
    train_output = os.path.join(output_template, 'train_output')
    predict_output = os.path.join(output_template, 'predict_output')

    with dsl.ExitHandler(exit_op=dataproc_delete_cluster_op(
        project_id=project,
        region=region,
        name=cluster_name
    )):
        _create_cluster_op = dataproc_create_cluster_op(
            project_id=project,
            region=region,
            name=cluster_name,
            initialization_actions=[
              os.path.join(_PYSRC_PREFIX,
                           'initialization_actions.sh'),
            ],
            image_version='1.2'
        )

        _analyze_op = dataproc_analyze_op(
            project=project,
            region=region,
            cluster_name=cluster_name,
            schema=schema,
            train_data=train_data,
            output=output_template
        ).after(_create_cluster_op).set_display_name('Analyzer')

        _transform_op = dataproc_transform_op(
            project=project,
            region=region,
            cluster_name=cluster_name,
            train_data=train_data,
            eval_data=eval_data,
            target=target,
            analysis=analyze_output,
            output=output_template
        ).after(_analyze_op).set_display_name('Transformer')

        _train_op = dataproc_train_op(
            project=project,
            region=region,
            cluster_name=cluster_name,
            train_data=transform_output_train,
            eval_data=transform_output_eval,
            target=target,
            analysis=analyze_output,
            workers=workers,
            rounds=rounds,
            output=train_output
        ).after(_transform_op).set_display_name('Trainer')

        _predict_op = dataproc_predict_op(
            project=project,
            region=region,
            cluster_name=cluster_name,
            data=transform_output_eval,
            model=train_output,
            target=target,
            analysis=analyze_output,
            output=predict_output
        ).after(_train_op).set_display_name('Predictor')

        _cm_op = confusion_matrix_op(
            predictions=os.path.join(predict_output, 'part-*.csv'),
            output_dir=output_template
        ).after(_predict_op)

        _roc_op = roc_op(
            predictions_dir=os.path.join(predict_output, 'part-*.csv'),
            true_class=true_label,
            true_score_column=true_label,
            output_dir=output_template
        ).after(_predict_op)

    dsl.get_pipeline_conf().add_op_transformer(
        gcp.use_gcp_secret('user-gcp-sa'))

 

Kubeflow パイプライン UI 上のパイプライン入力データ

下の部分的なスクリーンショットはパイプラインの実行を始めるための Kubeflow パイプライン UI を示します。貴方のコードのパイプライン定義はどのパラメータが UI フォームに現れるかを決定します。パイプライン定義はまたパラメータのためのデフォルト値を設定できます :

 

パイプラインからの出力

以下のスクリーンショットは Kubeflow パイプライン UI 上可視なパイプライン出力のサンプルを示します。

予測結果 :

混同行列 :

Receiver operating characteristics (ROC) カーブ:

 

アーキテクチャ概要

高位では、パイプラインの実行は以下のように進みます :

  • Python SDK: Kubeflow パイプライン・ドメイン固有言語 (DSL) を使用してコンポーネントを作成したりパイプラインを指定します。
  • DSL コンパイラ: DSL コンパイラ はパイプラインの Python コードを静的 configuration (YAML) に変換します。
  • パイプライン・サービス: 静的 configuration からパイプライン実行を作成するためにパイプライン・サービスを呼び出します。
  • Kubernetes リソース: パイプラインを実行するために必要な Kubernetes リソース ( CRD ) を作成するために Kubernetes API サーバを呼び出します。
  • Orchestration コントローラ: orchestration コントローラのセットはパイプラインを完了するために必要なコンテナを実行します。コンテナは仮想マシン上の Kubernetes ポッド内で実行されます。サンプル・コントローラは Argo ワークフロー コントローラで、これはタスク駆動のワークフローを編成します。
  • Artifact ストレージ: ポッドは 2 つの種類のデータをストアします :
    • Metadata: 実験、ジョブ、パイプライン実行、そして単一スカラー・メトリクス。メトリックデータはソートとフィルタリングの目的で集積されます。Kubeflow パイプラインは MySQL データベースにメタデータをストアします。
    • Artifacts: パイプライン・パッケージ、ビュー、そして巨大スケール・メトリクス (時系列)。パイプライン実行をデバッグしたり個々の実行のパフォーマンスを調べたりするために巨大スケール・メトリクスを使用します。Kubeflow パイプラインは artifact を Minio サーバCloud ストレージ のような artifact ストアにストアします。

    MySQL データベースと Minio サーバは両者とも Kubernetes PersistentVolume サブシステムにバックアップされます。

  • Persistence エージェントと ML メタデータ: パイプライン Persistence Agent はパイプライン・サービスにより作成された Kubernetes リソースを監視してそしてこれらのリソースの状態を ML メタデータ・サービスに永続化します。パイプライン Persistence エージェントは実行されたコンテナのセットとそれらの入力と出力を記録します。入力/出力はコンテナ・パラメータかデータ artifacts URI から成ります。
  • Pipeline web サーバ: パイプライン web サーバは関連ビューを表示するために様々なサービスからデータを集めます : 現在実行中のパイプラインのリスト、パイプライン実行の履歴、データ artifacts のリスト、個々のパイプライン実行についてのデバッグ情報、個々のパイプラインについての実行ステータス。
 

以上






Kubeflow 1.0 : パイプライン : クイックスタート

Kubeflow 1.0 : パイプライン : クイックスタート (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/13/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

パイプライン : クイックスタート

Kubeflow パイプラインで単純なパイプラインを素早く実行させることを望むのであればこのガイドを利用してください。

  • このクイックスタート・ガイドは、Kubeflow パイプライン・インストールに付随しそして Kubeflow パイプライン・ユーザインターフェイス (UI) で可視のサンプルの一つをどのように使用するかを示します。このガイドを Kubeflow パイプライン UI へのイントロダクションとして利用できます。
  • end-to-end チュートリアルはどのようにパイプラインを準備してコンパイルし、それを Kubeflow パイプラインにアップロードしてからそれを実行するかを示します。

 

Kubeflow を配備してパイプライン UI をオープンする

Kubeflow を配備してパイプライン・ダッシュボードをオープンするにはこれらのステップに従います :

  1. deploying Kubeflow on GCP へのガイドに従います。

    kubeflow/pipelines#1700 のため、Kubeflow パイプラインのコンテナ・ビルダーは Google Cloud Platform (GCP) のためだけにクレデンシャルを準備します。その結果、コンテナ・ビルダーは Google Container Registry だけをサポートします。けれども、イメージを得るために正しくクレデンシャルをセットアップしているとすれば、コンテナイメージを他のレジストリにストアできます。

  2. Kubeflow が実行されているとき、セットアップガイドで説明されているように、形式 https://<deployment-name>.endpoints.<project>.cloud.goog/ の URL で Kubeflow UI にアクセスしてください。Kubeflow UI はこのように見えます :
     

    Kubeflow を配備するとき Cloud IAP オプションをスキップしたか、Kubeflow エンドポイントをまだセットアップしていない場合には、kubectl とポートフォワーディングを通して Kubeflow にアクセスできます :

    1. kabectl をインストールしてください、まだそれを行なっていないのであれば、コマンドラインで次のコマンドを実行することによって : gcloud components install kubectl. より多くの情報については、kubectl ドキュメント を見てください。
    2. “kubectl port-forward -n kubeflow svc/ml-pipeline-ui 8080:80” を実行して http://localhost:8080/ に進んでください。
  3. パイプライン UI にアクセスするには “Pipelines” をクリックしてください。パイプライン UI はこのように見えます :

 

基本的なパイプラインを実行する

パイプライン UI はパイプラインを素早く試すために使用できる 2, 3 のサンプルを提供します。下のステップは幾つかの Python 演算子を含み、しかし機械学習 (ML) ワークロードを含まない基本的なサンプルをどのように実行するかを示します :

  1. パイプライン UI 上、サンプル [Sample] Basic – Parallel Execution の名前をクリックします :
     

  2. Create experiment をクリックします :
     

  3. 実験 (= experiment) を作成してから 実行 (= run) を作成するためにプロンプトに従います。サンプルは必要な総てのパラメータのためのデフォルト値を供給します。次のスクリーンショットは貴方が既に “My experiment” という名前の実験を作成してそして今は “My first run” という名前の実行を作成していることを仮定しています :
     

  4. 実行を作成するために Start をクリックします。
  5. 実験ダッシュボード上の実行の名前をクリックします :
     

  6. グラフと他の UI 要素のコンポーネントをクリックすることにより貴方の実行のグラフと他の様相を調べる :

Kubeflow パイプライン repo で 基本的な並列 join サンプルのためのソースコード を見つけられます。

 

ML パイプラインを実行する

このセクションはパイプライン UI から利用可能な XGBoost サンプルをどのように実行するかを示します。上で説明された基本的なサンプルとは違い、XGBoost サンプルは ML コンポーネントを含みません。このサンプルを実行する前に、サンプルによる使用のために幾つかの GCP サービスをセットアップする必要があります。

必要な GCP サービスをセットアップしてサンプルを実行するためにこれらのステップに従います :

  1. Kubeflow のために必要な標準的な GCP API に加えて (GCP セットアップガイド 参照)、以下の API が有効であることを確実にしてください :
  2. パイプライン実行の結果を保持するために Cloud ストレージ・バケット を作成します。
    • バケット名は総ての Cloud ストレージに渡り一意でなければなりません。
    • このパイプラインのために新しい実行を作成するたびに、Kubeflow は出力バケット内に一意なディレクトリを作成しますので、各実行の出力は前の実行の出力を override することはありません。
  3. パイプライン UI 上、サンプル [Sample] ML – XGBoost – Training with Confusion Matrix の名前をクリックします :

  4. Create experiment をクリックします。
  5. 実験 を作成してから 実行 を作成するためにプロンプトに従います。以下の 実行パラメータ を供給します :
    • output: パイプライン実行の結果を保持するために先に作成した Cloud ストレージ・バケット。
    • project: 貴方の GCP プロジェクト ID.

    サンプルは他のパラメータのための値を供給します :

    • region: GCP 地理的リージョン、そこで訓練と評価データがストアされます。
    • train-data: 訓練データへの Cloud ストレージ・パス。
    • eval-data: 評価データへの Cloud ストレージ・パス。
    • schema: 訓練と評価データを含む CSV フアイルの形式を記述する JSON ファイルへの Cloud ストレージ・パス。
    • target: ターゲット変数のカラム名。
    • rounds: XGBoost 訓練のためのラウンド数。
    • workers: 分散訓練のために使用されるワーカー数。
    • true-label: モデルにより出力されるラベルのテキスト表現のために使用されるカラム。

    次の部分的なスクリーンショットは、供給しなければならない 2 つのパラメータを含む、実行パラメータを示します :

  6. 実行を作成するために Start をクリックします。
  7. 実験ダッシュボード上の実行の名前をクリックします。
  8. グラフと他の UI 要素のコンポーネント上をクリックすることによりグラフと他の実行の様相を調べます。次のスクリーンショットはパイプラインが実行を終了したときグラフを示します :

Kubeflow パイプライン repo で XGBoost 訓練サンプルのためのソースコードを見つけることができます。

 

GCP 環境をクリーンアップする

このガイドを通して作業するとき、貴方のプロジェクトは GCP の支払い請求可能な (= billable) コンポーネントを使用します。コストを最小化するために、リソースを (それらで終了したとき) クリーンアップするためにこれらのステップに従います :

  1. 配備と関連リソースを削除するために Deployment Manager を訪ねます。
  2. パイプラインの出力を調べ終わったとき Cloud Storage bucket を削除します。
 

以上






Kubeflow 1.0 : コンポーネント : ハイパーパラメータ調整 : Katib Configuration 概要

Kubeflow 1.0 : コンポーネント : ハイパーパラメータ調整 : Katib Configuration 概要 (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/12/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

コンポーネント : ハイパーパラメータ調整 : Katib Configuration 概要

このページは Katib config についての情報を説明します。

Katib config は以下についての情報を含む Kubernetes Config Map です :

  1. 現在の メトリクス・コレクタ (key = metrics-collector-sidecar)
  2. 現在の アルゴリズム (提案) (key = suggestion).

Katib Config Map は katib-config を持つ KATIB_CORE_NAMESPACE 名前空間に配備されなければなりません。Katib コントローラは実験を提出するとき Katib config をパースします。

Katib を配備した後でさえもこの Config Map を編集できます。

Katib を Kubeflow 名前空間で配備する場合、Katib config を編集するためにこれを実行します :

kubectl edit configMap katib-config -n kubeflow

 

メトリクスコレクタ Sidecar 設定

これらの設定は Katib メトリクスコレクタに関係します、そこでは :

  • key = metrics-collector-sidecar
  • value = 各メトリクスコレクタのための JSON を設定することに相当します。

総ての設定を持つファイル・メトリクスコレクタのためのサンプル :

metrics-collector-sidecar: |-
{
  "File": {
    "image": "gcr.io/kubeflow-images-public/katib/v1alpha3/file-metrics-collector",
    "imagePullPolicy": "Always",
    "resources": {
      "requests": {
        "memory": "200Mi",
        "cpu": "250m",
        "ephemeral-storage": "200Mi"
      },
      "limits": {
        "memory": "1Gi",
        "cpu": "500m",
        "ephemeral-storage": "2Gi"
      }
    }
  },
  ...
}

image を除くこれらの設定の総ては省略できます。任意の他の設定を指定しない場合、デフォルト値が設定されます。

  1. image – ファイル・メトリクスコレクタのための Docker イメージ名。

    指定されなければなりません

  2. imagePullPolicy – ファイル・メトリクスコレクタ・コンテナ イメージ pull ポリシー

    デフォルト値は IfNotPresent.

  3. resources – ファイル・メトリクスコレクタ コンテナリソース。上のサンプルで limits と requests をどのように指定するか見ることができます。現在、memory, cpu と ephemeral-storage リソースだけが指定できます。

    requests のためのデフォルト値は :

    • memory = 10Mi.
    • cpu = 50m.
    • ephemeral-storage = 500Mi.

    limits のためのデフォルト値は :

    • memory = 100Mi.
    • cpu = 500m.
    • ephemeral-storage = 5Gi.

 

提案 (= suggestiojn) 設定

これらの設定は Katib 提案に関係します、そこでは :

  • key = suggestion
  • value = 各アルゴリズムための JSON を設定することに相当します。

新しいアルゴリズムを使用することを望む場合、新しい提案で Katib config を更新しなければなりません。

総ての設定を持つランダム提案のためのサンプル :

suggestion: |-
{
  "random": {
    "image": "gcr.io/kubeflow-images-public/katib/v1alpha3/suggestion-hyperopt",
    "imagePullPolicy": "Always",
    "resources": {
      "requests": {
        "memory": "100Mi",
        "cpu": "100m",
        "ephemeral-storage": "100Mi"
      },
      "limits": {
        "memory": "500Mi",
        "cpu": "500m",
        "ephemeral-storage": "3Gi"
      }
    },
    "serviceAccountName": "suggestion-serviceaccount"
  },
  ...
}

image を除くこれらの設定の総ては省略できます。任意の他の設定を指定しない場合、デフォルト値が設定されます。

  1. image – ランダム提案のための Docker イメージ名。

    指定されなければなりません

  2. imagePullPolicy – ランダム提案・コンテナ イメージ pull ポリシー

    デフォルト値は IfNotPresent.

  3. resources – ランダム提案 コンテナリソース。上のサンプルで limits と requests をどのように指定するか見ることができます。現在、memory, cpu と ephemeral-storage リソースだけが指定できます。

    requests のためのデフォルト値は :

    • memory = 10Mi.
    • cpu = 50m.
    • ephemeral-storage = 500Mi.

    limits のためのデフォルト値は :

    • memory = 100Mi.
    • cpu = 500m.
    • ephemeral-storage = 5Gi.
  4. serviceAccountName – ランダム提案コンテナ サービスアカウント。上のサンプルでは、ランダムアルゴリズムを持つ各実験のために suggestion-serviceaccount サービスアカウントが使用されます、Katib config からこのサービスアカウントが変更または削除されない限りは。

    デフォルトでは提案ポッドは特定のサービスアカウントを持ちません。この場合、提案ポッドは デフォルト サービスアカウントを使用します。

 

以上






Kubeflow 1.0 : コンポーネント : ハイパーパラメータ調整 : Getting started with Katib

Kubeflow 1.0 : コンポーネント : ハイパーパラメータ調整 : Getting started with Katib (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/11/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

コンポーネント : ハイパーパラメータ調整 : Getting started with Katib

このページは貴方に Katib で始めさせます。貴方の環境に依拠して、必要かもしれない任意の追加のセットアップを遂行し、そしてコマンドラインと Katib ユーザインターフェイス (UI) を使用して 2,3 のサンプルを実行するためにこのガイドに従ってください。

Katib とハイパーパラメータ調整まわりのコンセプトの概要については、Katib へのイントロダクション を読んでください。

 

Katib セットアップ

(訳注 : 省略します。必要な場合には原文参照)

 

Katib UI にアクセスする

実験を提出して結果を監視するために Katib ユーザインターフェイス (UI) を利用できます。Kubeflow 内の Katib ホームページはこのように見えます :

Kubeflow の一部として Katib をインストールした場合、Kubeflow UI から Katib UI にアクセスできます :

  1. Kubeflow UI をオープンします。セントラル・ダッシュボードにアクセスする へのガイドを見てください。
  2. 左手のメニューの Katib をクリックします。

代わりに、Katib UI サービスのためにポートフォワーディングを設定できます :

kubectl port-forward svc/katib-ui -n kubeflow 8080:80

それからこの URL で Katib UI にアクセスできます :

http://localhost:8080/katib/

 

サンプル

このセクションは Katib を試すために実行できる幾つかのサンプルを紹介します。

 

ランダムアルゴリズムを使用するサンプル

YAML configuration ファイルで実験を定義することにより Katib のための実験を作成できます。YAML ファイルはハイパーパラメータ実行可能空間、最適化パラメータ、最適化ゴール、提案アルゴリズム、等々を含む、実験のための configuration を定義します。

このサンプルは ランダムアルゴリズム・サンプルのための YAML ファイル を使用します。

ランダムアルゴリズム・サンプルは MNIST データセットを使用して画像分類モデルを訓練するために MXNet ニューラルネットワークを使用します。訓練コンテナ・ソースコードを ここ で確認できます。実験は様々なハイパーパラメータで 3 つの訓練ジョブを実行して結果をセーブします。

ランダムアルゴリズム・サンプルを使用して実験を起動するために以下のコマンドを実行します :

  1. サンプルをダウンロードします :
    curl https://raw.githubusercontent.com/kubeflow/katib/master/examples/v1alpha3/random-example.yaml --output random-example.yaml
    
  2. 貴方の Kubeflow ユーザプロフィール名前空間を使用するために random-example.yaml を編集して次の行を変更します :
    Namespace: kubeflow
    
  3. サンプルを配備する :
    kubectl apply -f random-example.yaml
    

このサンプルはハイパーパラメータを引数として埋め込みます。YAML ファイルの TrialTemplate.GoTemplate.RawTemplate セクションで定義されたテンプレートを使用して他の方法 (例えば、環境変数を使用して) でハイパーパラメータを埋め込むことができます。テンプレートは Go テンプレート・フォーマット を使用します。

このサンプルは以下のハイパーパラメータをランダムに生成します :

  • –lr: 学習率。型: double.
  • –num-layers: ニューラルネットワークの層の数。型: integer.
  • –optimizer: Optimizer. 型: categorical.

実験ステータスを確認します :

kubectl -n <your user profile namespace> describe experiment random-example

上のコマンドの出力はこれと同様に見えます :

Name:         random-example
Namespace:    <your user namespace> 
Labels:       controller-tools.k8s.io=1.0
Annotations:  <none>
API Version:  kubeflow.org/v1alpha3
Kind:         Experiment
Metadata:
  Creation Timestamp:  2019-12-22T22:53:25Z
  Finalizers:
    update-prometheus-metrics
  Generation:        2
  Resource Version:  720692
  Self Link:         /apis/kubeflow.org/v1alpha3/namespaces/kubeflow/experiments/random-example
  UID:               dc6bc15a-250d-11ea-8cae-42010a80010f
Spec:
  Algorithm:
    Algorithm Name:        random
    Algorithm Settings:    <nil>
  Max Failed Trial Count:  3
  Max Trial Count:         12
  Metrics Collector Spec:
    Collector:
      Kind:  StdOut
  Objective:
    Additional Metric Names:
      accuracy
    Goal:                   0.99
    Objective Metric Name:  Validation-accuracy
    Type:                   maximize
  Parallel Trial Count:     3
  Parameters:
    Feasible Space:
      Max:           0.03
      Min:           0.01
    Name:            --lr
    Parameter Type:  double
    Feasible Space:
      Max:           5
      Min:           2
    Name:            --num-layers
    Parameter Type:  int
    Feasible Space:
      List:
        sgd
        adam
        ftrl
    Name:            --optimizer
    Parameter Type:  categorical
  Trial Template:
    Go Template:
      Raw Template:  apiVersion: batch/v1
kind: Job
metadata:
  name: {{.Trial}}
  namespace: {{.NameSpace}}
spec:
  template:
    spec:
      containers:
      - name: {{.Trial}}
        image: docker.io/kubeflowkatib/mxnet-mnist-example
        command:
        - "python"
        - "/mxnet/example/image-classification/train_mnist.py"
        - "--batch-size=64"
        {{- with .HyperParameters}}
        {{- range .}}
        - "{{.Name}}={{.Value}}"
        {{- end}}
        {{- end}}
      restartPolicy: Never
Status:
  Conditions:
    Last Transition Time:  2019-12-22T22:53:25Z
    Last Update Time:      2019-12-22T22:53:25Z
    Message:               Experiment is created
    Reason:                ExperimentCreated
    Status:                True
    Type:                  Created
    Last Transition Time:  2019-12-22T22:55:10Z
    Last Update Time:      2019-12-22T22:55:10Z
    Message:               Experiment is running
    Reason:                ExperimentRunning
    Status:                True
    Type:                  Running
  Current Optimal Trial:
    Observation:
      Metrics:
        Name:   Validation-accuracy
        Value:  0.981091
    Parameter Assignments:
      Name:          --lr
      Value:         0.025139701133432946
      Name:          --num-layers
      Value:         4
      Name:          --optimizer
      Value:         sgd
  Start Time:        2019-12-22T22:53:25Z
  Trials:            12
  Trials Running:    2
  Trials Succeeded:  10
Events:              <none>

Status.Conditions.Type の最後の値が Succeeded であるとき、実験は完了しています。

Katib UI で実験の結果を見ます :

  1. 上で 説明されたように Katib UI をオープンする。
  2. Katib ホームページで ハイパーパラメータ調整 をクリックする。
  3. 左側の Katib メニューパネルをオープンしてから、HP セクションをオープンして モニタ をクリックします :

  4. メニューパネルをクローズするために右側のパネル上をクリックします。実験のリストを見るはずです :

  5. 実験の名前、random-example をクリックします。
  6. ハイパーパラメータ値 (学習率、層数と optimizer) の様々な組み合わせのための精度のレベルを示すグラフを見るはずです :

  7. 下でグラフは実験内で実行されたトライアルのリストです :

 

TensorFlow サンプル

Kebeflow の TensorFlow 訓練ジョブ演算子, TFJob を使用して実験を起動するために以下のコマンドを実行します :

  1. tfjob-example.yaml ファイルをダウンロードする。
    curl https://raw.githubusercontent.com/kubeflow/katib/master/examples/v1alpha3/tfjob-example.yaml --output tfjob-example.yaml
    
  2. 貴方の Kubeflow ユーザプロフィール名前空間を使用するために tfjob-example.yaml を編集して次の行を変更します :
    Namespace: kubeflow
    
  3. サンプルを配備する :
    kubectl apply -f tfjob-example.yaml
    
  4. 実験のステータスを確認できます :
    kubectl -n <your user profile namespace> describe experiment tfjob-example
    

Katib UI で実験の結果を見るため、 のランダムアルゴリズム・サンプルのために説明されたステップに従います。

 

PyTorch サンプル

Kebeflow の PyTorch 訓練ジョブ演算子, PyTorchJob を使用して実験を起動するために以下のコマンドを実行します :

  1. pytorchjob-example.yaml ファイルをダウンロードする。
    curl https://raw.githubusercontent.com/kubeflow/katib/master/examples/v1alpha3/pytorchjob-example.yaml --output pytorchjob-example.yaml
    
  2. 貴方の Kubeflow ユーザプロフィール名前空間を使用するために pytorchjob-example.yaml を編集して次の行を変更します :
    Namespace: kubeflow
    
  3. サンプルを配備する :
    kubectl apply -f pytorchjob-example.yaml
    
  4. 実験のステータスを確認できます :
    kubectl -n <your user profile namespace> describe experiment pytorchjob-example
    

Katib UI で実験の結果を見るため、 のランダムアルゴリズム・サンプルのために説明されたステップに従います。

 

クリーンアップ

インストールされたコンポーネントを削除します :

bash ./scripts/v1alpha3/undeploy.sh
 

以上






Kubeflow 1.0 : コンポーネント : ハイパーパラメータ調整 : Katib へのイントロダクション

Kubeflow 1.0 : コンポーネント : ハイパーパラメータ調整 : Katib へのイントロダクション (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/11/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

コンポーネント : ハイパーパラメータ調整 : Katib へのイントロダクション

貴方の機械学習 (ML) モデルのハイパーパラメータとアーキテクチャの自動調整のために Katib を利用します。

このページはハイパーパラメータ調整、ニューラルアーキテクチャ探索、そして Kubeflow のコンポーネントとしての Katib システムの概念を紹介します。

 

ハイパーパラメータとハイパーパラメータ調整

ハイパーパラメータはモデル訓練プロセスを制御する変数です。例えば :

  • 学習率
  • ニューラルネットワークの層の数。
  • 各層のノードの数。

ハイパーパラメータ値は学習されません。換言すれば、ノード重みと他の訓練パラメータとは対照的に、モデル訓練プロセスはハイパーパラメータ値を調整しません。

ハイパーパラメータ調整はモデルの予測精度を最大化するためにハイパーパラメータ値を最適化するプロセスです。Katib やハイパーパラメータ調整のための類似のシステムを利用しない場合、最適値を見つけるために手動でハイパーパラメータを調整して、多くの訓練ジョブを貴方自身で実行する必要があります。

自動ハイパーパラメータ調整はハイパーパラメータ調整ジョブのための configuration で指定する、目的メトリックとも呼ばれる、ターゲット変数を最適化することにより動作します。一般的なメトリックは訓練ジョブの検証パスにおけるモデルの精度です (検証精度)。ハイパーパラメータ調整ジョブにメトリックを最大化 or 最初化することを望むかを指定することもできます。

例えば、Katib からの次のグラフはハイパーパラメータ値 (学習率、層の数、そして optimizer) の様々な組み合わせのための精度のレベルを表示しています :

(このグラフを生成したサンプルを実行するには、getting-started ガイド に従ってください。)

Katib は各ハイパーパラメータ調整ジョブ (実験) 内で (トライアルとして知られる) 幾つかの訓練ジョブを実行します。各トライアルはハイパーパラメータ configuration の幾つかのセットをテストします。各トライアルはハイパーパラメータの configuration の異なるセットをテストします。実験の最後に、Katib はハイパーパラメータのための最適値を出力します。

 

ニューラル・アーキテクチャ探索

ハイパーパラメータ調整に加えて、Katib はニューラル・アーキテクチャ探索 (NAS) 特徴も提供します。モデルの予測精度とパフォーマンスを最大化する目標とともに、貴方の人工ニューラルネットワークを設計するために NAS を利用することができます。

NAS はハイパーパラメータ調整と密接に関係します。両者は自動機械学習 (AutoML) のサブセットです。ハイパーパラメータ調整がモデルのハイパーパラメータを最適化する一方で、NAS システムはモデルの構造、ノード重み、そしてハイパーパラメータを最適化します。

NAS テクノロジーは一般に最適なニューラルネットワーク・デザインを見つけるために様々なテクニックを使用します。Katib の NAS は強化学習テクニックを使用します。

コマンドラインか UI から Katib ジョブを提出することができます (Katib インターフェイスについてこのページで後で更に読んでください)。次のスクリーンショットは Katib UI から NAS ジョブを提出するためのフォームの一部を表示しています :

 

Katib プロジェクト

Katib はハイパーパラメータ調整とニューラル・アーキテクチャ探索のための Kubernetes ベースのシステムです。Katib は TensorFlow, MXNet, PyTorch, XGBoost その他を含む幾つかの ML フレームワークをサポートします。

Katib プロジェクト はオープンソースです。

 

Katib インターフェイス

Katib と相互作用するために以下のインターフェイスを使用できます :

  • 実験を提出して結果を監視するために web UI を利用できます。UI にどのようにアクセスするかについての情報は getting-started ガイド を見てください。Kubeflow 内の Katib ホームページはこのように見えます :

  • REST API。GitHub 上の API リファレンス を見てください。
  • コマンドライン・インターフェイス (CLI) :
    • Kfctl は Kubeflow をインストールして configure するために利用できる Kubeflow CLI です。kfctl について configuring Kubeflow へのガイドを読んでください。
    • Kubernetes CLI, kubectl, は Kubeflow クラスタに対してコマンドを実行するために有用です。kubectl について Kubernetes ドキュメント を読んでください。

 

Katib コンセプト

このセクションは Katib で使用される用語を説明します。

 

実験

実験は単一の調整実行で、最適化実行とも呼ばれます。

実験を定義するために configuration 設定を指定します。以下は主要な configuration です :

  • Objective (目的 (関数)) : 最適化することを望むもの。これは目的メトリックで、ターゲット変数とも呼ばれます。一般的なメトリックは訓練ジョブの検証パスにおけるモデル精度です (検証精度)。メトリックを最大化 or 最小化するためにハイパーパラメータ調整ジョブを望むかも指定できます。
  • Search space (探索空間) : ハイパーパラメータ調整ジョブが最適化のために考慮すべき総ての可能なハイパーパラメータ値のセットと各ハイパーパラメータのための制約です。探索空間のための他の名前は実行可能なセットと解法空間を含みます。例えば、最適化することを望むハイパーパラメータの名前を提供するかもしれません。各ハイパーパラメータについて、最小と最大値 or 許容される値のリストを提供するかもしれません。
  • Search algorithm (探索アルゴリズム) : 最適なハイパーパラメータ値を探索するときに使用するアルゴリズム。

実験をどのように定義するかの詳細については、running an experiment へのガイドを見てください。

 

提案

提案 (= suggestion) はハイパーパラメータ調整プロセスが提示したハイパーパラメータ値のセットです。Katlib は提案された値のセットを評価するためにトライアルを作成します。

 

トライアル

トライアルはハイパーパラメータ調整プロセスの 1 つの反復です。トライアルはパラメータ割り当てのリストを持つ一つのワーカージョブ・インスタンスに対応します。パラメータ割り当てのリストは提案に相当します。

各実験は幾つかのトライアルを実行します。実験はそれが目標か設定されたトライアルの最大数に達するまでトライアルを実行します。

 

ワーカージョブ

ワーカージョブはトライアルを評価してその目的 (関数) 値を計算するために実行されるプロセスです。

ワーカージョブは以下のタイプの一つであり得ます :

上のワーカージョブ・タイプを提供することにより、Katib はマルチ ML フレームワークをサポートします。

 

以上






Kubeflow 1.0 : コンポーネント : TensorFlow 訓練 (TFJob)

Kubeflow 1.0 : コンポーネント : TensorFlow 訓練 (TFJob) (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/10/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

コンポーネント : TensorFlow 訓練 (TFJob)

このページは TensorFlow で機械学習モデルを訓練するための TFJob を記述します。

 

TFJob とは何でしょう?

TFJob は Kubernetes 上で TensorFlow 訓練ジョブを実行するために利用できる Kubernetes カスタム・リソース です。TFJob の Kubeflow 実装は tf-operator にあります。

TFJob は下の一つのような YAML 表現を持つリソースです (貴方自身の訓練コードのためのコンテナ・イメージとコマンドを使用するために編集します) :

apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  generateName: tfjob
  namespace: your-user-namespace
spec:
  tfReplicaSpecs:
    PS:
      replicas: 1
      restartPolicy: OnFailure
      template:
        spec:
          containers:
          - name: tensorflow
            image: gcr.io/your-project/your-image
            command:
              - python
              - -m
              - trainer.task
              - --batch_size=32
              - --training_steps=1000
    Worker:
      replicas: 3
      restartPolicy: OnFailure
      template:
        spec:
          containers:
          - name: tensorflow
            image: gcr.io/your-project/your-image
            command:
              - python
              - -m
              - trainer.task
              - --batch_size=32
              - --training_steps=1000

GKE ベースで Kubeflow インストールを行なったときに自動的に作成される GCP クレデンシャルのような、クレデンシャル secret への TFJob ポッド・アクセスを与えることを望む場合、このように secret をマウントして使用できます :

apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  generateName: tfjob
  namespace: your-user-namespace
spec:
  tfReplicaSpecs:
    PS:
      replicas: 1
      restartPolicy: OnFailure
      template:
        spec:
          containers:
          - name: tensorflow
            image: gcr.io/your-project/your-image
            command:
              - python
              - -m
              - trainer.task
              - --batch_size=32
              - --training_steps=1000
            env:
            - name: GOOGLE_APPLICATION_CREDENTIALS
              value: "/etc/secrets/user-gcp-sa.json"
            volumeMounts:
            - name: sa
              mountPath: "/etc/secrets"
              readOnly: true
          volumes:
          - name: sa
            secret:
              secretName: user-gcp-sa
    Worker:
      replicas: 1
      restartPolicy: OnFailure
      template:
        spec:
          containers:
          - name: tensorflow
            image: gcr.io/your-project/your-image
            command:
              - python
              - -m
              - trainer.task
              - --batch_size=32
              - --training_steps=1000
            env:
            - name: GOOGLE_APPLICATION_CREDENTIALS
              value: "/etc/secrets/user-gcp-sa.json"
            volumeMounts:
            - name: sa
              mountPath: "/etc/secrets"
              readOnly: true
          volumes:
          - name: sa
            secret:
              secretName: user-gcp-sa

Kubernetes リソースに馴染みがないのであれば、ページ Understanding Kubernetes オブジェクト を参照してください。

TFJob を 組込みコントローラ と違わせるものは TFJob spec は 分散 TensorFlow 訓練ジョブ を管理するために設計されていることです。

分散 TensorFlow ジョブは典型的には以下のプロセスの 0 またそれ以上を含みます :

  • Chief : chief はモデルをチェックポイントするように訓練の編成とタスクの遂行の責任を負います。
  • Ps : ps はパラメータ・サーバです ; これらのサーバはモデルパラメータのための分散データストアを提供します。
  • Worker : ワーカーはモデルを訓練する実際の作業を行ないます。ある場合には、ワーカー 0 はまた chief として動作するかもしれません。
  • Evaluator : 評価器はモデルが訓練されるとき評価メトリクスを計算するために使用できます。

TFJob spec のフィールド tfReplicaSpecs は (上でリストされた) レプリカのタイプからそのレプリカのための TFReplicaSpec へのマップを含みます。TFReplicaSpec は 3 フィールドから成ります :

  • replicas この TFJob のために起動するこのタイプのレプリカ数。
  • template 各レプリカのために作成するポッドを記述する PodTemplateSpec
    • ポッドは tensorflow という名前のコンテナを含まなければなりません
  • restartPolicy ポッドがそれらが exit するとき再開始されるか否かを決定します。許可される値は次のようなものです :
    • Always はポッドが常に再開始されることを意味します。このポリシーはパラメータサーバのために良いです、何故ならばそれらは決して exit せずに failure イベントでは常に再開始されるべきであるためです。
    • OnFailure はポッドが failure により exit する場合に再開始されることを意味します。
      • 非ゼロは failure を示すコードです。
      • 0 の exit コードは成功を示しそしてポッドは再開始されません。
      • このポリシーは chief と worker のために良いです。
    • ExitCode は再開始動作は次のように tensorflow コンテナの exit コードに依拠していることを意味します。
      • Exit コード 0 はプロセスは成功的に完了し再開始されません。
      • 以下の exit コードはパーマネントエラーを示しそしてコンテナは再開始されません :
        • 1: 一般エラー
        • 2: misuse of shell builtins
        • 126: command invoked cannot execute
        • 127: command not found
        • 128: invalid argument to exit
        • 139: container terminated by SIGSEGV (invalid memory reference)
      • 以下の exit コードは再試行可能なエラーを示しそしてコンテナは再開始されます :
        • 130: container terminated by SIGINT (keyboard Control-C)
        • 137: container received a SIGKILL
        • 143: container received a SIGTERM
      • Exit コード 138 は SIGUSR1 に対応してユーザ指定再試行可能なエラーのために予約されています。
      • 他の exit コードは未定義で動作について保証はありません。

      exit コードのバックグラウンド情報については、termination シグナルへの GNU ガイドLinux ドキュメント・プロジェクト を見てください。

    • Never は停止するポッドは決して再開始されないことを意味します。このポリシーは滅多に使用されないはずです、何故ならば Kubernetes はどのような数の理由 (e.g. ノードが不安定になる) でもポッドを停止しそしてこれはジョブがリカバーされることを回避するからです。

 

クイックスタート

TensorFlow 訓練ジョブを投入する

Note: 訓練ジョブを投入する前に、kubeflow を貴方のクラスタに配備する べきでした。それを行なうことで訓練ジョブを投入するとき TFJob カスタム・リソース が利用可能であることを確かなものにします。

 

MNist サンプルを実行する

Kubeflow は単純な MNist モデル を実行するために適した サンプル とともに配布されています。

git clone https://github.com/kubeflow/tf-operator
cd tf-operator/examples/v1/mnist_with_summaries
# Deploy the event volume
kubectl apply -f tfevent-volume
# Submit the TFJob
kubectl apply -f tf_job_mnist.yaml

ジョブを監視する (下の詳細ガイド を見てください) :

kubectl -n kubeflow get tfjob mnist -o yaml

それを削除する :

kubectl -n kubeflow delete tfjob mnist

 

TFJob をカスタマイズする

典型的には TFJob yaml ファイルの次の値を変更できます :

  1. イメージを貴方のコードを含む docker イメージを指すように変更する
  2. レプリカの数とタイプを変更する
  3. 各リソースに割り当てられたリソース (リクエストと制限) を変更する
  4. 任意の環境変数を設定する
    • 例えば、GCS or S3 のようなデータストアと通信するために様々な環境変数を configure する必要があるかもしれません
  5. ストレージのために PV を使用することを望む場合 PV を装着する。

 

GPU を使用する

貴方のクラスタは GPU を利用するために configure されなければなりません。

GPU を装着するには GPU を含むべきレプリカのコンテナ上の GPU リソースを指定します ; 例えば :

apiVersion: "kubeflow.org/v1"
kind: "TFJob"
metadata:
  name: "tf-smoke-gpu"
spec:
  tfReplicaSpecs:
    PS:
      replicas: 1
      template:
        metadata:
          creationTimestamp: null
        spec:
          containers:
          - args:
            - python
            - tf_cnn_benchmarks.py
            - --batch_size=32
            - --model=resnet50
            - --variable_update=parameter_server
            - --flush_stdout=true
            - --num_gpus=1
            - --local_parameter_device=cpu
            - --device=cpu
            - --data_format=NHWC
            image: gcr.io/kubeflow/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3
            name: tensorflow
            ports:
            - containerPort: 2222
              name: tfjob-port
            resources:
              limits:
                cpu: '1'
            workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
          restartPolicy: OnFailure
    Worker:
      replicas: 1
      template:
        metadata:
          creationTimestamp: null
        spec:
          containers:
          - args:
            - python
            - tf_cnn_benchmarks.py
            - --batch_size=32
            - --model=resnet50
            - --variable_update=parameter_server
            - --flush_stdout=true
            - --num_gpus=1
            - --local_parameter_device=cpu
            - --device=gpu
            - --data_format=NHWC
            image: gcr.io/kubeflow/tf-benchmarks-gpu:v20171202-bdab599-dirty-284af3
            name: tensorflow
            ports:
            - containerPort: 2222
              name: tfjob-port
            resources:
              limits:
                nvidia.com/gpu: 1
            workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
          restartPolicy: OnFailure

GPU を利用するための TensorFlow の 手順 に従ってください。

 

貴方のジョブを監視する

貴方のジョブのステータスを得るには :

kubectl get -o yaml tfjobs ${JOB}

ここのサンプル・ジョブのためのサンプル出力があります :

apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"kubeflow.org/v1","kind":"TFJob","metadata":{"annotations":{},"name":"mnist","namespace":"kubeflow"},"spec":{"cleanPodPolicy":"None","tfReplicaSpecs":{"Worker":{"replicas":1,"restartPolicy":"Never","template":{"spec":{"containers":[{"command":["python","/var/tf_mnist/mnist_with_summaries.py","--log_dir=/train","--learning_rate=0.01","--batch_size=150"],"image":"gcr.io/kubeflow-ci/tf-mnist-with-summaries:1.0","name":"tensorflow","volumeMounts":[{"mountPath":"/train","name":"training"}]}],"volumes":[{"name":"training","persistentVolumeClaim":{"claimName":"tfevent-volume"}}]}}}}}}
  creationTimestamp: "2019-07-16T02:44:38Z"
  generation: 1
  name: mnist
  namespace: your-user-namespace
  resourceVersion: "10429537"
  selfLink: /apis/kubeflow.org/v1/namespaces/kubeflow/tfjobs/mnist
  uid: a77b9fb4-a773-11e9-91fe-42010a960094
spec:
  cleanPodPolicy: None
  tfReplicaSpecs:
    Worker:
      replicas: 1
      restartPolicy: Never
      template:
        spec:
          containers:
          - command:
            - python
            - /var/tf_mnist/mnist_with_summaries.py
            - --log_dir=/train
            - --learning_rate=0.01
            - --batch_size=150
            image: gcr.io/kubeflow-ci/tf-mnist-with-summaries:1.0
            name: tensorflow
            volumeMounts:
            - mountPath: /train
              name: training
          volumes:
          - name: training
            persistentVolumeClaim:
              claimName: tfevent-volume
status:
  completionTime: "2019-07-16T02:45:23Z"
  conditions:
  - lastTransitionTime: "2019-07-16T02:44:38Z"
    lastUpdateTime: "2019-07-16T02:44:38Z"
    message: TFJob mnist is created.
    reason: TFJobCreated
    status: "True"
    type: Created
  - lastTransitionTime: "2019-07-16T02:45:20Z"
    lastUpdateTime: "2019-07-16T02:45:20Z"
    message: TFJob mnist is running.
    reason: TFJobRunning
    status: "True"
    type: Running
  replicaStatuses:
    Worker:
      running: 1
  startTime: "2019-07-16T02:44:38Z"

 

条件

TFJob は TFJobStatus を持ち、これは TFJobConditions の配列を持ちます、それを通して TFJob は通過または非通過しました。TFJobCondition の各要素は 6 つの可能なフィールドを持ちます :

  • lastUpdateTime フィールドはこの条件が更新された最後の時間を提供します。
  • lastTransitionTime フィールドは条件が一つのステータスから他に遷移した最後の時間を提供します。
  • message フィールドは遷移についての詳細を示す可読なメッセージです。
  • reason フィールドは条件の最後の遷移のための一意、1 単語、CamelCase な理由です。
  • status フィールドは可能な値 “True”, “False” と “Unknown” を持つ文字列です。
  • type フィールドは以下の可能な値を持つ文字列です :
    • TFJobCreated は tfjob がシステムにより受け取られたことを意味しますが、ポッド/サービスの一つまたはそれ以上がまだ開始されていません。
    • TFJobRunning はこの TFJob の総てのサブリソース (e.g. サービス/ポッド) が成功的にスケジュールされて起動されてジョブが実行されていることを意味します。
    • TFJobRestarting はこの TFJob の一つまたはそれ以上のサブリソース (e.g. サービス/ポッド) が問題を持ち再開始されていることを意味します。
    • TFJobSucceeded はジョブが成功的に完了したことを意味します。
    • TFJobFailed はジョブが失敗したことを意味します。

ジョブの成功と失敗は次のように決定されます :

  • ジョブが chief 成功か失敗を持つかは chief のステータスにより決定されます。
  • ジョブが chief でない成功か失敗を持つかはワーカーにより決定されます。
  • 両者の場合、TFJob は監視されているプロセスが exit コード 0 で抜ける場合に成功します。
  • 非ゼロ exit コードの場合動作はレプリカのための restartPolicy により決定されます。
  • restartPolicy が再開始を許容する場合にはプロセスは単に再開始されて TFJob は実行し続けます。
    • restartPolicy ExitCode については動作は exit コード依存です。
    • restartPolicy が再開始を許容しない場合、非ゼロ exit コードはパーマネント失敗と考えられてジョブは失敗とマークされます。

 

tfReplicaStatuses

tfReplicaStatuses は与えられた状態にある各レプリカのためのポッドの数を示すマップを提供します。3 つの可能な状態があります :

  • Active は現在実行中のポッドの数です。
  • Succeeded は成功的に完了したポッドの数です。
  • Failed はエラーで完了したポッドの数です。

 

イベント

実行の間、TFJob はポッドとサービスの作成/削除のような発生したことを示すためにイベントを出力します。Kubernetes はデフォルトでは 1 時間よりも古いイベントは保持しません。ジョブのための最近のイベントを見るには次を実行します :

kubectl describe tfjobs ${JOB}

これは次のような出力を生成します :

Name:         mnist
Namespace:    kubeflow
Labels:       
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"kubeflow.org/v1","kind":"TFJob","metadata":{"annotations":{},"name":"mnist","namespace":"kubeflow"},"spec":{"cleanPodPolicy...
API Version:  kubeflow.org/v1
Kind:         TFJob
Metadata:
  Creation Timestamp:  2019-07-16T02:44:38Z
  Generation:          1
  Resource Version:    10429537
  Self Link:           /apis/kubeflow.org/v1/namespaces/kubeflow/tfjobs/mnist
  UID:                 a77b9fb4-a773-11e9-91fe-42010a960094
Spec:
  Clean Pod Policy:  None
  Tf Replica Specs:
    Worker:
      Replicas:        1
      Restart Policy:  Never
      Template:
        Spec:
          Containers:
            Command:
              python
              /var/tf_mnist/mnist_with_summaries.py
              --log_dir=/train
              --learning_rate=0.01
              --batch_size=150
            Image:  gcr.io/kubeflow-ci/tf-mnist-with-summaries:1.0
            Name:   tensorflow
            Volume Mounts:
              Mount Path:  /train
              Name:        training
          Volumes:
            Name:  training
            Persistent Volume Claim:
              Claim Name:  tfevent-volume
Status:
  Completion Time:  2019-07-16T02:45:23Z
  Conditions:
    Last Transition Time:  2019-07-16T02:44:38Z
    Last Update Time:      2019-07-16T02:44:38Z
    Message:               TFJob mnist is created.
    Reason:                TFJobCreated
    Status:                True
    Type:                  Created
    Last Transition Time:  2019-07-16T02:45:20Z
    Last Update Time:      2019-07-16T02:45:20Z
    Message:               TFJob mnist is running.
    Reason:                TFJobRunning
    Status:                True
    Type:                  Running
  Replica Statuses:
    Worker:
      Running:  1
  Start Time:  2019-07-16T02:44:38Z
Events:
  Type    Reason                   Age    From         Message
  ----    ------                   ----   ----         -------
  Normal  SuccessfulCreatePod      8m6s   tf-operator  Created pod: mnist-worker-0
  Normal  SuccessfulCreateService  8m6s   tf-operator  Created service: mnist-worker-0

ここでイベントはポッドとサービスが成功的に作成されたことを示します。

 

TensorFlow ログ

ロギングは標準的な K8s ロギング実践に従います。

削除 されなかった任意のポッドのための標準的な出力/エラーを得るために kubectl を使用できます。

最初に関心のあるレプリカのためのジョブ・コントローラにより作成されたポッドを見つけます。ポッドは次のように名前付けられます :

${JOBNAME}-${REPLICA-TYPE}-${INDEX}

ひとたびポッドを特定すれば、kubectl を使用してログを得ることができます。

kubectl logs ${PODNAME}

TFJob spec の CleanPodPolicy はジョブが停止したときポッドの削除を制御します。ポリシーは以下の値の一つであり得ます :

  • Running はジョブが完了したとき依然として実行しているポッド (e.g. パラメータサーバ) だけが直ちに削除されます ; 完了したポッドはログが保存されるように削除されません。これはデフォルト値です。
  • All ポリシーはジョブが終了したとき総てのポッド、完了したポッドさえも直ちに削除されることを意味します。
  • None ポリシーはジョブが完了したときポッドは削除されないことを意味します。

貴方のクラスタが Kubernetes クラスタ・ロギング を活用するならばログも更なる解析のために適切なデータストアに送られるかもしれません。

 

GKE 上の Stackdriver

Stackdriver を使用してログを得る上での手順については ロギングと監視 へのガイドを見てください。

ロギングと監視 へのガイドで説明されているように、ポッドラベルに基づいて特定のレプリカのためのログを取得することができます。

Stackdriver UI を使用して次のような問い合わせを使用できます :

resource.type="k8s_container"
resource.labels.cluster_name="${CLUSTER}"
metadata.userLabels.tf_job_name="${JOB_NAME}"
metadata.userLabels.tf-replica-type="${TYPE}"
metadata.userLabels.tf-replica-index="${INDEX}"

代わりに gcloud を使用して :

QUERY="resource.type=\"k8s_container\" "
QUERY="${QUERY} resource.labels.cluster_name=\"${CLUSTER}\" "
QUERY="${QUERY} metadata.userLabels.tf_job_name=\"${JOB_NAME}\" "
QUERY="${QUERY} metadata.userLabels.tf-replica-type=\"${TYPE}\" "
QUERY="${QUERY} metadata.userLabels.tf-replica-index=\"${INDEX}\" "
gcloud --project=${PROJECT} logging read  \
     --freshness=24h \
     --order asc  ${QUERY}

 

トラブルシューティング

ここに貴方のジョブのトラブルシュートをするために従うべき幾つかのステップがあります。

  1. ステータスは貴方のジョブのために存在していますか? 次のコマンドを実行してください :
    kubectl -n ${USER_NAMESPACE} get tfjobs -o yaml ${JOB_NAME}
    
    • USER_NAMESPACE は貴方のユーザプロフィールのために作成された名前空間です。
    • 結果としての出力が貴方のジョブのためのステータスを含まない場合、これは典型的にはジョブ spec が不正であることを示しています。
    • TFJob spec が不正であれば tf operator ログにログメッセージがあるはずです :
        kubectl -n ${KUBEFLOW_NAMESPACE} logs `kubectl get pods --selector=name=tf-job-operator -o jsonpath='{.items[0].metadata.name}'` 
        

      • KUBEFLOW_NAMESPACE は TFJob 演算子を配備した名前空間です。

     

  2. ポッドが作成されたかを見るために貴方のジョブのためのイベントを確認します。
    • イベントを得るために幾つかの方法があります ; ジョブが 1 時間未満であれば次を行なうことができます :
        kubectl -n ${USER_NAMESPACE} describe tfjobs -o yaml ${JOB_NAME}
        
    • 出力のボトムはジョブにより出力されたイベントのリストを含むはずです ; e.g.
      Events:
      Type     Reason                          Age                From         Message
      ----     ------                          ----               ----         -------
      Warning  SettedPodTemplateRestartPolicy  19s (x2 over 19s)  tf-operator  Restart policy in pod template will be overwritten by restart policy in replica spec
      Normal   SuccessfulCreatePod             19s                tf-operator  Created pod: tfjob2-worker-0
      Normal   SuccessfulCreateService         19s                tf-operator  Created service: tfjob2-worker-0
      Normal   SuccessfulCreatePod             19s                tf-operator  Created pod: tfjob2-ps-0
      Normal   SuccessfulCreateService         19s                tf-operator  Created service: tfjob2-ps-0
      
    • Kubernetes は 1 時間 の間イベントを保存するだけです (kubernetes/kubernetes#52521 参照)
      • 貴方のクラスタ・セットアップに依拠してイベントは外部ストレージに存続してより長い期間アクセス可能かもしれません。
      • GKE 上ではイベントは stackdriver で存続されて前のセクションの手順を使用してアクセスできます。
    • ポッドとサービスが作成されなければこれは TFJob が処理されていないことを提示します ; 一般的な原因は :
      • TFJob spec が不正である (上を見てください)
      • TFJob 演算子が動作していない

     

  3. ポッドのためのイベントをそれらがスケジュールされたかを確実にするためにクリックします。
    • イベントを得るために幾つかの方法があります ; ポッドが 1 時間未満であれば次を行なうことができます :
        kubectl -n ${USER_NAMESPACE} describe pods ${POD_NAME}
        
    • 出力のボトムは次のようなイベントを含むはずです :
      Events:
      Type    Reason                 Age   From                                                  Message
      ----    ------                 ----  ----                                                  -------
      Normal  Scheduled              18s   default-scheduler                                     Successfully assigned tfjob2-ps-0 to gke-jl-kf-v0-2-2-default-pool-347936c1-1qkt
      Normal  SuccessfulMountVolume  17s   kubelet, gke-jl-kf-v0-2-2-default-pool-347936c1-1qkt  MountVolume.SetUp succeeded for volume "default-token-h8rnv"
      Normal  Pulled                 17s   kubelet, gke-jl-kf-v0-2-2-default-pool-347936c1-1qkt  Container image "gcr.io/kubeflow/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3" already present on machine
      Normal  Created                17s   kubelet, gke-jl-kf-v0-2-2-default-pool-347936c1-1qkt  Created container
      Normal  Started                16s   kubelet, gke-jl-kf-v0-2-2-default-pool-347936c1-1qkt  Started container
      
    • コンテナを開始から妨げられる幾つかの一般的な問題は :
      • ポッドをスケジュールするために不十分なリソース
      • ポッドが存在しないか利用不可能なボリューム (or secret) をマウントしようとする
      • docker イメージが存在しないかアクセスできない (e.g. パーミッション問題により)
  4. コンテナが開始される場合 ; 前のセクションの手順に従ってコンテナのログを確認してください。
 

以上






Kubeflow 1.0 : コンポーネント : メタデータ

Kubeflow 1.0 : コンポーネント : メタデータ (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/09/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

コンポーネント : メタデータ

メタデータ プロジェクトの目標は Kubeflow ユーザが (ワークフローが生成する) メタデータを追跡して管理することにより機械学習 (ML) ワークフローを理解して管理することを手助けすることです。

このコンテキストでは、実行, モデル, データセットそして他の artifacts についての情報を意味します。artifact は貴方の ML ワークフローでコンポーネントの入力と出力を形成するファイルとオブジェクトです。

 

メタデータ・コンポーネントをインストールする

Kubeflow v0.6.1 とその後のバージョンはデフォルトで Metadata コンポーネントをインストールします。Kubeflow v0.6.1 or later を実行している場合、このセクションはスキップできます。

Metadata コンポーネントの最新版をインストールするかコンポーネントを Kubernetes クラスタのアプリケーションとしてインストールすることを望む場合、これらのステップに従ってください :

  1. Kubeflow manifests レポジトリをダウンロードします :
    git clone https://github.com/kubeflow/manifests
    
  2. Metadata コンポーネントのサービスを配備するために次のコマンドを実行します :
    cd manifests/metadata
    kustomize build overlays/db | kubectl apply -n kubeflow -f -
    

 

メタデータを記録するために Metadata SDK を使用する

Metadata プロジェクトは Python SDK (API リファレンスソース) を公開しています、これを貴方のメタデータを記録するために利用できます。

Metadata SDK をインストールするには次のコマンドを実行します :

pip install kubeflow-metadata

 

サンプル Jupyter ノートブックで Metadata SDK を試す

Metadata SDK をどのように使用するかのサンプルをこの demo ノートブック で見つけることができます。

ノートブックを Kubeflow クラスあで実行するには :

  1. setting up your Jupyter notebooks in Kubeflow へのガイドに従う。
  2. GitHub の demo ノートブック に進む。
  3. ファイルの Raw ビューを開くことでノートブックコードをダウンロードしてから、コンテンツ上で右クリックしてファイルを demo.ipynb としてローカルにセーブします。
  4. Kubeflow UI の Jupyter ノートブック・サーバに戻ります。(Kubeflow のノートブック・セクションから離れて移動した場合、そこに戻るには左手のナビゲーション・パネルの Notebook Servers をクリックします。)
  5. Jupyter ノートブック UI で、demo.ipynb ノートブックをアップロードするには Upload をクリックしてプロンプトに従います。
  6. Kubeflow クラスタでノートブックを開くにはノートブック名 (demo.ipynb) をクリックします。
  7. Metadata SDK をインストールして使用するにはノートブックのステップを実行します。

demo.ipynb ノートブックのステップを通した実行を完了したとき、Kubeflow UI 上で結果としてのメタデータを見ることができます :

  1. Kubeflow UI の左手のナビゲーション・パネルの Artifact Store をクリックします。
  2. Artifacts スクリーン上で次の項目を見るはずです :
    • 名前 MNIST を持つ モデル メタデータ項目。
    • 名前 MNIST-evaluation を持つ メトリクス メタデータ項目。
    • 名前 mytable-dump を持つ データセット メターデータ項目。

    詳細を見るために各項目の名前をクリックできます。Metadata UI についてより多くの詳細は下のセクションを見てください。

 

Metadata SDK について更に学習する

Metadata SDK は次の事前定義された型を含みます、貴方の ML ワークフローを記述するためにこれを使用できます :

  • DataSet, データセットのためのメタデータを捕捉するため、これは貴方のワークフローでコンポーネントへの入力やコンポーネントの出力を形成します。
  • Execution, ML ワークフローの実行のためのメタデータを捕捉するため。
  • Metrics, ML モデルを評価するために使用されるメトリクスのためのメタデータを捕捉するため。
  • Model, ワークフローが生成する ML モデルのためのメタデータを捕捉するため。

 

メタデータを記録するためにメタデータ・ウォッチャーを使用する

メタデータを直接ロギングするために Python SDK を使用することに加えて、Kubernetes リソースの変化を監視してメタデータをメタデータ・サービスにセーブするために貴方自身の メタデータ・ウォッチャー を追加することができます。

 

メタデータ UI 上で artifacts を追跡する

Kubeflow UI 上の Artifact Store でロギングされた artifacts のリストと各個別の artifact の詳細を見ることができます。

  1. 貴方のブラウザの Kubeflow に行きます。(Kubeflow UI をまだ開いていない場合、どのように セントラル・ダッシュボードにアクセスする かを見つけてください。)
  2. 左手のナビゲーション・パネルの Artifact Store をクリックします :

     

  3. Artifacts スクリーンは貴方のワークフローがロギングした総てのメタデータイベントのための項目のリストを開いて表示します。詳細を見るために各項目の名前をクリックできます。
     
    次のサンプルは で説明された demo.ipynb ノートブックを実行するとき現れる項目を示します :

    • 名前 “MNIST” を持つ モデル メタデータのサンプル :

    • 名前 “MNIST-evaluation” を持つ メトリクス メタデータのサンプル :

    • 名前 “mytable-dump” を持つ データセット メタデータのサンプル :

 

GRPC バックエンド

Kubeflow メタデータはメタデータと関係を管理するために ML メタデータ (MLMD)gRPC サービス を配備します。

Kubeflow メタデータ SDK は gRPC サービスを通してデータをセーブして取得します。同様に、貴方のカスタム artifacts のためのメタデータをロギングして見るために貴方自身のメタデータ型を定義することができます。Python サンプルについては、MLMD Python クライアント と Kubeflow メタデータ SDK ソースコード を確認できます。Go サンプルについては、メタデータ・ウォッチャーソースコード を確認できます。

 

以上






Kubeflow 1.0 : コンポーネント : 登録フロー

Kubeflow 1.0 : コンポーネント : 登録フロー (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/09/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

コンポーネント : 登録フロー

このガイドは最初に Kubeflow にログインしている Kubeflow ユーザのためです。

ユーザは Kubeflow を配備した人か、あるいは Kubeflow クラスタにアクセスする許可を持ち Kubeflow を使用する別の人です。

 

名前空間へのイントロダクション

貴方の Kubeflow クラスタのセットアップに依拠して、最初に Kubeflow にログインするとき名前空間を作成する必要があるかもしれません。名前空間は時に プロフィール または ワークグループ と呼ばれます。

Kubeflow は次の環境下で名前空間を作成することを促します :

  • マルチユーザ分離 (= isolation) をサポートする Kubeflow 配備について : 貴方のユーザ名は名前空間への管理者 (オーナー) 権限アクセスを与えるロールバインディングを持つ関連する名前空間をまだ持ちません。
  • シングルユーザ分離をサポートする Kubeflow 配備について : Kubeflow クラスタは名前空間ロールバインディングを持ちません。

Kubeflow が名前空間を作成することを貴方に促さない場合、Kubeflow 管理者が貴方のために名前空間を作成したのかもしれません。Kubeflow セントラル・ダッシュボードを見て Kubeflow を使用し始めることができるはずです。

 

前提条件

Kubeflow 管理者は次のステップを遂行しなければなりません :

 

名前空間を作成する

貴方がユーザ名に関連する適切な名前空間をまだ持たない場合、最初にログインするとき Kubeflow は次のスクリーンを表示します :

貴方の名前空間をセットアップするために Start Setup をクリックしてスクリーン上の指示に従います。名前空間のためのデフォルト名は貴方のユーザ名です。

名前空間作成後、スクリーンのトップのドロップダウン・リストで利用可能な貴方の名前空間を持つ、Kubeflow セントラル・ダッシュボードを見るはずです :

 

以上






Kubeflow 1.0 : コンポーネント : セントラル・ダッシュボード

Kubeflow 1.0 : コンポーネント : セントラル・ダッシュボード (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/09/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

コンポーネント : セントラル・ダッシュボード

Kubeflow 配備はクラスタに配備された Kubeflow コンポーネントへの素早いアクセスを提供するセントラル・ダッシュボードを含みます。ダッシュボードは次の特徴を含みます :

  • 特定のアクションへのショートカット、最近のパイプラインとノートブックのリスト、そしてメトリックス、1 つのビューでジョブとクラスタの概要を与えます。
  • パイプラインKatibノートブック 以上を含む、クラスタで動作するコンポーネントの UI のための筐体 (= housing)。
  • 新しいユーザに必要であれば彼らの名前空間をセットアップすることを促すための 登録フロー

 

Kubeflow UI の概要

Kubeflow UI は以下を含みます :

  • Home, Kubeflow コンポーネント間のナビゲーションのためのセントラル・ダッシュボード。
  • パイプライン, Kubeflow パイプライン・ダッシュボードのため。
  • ノートブック・サーバ, Jupyter ノートブックのため。
  • Katib, ハイパーパラメータ調整のため。
  • Artifact ストア, artifact メタデータを追跡するため。
  • Manage Contributors, Kubeflow 配備の名前空間に渡るユーザアクセスを共有するため。

セントラル・ダッシュボードはこのように見えます :

 

セントラル・ダッシュボードにアクセスする

セントラル・ダッシュボードにアクセスするには、Istio ゲートウェイ に接続する必要があります、これは Kubeflow サービス網 へのアクセスを提供します。

Istio ゲートウェイにどのようにアクセスするかはそれをどのように configure したかに依拠して様々です。

 

Google Cloud Platform (GCP) での URL パターン

deploying Kubeflow on GCP へのガイドに従った場合、Kubeflow セントラル UI は次のパターンの URL でアクセスできます :

https://<application-name>.endpoints..cloud.goog/

この URL は上で図示されたダッシュボードを送り込みます。

Cloud Identity-Aware Proxy (IAP) で Kubeflow を配備する場合、Kubeflow は Kubeflow UI のための SSL 証明書を提供するために Let’s Encrypt サービスを利用します。貴方の証明書での troubleshooting 問題については Cloud IAP セットアップを監視する へのガイドを見てください。

 

kubectl の利用とポートフォワーディング

Kubeflow を identity プロバイダーと統合するように configure していない場合、Istio ゲートウェイに直接ポートフォワードできます。

ポートフォワーディングは以下のいずれかが真であれば典型的には動作しません :

  • GCP 配備 UI または CLI 配備 によるデフォルト設定を使用して GCP 上で Kubeflow を配備した (ポートフォワーディングを使用することを望む場合、Kubeflow を kfctl_k8s_istio configuration を使用して既存の Kubernetes クラスタ上に配備しなければなりません)。
  • Istio ingress を特定のドメインか IP アドレスの HTTPS トラフィックだけを受け取るように configure した。
  • Istio ingress を (例えば、Cloud IAP や Dex を使用して) 認証チェックを遂行するように Istio Ingress を configura した。

次のように kubectl を通して Kubeflow にアクセスしてポートフォワーディングできます :

  1. kubectl をインストールします、まだそうしていないのであれば :
    • GCP 上で Kubeflow を使用している場合、コマンドラインで次のコマンドを実行します: “gcloud components install kubectl”
    • あるいは、kubectl インストールガイド に従います。
  2. Istio ゲートウェイへのポートフォワーディングをセットアップするために次のコマンドを使用します。
    export NAMESPACE=istio-system
    kubectl port-forward -n istio-system svc/istio-ingressgateway 8080:80
    
  3. セントラル・ナビゲーション・ダッシュボードに次でアクセスします :
    http://localhost:8080/
    

    Kubeflow をどのように configure したかに依拠して、リバースプロキシへのポートフォワーディングの背後で総ての UI が動作はしません。

    幾つかの web アプリケーションについては、app がサーブするベース URL を configure する必要があります。

    例えば、https://example.mydomain.com の ingress サービングとともに Kubeflow を配備してアプリケーションを URL https://example.mydomain.com/myapp でサーブされるように configure した場合、app は https://localhost:8080/myapp でサーブされたとき動作しないかもしれません、何故ならばパスが一致しないからです。

 

以上






Kubeflow 1.0 : Getting Started : Kubeflow 概要

Kubeflow 1.0 : Getting Started : Kubeflow 概要 (翻訳/解説)

翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 04/08/2020 (1.0)

* 本ページは、Kubeflow の以下のページを翻訳した上で適宜、補足説明したものです:

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

Getting Started : Kubeflow 概要

このガイドは機械学習 (ML) システムを開発して配備するためのプラットフォームとしての Kubeflow を紹介します。

Kubeflow は ML パイプラインを構築して実験することを望むデータサイエンティストのためのプラットフォームです。Kubeflow はまた ML システムを開発、テストと製品レベルサービングのための様々な環境に配備することを望む ML エンジニアと運用チームのためでもあります。

 

概念的概要

Kubeflow は Kubernetes のための ML ツールキットです。次の図は Kubeflow を Kubernetes 上に貴方の ML システムのコンポーネントを配置するためのプラットフォームとして示しています :

Kubeflow は複雑なシステムを配備、スケーリング、そして管理するためのシステムを Kuberunetes 上に構築します。Kubeflow configuration インターフェイスを使用して ( 参照)、貴方のワークフローに必要な ML ツールを指定できます。それからワークフローを実験と製品ユースのために様々なクラウド、ローカル、そしてオンプレミス・プラットフォームに配備できます。

 

ML ワークフローを紹介する

ML システムを開発して配備するとき、ML ワークフローは典型的には幾つかのステージから成ります。ML システムの開発は反復プロセスです。ML ワークフローの様々なステージの出力を評価してモデルが必要な結果を生成し続けることを確かなものにするため必要な時にはモデルとパラメータに変更を適用する必要があります。

単純化のため、次の図はワークフロー・ステージを順番に示します。ワークフローの最後の矢印はプロセスの反復的性質を示すためにフローに差し戻しています :

ステージをより詳細に見ます :

  • 実験フェーズでは、初期仮定に基づいてモデルを開発し、求める結果を生成するためにモデルを反復的にテストして更新します :
    • ML システムに解くことを望む問題を明らかにする。
    • ML モデルを訓練するために必要なデータを集めて解析する。
    • ML フレームワークとアルゴリズムを選択し、そしてモデルの初期バージョンをコーディングする。
    • データで実験してモデルを訓練する。
    • 最も効率的な処理と可能な最も正確な結果を確実にするようにモデルハイパーパラメータを調整する。
  • プロダクションフェーズでは、次のプロセスを遂行するシステムを配備します :
    • データを訓練システムが必要とする形式に変換する。モデルが訓練と予測の間に一貫して動作することを確実にするため、変換プロセスは実験とプロダクションフェーズで同じでなければなりません。
    • ML モデルを訓練する。
    • オンライン予測やバッチモードでの実行のためにモデルをサーブする。
    • モデルのパフォーマンスを監視し、モデルを調整または再訓練するために結果をプロセスに供給します。

 

ML ワークフローの Kubeflow コンポーネント

次の図は Kubeflow をワークフローに追加し、各ステージでどの Kubeflow コンポーネントが有用であるかを示します :

更に学習するため、Kubeflow コンポーネントへの次のガイドを読んでください :

  • Kubeflow は Jupyter ノートブックを起動して管理するためのサービスを含みます。ML ワークフローによる対話的データサイエンスと実験のためにノートブックを利用します。
  • Kubeflow パイプライン は Docker コンテナに基づくマルチステップ ML ワークフローを構築し、配備し、そして管理するためのプラットフォームです。
  • Kubeflow はマルチプラットフォームに渡り ML 訓練、ハイパーパラメータ調整、そしてワークロードのサービングを構築するために使用できる幾つかの コンポーネント を提供します。

 

特定の ML ワークフローのサンプル

次の図は特定の ML ワークフローの単純なサンプルを示します、これは MNIST データセット上で訓練されるモデルを訓練してサーブするために利用できます :

ワークフローの詳細についてそしてシステムを貴方自身で実行するためには、end-to-end チュートリアル for Kubeflow on GCP を見てください。

 

Kubeflow インターフェイス

このセクションは Kubeflow と相互作用するためにそして Kubeflow 上で ML ワークフローを構築して実行するために使用できるインターフェイスを紹介します。

 

Kubeflow ユーザ・インターフェイス (UI)

Kubeflow UI はこのように見えます :

UI は Kubeflow 配備のコンポーネントにアクセスするために利用できる中心的なダッシュボードを提供します。how to access the central dashboard を読んでください。

 

Kubeflow コマンドライン・インターフェイス (CLI)

Kfctl は Kubeflow をインストールして configure するために利用できる Kubeflow CLI です。Kubeflow を構成する ためのガイドの kfctl について読んでください。

Kubernetes CLI, kubectl, は Kubeflow クラスタに対してコマンドを実行するために有用です。アプリケーションを配備し、クラスタリソースを調査して管理し、そしてログを見るために kubectl を利用できます。Kubernetes ドキュメント の kubectl について読んでください。

 

Kubeflow API と SDK

Kubeflow の様々なコンポーネントが API と Python SDK を提供します。リファレンス・ドキュメントの次のセットを見てください :

 

以上






AI導入支援 #2 ウェビナー

スモールスタートを可能としたAI導入支援   Vol.2
[無料 WEB セミナー] [詳細]
「画像認識 AI PoC スターターパック」の紹介
既に AI 技術を実ビジネスで活用し、成果を上げている日本企業も多く存在しており、競争優位なビジネスを展開しております。
しかしながら AI を導入したくとも PoC (概念実証) だけでも高額な費用がかかり取組めていない企業も少なくないようです。A I導入時には欠かせない PoC を手軽にしかも短期間で認知度を確認可能とするサービの紹介と共に、AI 技術の特性と具体的な導入プロセスに加え運用時のポイントについても解説いたします。
日時:2021年10月13日(水)
会場:WEBセミナー
共催:クラスキャット、日本FLOW(株)
後援:働き方改革推進コンソーシアム
参加費: 無料 (事前登録制)
人工知能開発支援
◆ クラスキャットは 人工知能研究開発支援 サービスを提供しています :
  • テクニカルコンサルティングサービス
  • 実証実験 (プロトタイプ構築)
  • アプリケーションへの実装
  • 人工知能研修サービス
◆ お問合せ先 ◆
(株)クラスキャット
セールス・インフォメーション
E-Mail:sales-info@classcat.com