#Kubeflow Pipelines 执行和存储行为

由 Alauda kfp-operator v26.3.1 或 Data Science Pipelines Operator (DSPO) v2.15.2 安装的 Kubeflow Pipelines 2.16.1 支持任务缓存、dsl.ParallelFor、类型化 KFP artifacts，以及在 amd64 和 arm64 集群上的 S3 兼容 artifact 持久化。这些机制都是 KFP 的功能；operator 负责配置 API server、workflow controller、cache server 和 artifact store 来实现它们。

#功能概览

下面链接的验证 pipeline 是在 x86 集群上使用 DSPO 运行的。它生成了一个 Dataset，由三个 ParallelFor 任务读取，然后再次提交完全相同的 pipeline。三个消费者都成功了，第二次运行中的四个 executor task 因为缓存结果被复用而被报告为 SKIPPED。在 workflow pod 完成后，该 dataset 对象仍然存在于 S3 中。

#安全地缓存任务

默认情况下，运行会启用缓存。提交编译后的 package 时也可以进行设置：

client.create_run_from_pipeline_package(
    pipeline_file="pipeline.yaml",
    arguments={"dataset_version": "2026-07-23"},
    enable_caching=True,
)

对于具有外部副作用或可变输入的任务，请禁用缓存：

task = publish_report(...)
task.set_caching_options(False)

KFP 会根据 component 及其声明的输入计算 cache key。它无法检测未更改的 S3 object key、URL、database query 或 image tag 背后的内容是否发生了变化。当需要新的外部内容使 cache 失效时，请传入不可变的 object version、digest 或显式的 version 参数。

#使用 ParallelFor 运行任务

当同一个 component 可以处理彼此独立的项时，请使用 dsl.ParallelFor：

from kfp import dsl


@dsl.pipeline(name="parallel-evaluation")
def evaluation_pipeline():
    dataset = produce_dataset()
    with dsl.ParallelFor(
        items=["accuracy", "precision", "recall"],
        parallelism=3,
    ) as metric:
        evaluate(dataset=dataset.outputs["dataset"], metric=metric)

controller 会为每个项创建一个 evaluate 任务。当 namespace quota、node 容量或外部 API 无法同时承载所有迭代时，请将 parallelism 设为低于项数的值。

#持久化并传递类型化 artifact

将文件写入输出 artifact 提供的路径。不要自行构造本地路径并期望它能在 producer pod 中保留下来：

from kfp import dsl


@dsl.component(base_image="python:3.12-slim")
def produce_dataset(dataset: dsl.Output[dsl.Dataset]):
    from pathlib import Path

    output = Path(dataset.path)
    output.parent.mkdir(parents=True, exist_ok=True)
    output.write_text("value\n42\n", encoding="utf-8")
    dataset.metadata["rows"] = 1


@dsl.component(base_image="python:3.12-slim")
def consume_dataset(dataset: dsl.Input[dsl.Dataset]):
    from pathlib import Path

    print(Path(dataset.path).read_text(encoding="utf-8"))

将 producer.outputs["dataset"] 传递给 consumer 会建立依赖关系。KFP launcher 会把 producer 的文件上传到 artifact store，并在 consumer pod 中将其 materialize 到 dataset.path。

这与 KFP workspace PVC 不同：

#运行验证 pipeline

下载 verify-kfp-features.py ，并在可以访问 KFP API 的 Workbench 或其他环境中运行它：

python -m pip install 'kfp==2.16.1'

export KFP_ENDPOINT='http://<kfp-api-service>:8888'
export KFP_NAMESPACE='my-pipeline-namespace'
python verify-kfp-features.py

该脚本会编译一个 producer 和三个并行 consumer，使用相同参数提交两次，并在以下任一条件不满足时失败：

• 第一次运行成功；
• 恰好有三个 verify-dataset 任务成功；
• 每个 consumer 都读取了 producer 的 Dataset 内容；并且
• 第二次运行将缓存任务报告为 SKIPPED。

最终输出中，每种机制都会有一行 PASS。管理员可以在 pod 结束后，通过列出 KFP artifact bucket 中的 run prefix 来独立确认持久化情况。

#在 arm64 集群上部署

Alauda KFP 2.16.1 版本为 linux/amd64 和 linux/arm64 都打包了 pipeline service 和 runtime images。可选的 kfp-metadata-writer image 仍然仅支持 amd64。DSPO 不部署此组件；Alauda kfp-operator 必须在 arm64 上将其禁用。

#kfp-operator

使用 Alauda kfp-operator v26.3.1 时，请先从 OperatorHub 正常安装 operator，并在 reconciliation 之前将 KubeflowPipelines custom resource 中可选的 metadata writer 设为 false：

apiVersion: operator.alauda.io/v1
kind: KubeflowPipelines
metadata:
  name: kubeflowpipelines
spec:
  global:
    images:
      kfpMetadataWriter:
        enabled: false

保留 release sample 中其余的 spec.global.images 值不变。support_arm image 字段仅控制打包/image 迁移；它不会禁用 Deployment。请在 reconciliation 后验证 writer 不存在：

kubectl -n kubeflow get deployment metadata-writer
# Error from server (NotFound) is expected

#Data Science Pipelines Operator (DSPO)

DSPO v2.15.2 中的 V2 reconciler 不会部署 kfp-metadata-writer。无需 arm64 覆盖。使用常规 V2 设置创建 DSPA，并且不要添加 MLMD writer 字段：

apiVersion: datasciencepipelinesapplications.opendatahub.io/v1
kind: DataSciencePipelinesApplication
metadata:
  name: sample
  namespace: data-science-project
spec:
  dspVersion: v2
  mlmd:
    deploy: true

验证该 namespace 包含 MLMD gRPC/Envoy 资源，但没有 metadata-writer Deployment。DSPO 和 kfp-operator 彼此互斥；每个集群只能选择一种安装模型。

#平台兼容性和数据库后端

以下结果适用于与 KFP 2.16.1 对齐的 Alauda 构建：

这些 release 中所有必需的 runtime images 都有 amd64 和 arm64 manifest，kfp-metadata-writer 除外。只有 arm64 的 Alauda kfp-operator 安装需要禁用该组件；它不是 DSPO deployment 的一部分。

当前这两个 operator 都只暴露 MySQL 连接设置。DSPO 使用 MySQL driver 执行外部数据库健康检查，并渲染 DB_DRIVER_NAME=mysql。kfp-operator chart 会渲染 dbType=mysql、DBDriverName=mysql 和 DBCONFIG_MYSQLCONFIG_*。将任一 operator 指向 PostgreSQL endpoint 都不会切换其 driver，也不会生成可用的 KFP 安装。在 operator 接口中接入 PostgreSQL driver 选择以及上游 PostgreSQL deployment 补丁之前，请继续使用 MySQL。