KEP for kfp helm charts

[XploY04]

Description of your changes:
Fixes #12728

Checklist:

• You have signed off your commits
• The title for your pull request (PR) should follow our title convention. Learn more about the pull request title convention used in this repository.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign humairak for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[google-oss-prow]

Hi @XploY04. Thanks for your PR.

I'm waiting for a kubeflow member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Copilot]

Pull request overview

Adds a KEP-style proposal document describing an approach to introducing official Helm charts for Kubeflow Pipelines (KFP), including goals around parity with existing Kustomize manifests, chart structure, and testing strategy.

Changes:

• Introduces a new proposal document for KFP Helm charts (motivation, goals/non-goals, design details, risks, and test plan).

[Copilot]

The KEP title still uses the placeholder KEP-XXXX. Other proposals in this repo use the numeric KEP ID in the header (and typically in the proposal directory name as well), so this should be updated to the correct number (likely matching the issue/KEP ID) to align with existing proposal conventions and make the document easier to reference.

Suggested change

	# KEP-XXXX: Helm Charts for Kubeflow Pipelines
	# KEP-1234: Helm Charts for Kubeflow Pipelines

[Copilot]

Grammar issue: “a minimalistic, and maintainable Helm charts” mixes singular/plural and has an unnecessary comma. Consider rephrasing to either singular (“a minimalistic and maintainable Helm chart”) or plural (“minimalistic and maintainable Helm charts”).

Suggested change

	This proposal is to build a minimalistic, and maintainable Helm charts for Kubeflow Pipelines (KFP). These charts will serve as an alternative installation method to Kustomize, reflecting Kustomize defaults 1:1 to ensure consistency across deployment options.
	This proposal is to build minimalistic and maintainable Helm charts for Kubeflow Pipelines (KFP). These charts will serve as an alternative installation method to Kustomize, reflecting Kustomize defaults 1:1 to ensure consistency across deployment options.

[Copilot]

This section says “three critical implementation challenges” but the list contains four items (1–4). Please update the count or adjust the list so the text matches the enumerated items.

Suggested change

	Beyond the surface-level YAMLs, we have identified three critical implementation challenges that the Helm chart must address to be viable:
	Beyond the surface-level YAMLs, we have identified four critical implementation challenges that the Helm chart must address to be viable:

[Copilot]

The “Dependency Management” section frames the relational DB dependency as MySQL-only, but later the proposal maps Kustomize patches from base/postgresql/... and the repo includes both MySQL and PostgreSQL install paths. To avoid confusion, clarify whether the Helm charts will support both DB backends (and which is default), or update the later examples to match the stated dependency.

Suggested change

	KFP has strict external dependencies, specifically **Object Storage (Minio/S3)** and **Relational Database (MySQL)**.
	- The Helm chart MUST provide a mechanism to:
	1. Provision in-cluster instances of Minio/MySQL (for easy testing/dev) - possibly via subcharts like `bitnami/mysql`.
	2. Configure connection details for external managed services (RDS/S3) - using a clean `values.yaml` structure for secrets/hosts.
	KFP has strict external dependencies, specifically **Object Storage (Minio/S3)** and **Relational Database (MySQL or PostgreSQL, defaulting to the same backend as the existing Kustomize manifests—currently MySQL)**.
	- The Helm chart MUST provide a mechanism to:
	1. Provision in-cluster instances of Minio plus a relational database (MySQL/PostgreSQL) for easy testing/dev — for example via subcharts like `bitnami/mysql` or a PostgreSQL equivalent.
	2. Configure connection details for external managed services (e.g., managed MySQL/PostgreSQL such as RDS, Cloud SQL, or Aurora, and object storage such as S3/GCS) — using a clean `values.yaml` structure for secrets/hosts.

[Goku2099]

Thanks for putting this together this is a very thoughtful and well-structured proposal. I especially like the explicit definition of 1:1 parity and the CI diffing approach to prevent drift between Helm and Kustomize.

One thought, since we’ve been emphasizing “minimal and maintainable” for the first iteration, would it make sense to explicitly define a V1 boundary (for example, single-user mode with one default DB backend) and defer multi-user + additional backends to follow-up phases?

It might help us validate the Helm testing and release workflow with a smaller surface area before expanding into the more complex overlays.

Curious to hear what others think about phasing this incrementally.

[juliusvonkohout]

I see multiple ones. 1. the general one kubeflow/community#832 2. KFP specific ones #12842 #12787 #12723

and some requirements from GSOC https://www.kubeflow.org/events/upcoming-events/gsoc-2026/#project-5-helm-charts

"
Details: This project continues the KSC-approved initiative to provide Kubeflow platform and standalone components via Helm. The goal is to move beyond Kustomize-only deployments to offer minimalistic, maintainable Helm charts that reflect Kustomize defaults 1:1. Key tasks include: developing and testing Helm charts for KFP and Katib, implementing CI/CD testing infrastructure for Helm-based deployments and coordinating with component maintainers to ensure cross-project consistency.

This project will touch most components and continue the helm chart initiative started by Kunal Dugar who also helped a lot with the testing infrastructure. This will therefore also include working with maintainers of other components such as KFP maintainersfor the KFP helm charts, security and scalability topic or Katib maintainers for Katib helm charts. Some have already open PRs and there was a formal vote by the KSC (Kubeflow steering Committee) that we are moving forward with offering Kubeflow platform and standalone components as helm charts. Therefore it is not just the technical part, but also the coordination effort. The goal is to make minimalistic helm charts that are easy to maintain next to kustomize and only expose sensible settings relevant to most users. For the time being the rendered chart default values must replicate kustomize 1:1. The testing infrastructure has already been set up in the GSOC 2025 efforts in kubeflow/manifests where we already have a few helm charts.
"

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[juliusvonkohout]

/close
since this is covered by @danish9039 within gsoc

[google-oss-prow]

@juliusvonkohout: Closed this PR.

Details

In response to this:

/close
since this is covered by @danish9039 within gsoc

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.