Kubeflowとは？Kubernetes上の機械学習基盤の全体像とPipelinesの使い方

Kubeflowは、機械学習のワークフローをKubernetes上で動かすためのオープンソースのプラットフォームです。GitHubの公式タグラインは「Machine Learning Toolkit for Kubernetes」で、モデルの実験・学習・パイプライン化・推論提供までを、Kubernetesのスケーラビリティに乗せて一元管理できます。ただしKubeflowは単一のツールではなく、Pipelines・Katib・KServeなど役割の異なるコンポーネントの集合体です。この記事では、まずKubeflow全体の構成を押さえたうえで、中核であるKubeflow Pipelinesの仕組みとKFP SDK v2でのパイプライン作成、ローカルでの試し方、そしてAirflowやMLflowとの使い分けまでを順に解説します。

まとめ：Kubeflowの要点

• 正体：Kubernetes上で機械学習を運用するためのプラットフォーム。CNCFのIncubatingプロジェクト（2023年7月受理、卒業前）。
• 構成：Pipelines（ワークフロー）・Katib（AutoML）・KServe（推論提供）・Kubeflow Trainer（分散学習）・Notebooks・Central Dashboardなどの集合。必要なコンポーネントだけを個別に導入することもできる。
• 中核：Kubeflow Pipelines（KFP）。現行はKFP SDK v2（kfp 2系）で、Pythonのデコレータでコンポーネントとパイプラインを定義し、コンパイルするとIR形式のYAMLが出力される。
• 試し方：本番はKubernetesクラスタが前提だが、kfp localを使えばクラスタ無しで単体のパイプラインをローカル実行できる。
• 使い分け：汎用ワークフローならAirflow、実験トラッキング中心ならMLflow、自前運用を避けたいならマネージドのVertex AI Pipelines。Kubernetesの運用体制が無いなら無理にKubeflowを選ばない。

Kubeflowとは何か：Kubernetesネイティブな機械学習プラットフォーム

Kubeflowは、機械学習のワークロード（データ処理・学習・ハイパーパラメータ探索・モデル提供）をKubernetes上で動かすことに特化したフレームワークです。Kubernetesがコンテナのスケジューリングやスケーリングを担い、Kubeflowがその上に機械学習ならではの作法（パイプライン、分散学習、推論サーバなど）を載せます。基盤にKubernetes（K8s）の仕組みを使うため、学習ジョブや推論を必要なだけ水平スケールできるのが特徴です。

Kubeflowが解決する課題

機械学習の開発では、前処理・学習・評価・デプロイといった処理がノートブックやスクリプトに散らばり、再現性やスケールで壁に当たります。Kubeflowはこれらをコンテナ化した処理単位としてKubernetes上に載せ、実験の記録・再実行・スケールを標準化します。これはMLOps（機械学習の運用）の実践基盤の一つという位置づけで、モデルを作って終わりにせず、継続的に運用するための足場になります。

CNCFプロジェクトとしての位置づけと最新版

KubeflowはもともとGoogle社内のTensorFlow運用の仕組みから生まれ、2023年7月25日にCNCF（Cloud Native Computing Foundation）のIncubatingプロジェクトとして受理されました。KubernetesやPrometheusと同じ財団の管理下にありますが、まだGraduated（卒業）段階ではありません。プラットフォームとしての最新版は2025年3月末に公開されたKubeflow 1.10で、各コンポーネントを束ねたリリースはkubeflow/manifestsリポジトリに集約されています。バージョンは頻繁に更新されるため、最新の対応状況は公式で確認してください。

Kubeflowを構成する主要コンポーネント

Kubeflowを「一つのツール」と捉えると混乱します。実際には役割の異なるコンポーネントが集まってプラットフォームを成しており、全部を導入する必要はありません。中核のPipelinesだけを単体で使う構成もよく取られます。主要コンポーネントは次のとおりです。

KServeは旧KFServing、Kubeflow Trainerは旧Training Operatorで、いずれも名称が整理された経緯があります。過去の記事や資料では旧名で書かれていることが多いので、同じものを指していると理解しておくと混乱しません。KServeのように、Kubeflowから独立したプロジェクトとしても運用されるコンポーネントもあります。

Kubeflow Pipelinesの仕組み：Pipeline・Component・Run

