Principle:Kubeflow Kubeflow Installation Method Selection
| Knowledge Sources | |
|---|---|
| Domains | Kubeflow, Platform Deployment, Architecture Decision |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Installation method selection is the decision gate where operators choose between deploying Kubeflow via raw manifests (full control, self-managed) or through a packaged distribution (vendor-supported, opinionated defaults).
Description
Kubeflow offers two primary installation paths. The first is Kubeflow Manifests, hosted in the kubeflow/manifests repository, which provides raw kustomize overlays that operators apply directly to their Kubernetes cluster. This path grants maximum flexibility and control over every component, namespace, and configuration, but places the full operational burden on the deploying team. The second path is Packaged Distributions, provided by vendors such as Google (AI Platform Pipelines), AWS (Kubeflow on AWS), Azure, and others. These distributions bundle Kubeflow components with cloud-native integrations, managed identity, and vendor support contracts, but limit customization options.
This principle does not involve any API call or tool invocation. It is a decision gate that must be resolved before proceeding to core infrastructure deployment. The choice affects every downstream step in the workflow, including how Istio, cert-manager, and Dex are provisioned, how components are deployed, and how upgrades are managed over time.
Usage
Apply this decision gate in the following scenarios:
- A new Kubeflow installation is being planned
- An organization is migrating from one installation method to another
- A team is evaluating whether to adopt Kubeflow for the first time
- The current installation method is causing operational friction and alternatives are being considered
Theoretical Basis
The decision framework evaluates the following criteria:
Criterion 1: Control vs. Convenience
- If the team requires fine-grained control over every component version, namespace layout, and network policy, select Kubeflow Manifests
- If the team prefers opinionated defaults and reduced operational overhead, select a Packaged Distribution
Criterion 2: Cloud Provider Alignment
- If the deployment targets a specific cloud provider (GCP, AWS, Azure) and the team wants native integrations (IAM, managed Istio, cloud storage), evaluate the corresponding packaged distribution
- If the deployment targets bare-metal, on-premises, or multi-cloud environments, Kubeflow Manifests is typically the only viable option
Criterion 3: Support Requirements
- If the organization requires vendor support contracts and SLAs, a Packaged Distribution is preferred
- If the team has Kubernetes expertise and is comfortable with community support, Kubeflow Manifests is viable
Criterion 4: Upgrade and Lifecycle Management
- Kubeflow Manifests requires manual tracking of upstream releases and applying kustomize diffs
- Packaged Distributions often provide managed upgrade paths with version compatibility guarantees
Decision Output:
- If Kubeflow Manifests is selected, proceed to Core Infrastructure Deployment using the kubeflow/manifests repository
- If a Packaged Distribution is selected, follow the vendor-specific installation guide