Implementation:Kubeflow Kubeflow Manifests Vs Packaged Decision
| Knowledge Sources | |
|---|---|
| Domains | Kubeflow, Platform Deployment, Architecture Decision |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Concrete tool for selecting the Kubeflow installation method provided by the Kubeflow documentation and manifests repository.
Description
This implementation documents the decision process for choosing between Kubeflow Manifests and Packaged Distributions. There is no API call or CLI command to execute. Instead, the operator evaluates their organizational requirements against the capabilities of each path and records the decision. The Kubeflow README at lines 41-53 lists the core components (Central Dashboard, Profile Controller) and references the manifests repository, which serves as the entry point for the self-managed path.
Usage
Use this decision framework at the start of any new Kubeflow deployment project, during architecture reviews, or when re-evaluating the current installation strategy. The decision should be documented and agreed upon by the platform team before proceeding.
Code Reference
Source Location
- Repository: kubeflow/kubeflow
- File: README.md (lines 41-53)
Signature
# No CLI command — this is a decision gate.
# The operator selects one of the following paths:
# Path A: Kubeflow Manifests (self-managed)
git clone https://github.com/kubeflow/manifests.git
cd manifests
# Path B: Packaged Distribution (vendor-managed)
# Follow vendor-specific installation guide (e.g., GCP, AWS, Azure)
Import
# For Path A: Clone the manifests repository
git clone https://github.com/kubeflow/manifests.git
cd manifests
git checkout v1.9.0 # Pin to a specific release tag
I/O Contract
Inputs
| Name | Type | Required | Description |
|---|---|---|---|
| Prerequisites validation results | validation report | Yes | Confirmed kubectl, kustomize versions and cluster access from the Prerequisites Validation step |
| Organizational requirements | document | Yes | Control needs, cloud provider, support contract requirements, team Kubernetes expertise level |
| Target environment | string | Yes | Cloud provider (GCP, AWS, Azure) or on-premises/bare-metal |
| Upgrade strategy preference | string | No | Whether the team prefers manual manifest upgrades or vendor-managed lifecycle |
Outputs
| Name | Type | Description |
|---|---|---|
| Selected installation method | string | Either "Kubeflow Manifests" or a specific packaged distribution name |
| Manifests repository (if Path A) | git repository | Cloned kubeflow/manifests at a pinned release tag |
| Decision rationale | document | Recorded justification for the selected path |
Usage Examples
Basic Usage
# Decision: Using Kubeflow Manifests (Path A)
# Rationale: On-premises deployment, need full control, team has Kubernetes expertise
# Step 1: Clone the manifests repository at a stable release
git clone https://github.com/kubeflow/manifests.git
cd manifests
git checkout v1.9.0
# Step 2: Verify the repository structure
ls -la
# Expected: directories for each component (apps/, common/, contrib/)
# Step 3: Document the decision
# Record in your project wiki or architecture decision record (ADR)
# that Kubeflow Manifests was selected with the rationale above.