Kubeflowの中で最もよく使われるのがKubeflow Pipelines（KFP）です。「kfpとは」という検索が示すとおり、Kubeflowを触る入口はほぼここになります。KFPは機械学習の一連の処理を、有向非巡回グラフ（DAG）として組み立てて実行する仕組みです。各ステップの内側で計算そのものを複数ノードへ分散させたい場合は、Rayとは？分散処理フレームワークの仕組みと採用判断で扱う分散実行基盤をコンポーネント内に組み合わせる構成が取れます。

KFPを構成する基本概念

用語を最初に押さえると全体像が掴めます。

• Component（コンポーネント）：前処理・学習といった1ステップ。コンテナとして実行される再利用可能な処理単位。
• Pipeline（パイプライン）：コンポーネントを入出力でつないだDAG全体。
• Run（実行）：パイプラインを実際に走らせた1回分の実行インスタンス。
• Experiment（実験）：関連するRunをまとめる単位。パラメータを変えた比較に使う。
• Artifact（アーティファクト）：コンポーネントが出力するモデルやデータ。メタデータとして追跡される。

コンポーネント間はパラメータ（小さな値）とアーティファクト（モデルやデータファイル）で結ばれ、どのRunがどの成果物を生んだかが記録されます。この追跡性が、スクリプトの寄せ集めとの決定的な違いです。

KFP SDK v2でのパイプライン定義

現行のKFP SDKはv2（kfp 2系。執筆時点の最新はkfp 2.17系）で、Pythonのデコレータでコンポーネントとパイプラインを定義します。次は2つの数値を足すだけの最小パイプラインです。

from kfp import dsl
from kfp import compiler

@dsl.component(base_image="python:3.11")
def add(a: float, b: float) -> float:
    return a + b

@dsl.pipeline(name="addition-pipeline")
def addition_pipeline(x: float = 1.0, y: float = 2.0):
    add(a=x, b=y)

# コンパイルするとIR形式のYAML（PipelineSpec）が出力される
compiler.Compiler().compile(addition_pipeline, "pipeline.yaml")

生成されたpipeline.yamlをKubeflowにアップロードして実行します。SDKから直接Runを作ることもできます。

from kfp.client import Client

client = Client(host="http://localhost:8080")
client.create_run_from_pipeline_package(
    "pipeline.yaml",
    arguments={"x": 3.0, "y": 4.0},
)

v1からv2への主な変更点

古い記事のコードをそのまま動かそうとすると、ここでつまずきます。v1で中心だったContainerOpクラスはv2で削除され、コンポーネントは@dsl.component（Python関数から生成）や@dsl.container_componentで定義する形に変わりました。コンパイル結果も、v1のArgo依存のYAMLから、バックエンド非依存のIR YAML（PipelineSpec）へと統一されています。v1向けに書かれたパイプラインコードは、v2ではそのまま動かないため、公式の移行ガイドに沿った書き換えが必要です。既存のコンポーネントYAMLはload_component_from_fileで後方互換的に読み込めます。

Kubeflowの試し方：ローカル検証から本番デプロイまで

フルのKubeflowはKubernetesクラスタ前提でリソース要求も大きいため、いきなり全部を立てる必要はありません。目的に応じて段階を選べます。

kfp localによるクラスタ無し検証

パイプラインのロジックだけを手元で確認したいなら、kfp localが最短です。local.init()でランナーを初期化すると、コンポーネントを通常のPython関数のように呼び出して結果を得られます。

from kfp import local

local.init(runner=local.SubprocessRunner())

task = add(a=1.0, b=2.0)
print(task.output)   # 3.0 のように結果を直接取得できる

ランナーは軽量なSubprocessRunner（サブプロセス実行）と、本番に近いDockerRunner（コンテナ実行）から選べます。ただしキャッシュやリトライといった本番機能は動かないため、あくまでロジック検証用と割り切ります。

minikube・kindでのローカル実行

Kubernetesの検証環境であるminikubeやkind上にデプロイすれば、UIを含む本来の挙動を試せます。フルのKubeflow Platformは必要メモリが大きいため、パイプラインだけ試すならKFPを単体で入れるstandalone構成が現実的です。

本番デプロイとマネージド利用

本番運用では、kubeflow/manifestsのリリースをkustomizeで自クラスタに適用するのが基本です。自前でKubernetesを運用したくない場合は、GoogleのVertex AI Pipelinesが選択肢になります。これはKFPをベースにしたマネージドサービスで、KFP SDKで書いたパイプラインをほぼそのままサーバーレス実行できます。なお、awslabsのKubeflow on AWSはアップストリーム（最新のKubeflow本体）への追随が停滞しており、最新版を前提にするなら注意が必要です。CanonicalのCharmed KubeflowやdeployKFといったディストリビューションもあります。

