Principle:Kubeflow Kubeflow Component Deployment
| Knowledge Sources | |
|---|---|
| Domains | Kubeflow, Platform Deployment, ML Infrastructure |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Component deployment is the process of selectively installing individual Kubeflow ML components into a prepared Kubernetes cluster using kustomize overlays applied via kubectl.
Description
After core infrastructure (Istio, cert-manager, Dex) is operational, operators deploy the Kubeflow ML components that their teams require. Kubeflow follows a modular architecture where each component is independently deployable via its own kustomize overlay directory. The primary components available for deployment include:
- Kubeflow Pipelines — workflow orchestration for ML pipelines
- Katib — hyperparameter tuning and neural architecture search
- Training Operator (Trainer) — distributed training job management (TrainJob CRD)
- Notebooks — Jupyter notebook server management
- KServe — model serving and inference (InferenceService CRD)
- Model Registry — centralized model metadata and artifact tracking
- Spark Operator — Apache Spark job management on Kubernetes
- Central Dashboard — unified web UI for accessing all Kubeflow components
Each component registers its own Custom Resource Definitions (CRDs) in the cluster, creates controllers in dedicated namespaces, and integrates with Istio for traffic management and with Dex for authentication. The deployment pattern is uniform: kustomize build <component-overlay> | kubectl apply -f -.
Operators can choose to deploy all components or a subset based on their ML platform requirements. This modularity is a key design principle of Kubeflow.
Usage
Deploy components in the following scenarios:
- Initial Kubeflow installation after core infrastructure is confirmed running
- Adding a new ML capability to an existing Kubeflow installation (e.g., adding KServe to an installation that previously only had Pipelines)
- Upgrading individual components to newer versions without redeploying the entire platform
- Replacing a component with an alternative (e.g., swapping Katib for a different hyperparameter tuning system)
Theoretical Basis
The component deployment process follows an iterative pattern for each selected component:
Step 1: Component Selection
- Review the list of available components against team requirements
- Identify dependencies between components (e.g., Central Dashboard depends on all other components being registered)
- Determine the deployment order: standalone components first, then components that aggregate or depend on others
Step 2: Per-Component Deployment
- For each selected component, execute: kustomize build <overlay-path> | kubectl apply -f -
- If the first apply results in errors due to CRD ordering, re-apply the same command (Kubernetes will reconcile)
- Wait for the component controller pods to reach Running state before proceeding to the next component
Step 3: CRD Registration Verification
- After deploying each component, verify its CRDs are registered in the cluster
- For Trainer: confirm TrainJob CRD exists
- For Katib: confirm Experiment CRD exists
- For KServe: confirm InferenceService CRD exists
- For Pipelines: confirm pipeline-related CRDs exist
Step 4: Central Dashboard Deployment
- Deploy Central Dashboard last, after all other components are running
- Central Dashboard discovers and displays links to all registered components
- Verify the Dashboard is accessible through the Istio ingress gateway
Deployment Order Recommendation:
- Kubeflow Pipelines
- Training Operator
- Katib
- Notebooks
- KServe
- Model Registry
- Spark Operator
- Central Dashboard