Kubeflowと他ツールの使い分け：Airflow・MLflow・Vertex AI

「kubeflow airflow」で検索されるように、KubeflowはAirflowやMLflowとよく比較されます。役割が重なって見えて実は守備範囲が違うので、まず全体像を表で整理します。

Apache Airflowとの違い

Apache AirflowはDAGでタスクをスケジュール・実行する汎用のワークフローエンジンで、機械学習専用の機能は持ちません。分散学習やモデルサービングは自分で組み込む必要があります。一方Kubeflowはそれらを最初からKubernetesネイティブに内包します。データ基盤全体のジョブ管理も含めて汎用的に回したいならAirflow、機械学習の学習〜提供までをKubernetes上で完結させたいならKubeflow、という切り分けになります。両者は排他ではなく、Airflowでデータ処理を回しつつKubeflowでML部分を担わせる併用も見られます。

MLflowとの違い

MLflowはインフラを問わず軽量に導入でき、実験のトラッキングとモデルのバージョニング・パッケージングが主眼です。Kubeflowのようにパイプラインの実行基盤やクラスタを持つわけではありません。したがってKubeflowとMLflowは競合というより補完関係で、KubeflowでオーケストレーションしながらMLflowで実験を記録する、という併用が定石です。まず実験管理から始めたい小規模チームはMLflow単体が手軽です。

Kubeflowを選ぶべきでない場面

Kubeflowは強力ですが、万能ではありません。次の条件に当てはまるなら、導入を急ぐべきではありません。Kubernetesの運用経験がチームに無い場合、Kubeflow自体の運用コスト（アップグレード、認証、リソース管理）が機械学習の生産性を上回り、かえって足を引っ張ります。モデルが1〜2個で実験の記録が主目的なら、MLflow単体で十分です。また自前クラスタの運用を避けたいなら、Vertex AI Pipelinesのようなマネージドから入るほうが立ち上がりは速くなります。Kubeflowが本領を発揮するのは、複数のモデルを継続的に学習・提供し、Kubernetes基盤を運用できる体制がある組織です。

よくある質問（FAQ）

KFPとは何ですか？

KFPはKubeflow Pipelinesの略で、機械学習のワークフローをDAGとして定義・実行・監視するKubeflowの中核コンポーネントです。同名のPython SDK（パッケージ名kfp）でパイプラインを記述し、コンパイルしてKubeflowにデプロイします。現行はv2系です。

KubeflowとMLflowの違いは何ですか？

Kubeflowは機械学習をKubernetes上で動かすエンドツーエンドのプラットフォーム（パイプライン・学習・サービング）で、MLflowはインフラ非依存で実験トラッキングとモデル管理を担う軽量ツールです。守備範囲が異なるため、オーケストレーションはKubeflow、記録はMLflowと併用されることも多くあります。

Kubeflowはローカルで試せますか？

試せます。パイプラインのロジックだけならkfp localでクラスタ無しに実行でき、UIを含めて動かしたい場合はminikubeやkind上にデプロイします。フルのKubeflow Platformはリソース要求が大きいため、軽く試すならKFP単体のstandalone構成が現実的です。

Kubeflow SDKとKFP SDKは違うものですか？

別物です。KFP SDK（kfp）はPipelinesを操作する従来からのSDKです。Kubeflow SDK（github.com/kubeflow/sdk、PyPIパッケージ名kubeflow）は、Trainer・Katibなど複数のコンポーネントを統一のPython APIから扱う新しいSDKで、まだ初期段階（実験的）の位置づけです。用途が固まるまでは公式の状況を確認して使い分けてください。

Kubeflow on AWSは今も使えますか？

awslabsが公開するKubeflow on AWSは公式に終了が告知されているわけではありませんが、最新リリースが2023年でアップストリームのKubeflow本体（1.10系）に追随できていません。最新機能を前提にするなら、EKS上に自前でmanifestsを適用するか、別のマネージド構成を検討するほうが無難です。

関連記事

• Kubernetes（クーベネティス）とは？読み方・K8sの意味から仕組みまで初心者向けに解説
• Apache Airflowを活用したビッグデータのワークフロー管理
• MLOpsとは？機械学習の運用を支える仕組みと導入判断をわかりやすく解説