Kubeflow: ML Pipelines on Kubernetes

Khimananda Oli 9 min read Virtualization
Kubeflow: ML Pipelines on Kubernetes

By Khimananda Oli | Last reviewed: August 2026

Moving machine learning from experimental notebooks to reliable production systems remains one of the hardest challenges in modern engineering. Kubeflow: ML Pipelines on Kubernetes solves this by treating ML workflows as first-class cloud-native applications rather than fragile scripts. It provides a portable, scalable orchestration layer that integrates directly with your existing infrastructure, enabling reproducible training runs and automated deployments. If you are already operating clusters using patterns from our MLOps from notebook to production guide, Kubeflow is the logical next step to enforce standardization.

Kubeflow Platform ArchitectureKFP SDKPython DSL / YAMLAPI ServergRPC / RESTArgo WorkflowsDAG OrchestratorML MetadataLineage TrackingMinIO / S3Artifact StoreKubernetesCompute / GPU
High-level architecture of Kubeflow: ML Pipelines on Kubernetes showing the flow from SDK definition through orchestration to storage and compute.

What is Kubeflow: ML Pipelines on Kubernetes and why use it?

Kubeflow Pipelines (KFP) is the workflow orchestration engine at the heart of the Kubeflow ecosystem. While Kubeflow itself is a collection of tools for notebooks, training operators, and model serving, KFP specifically addresses the reproducibility crisis in machine learning. In practice, most teams start with Jupyter notebooks that work locally but fail when handed to operations because they lack dependency isolation, versioned parameters, or defined resource requests. KFP forces you to containerize every step, making the pipeline portable across any conformant Kubernetes cluster.

The primary value proposition is lineage and auditability. Every run generates a complete record of inputs, outputs, container images, and execution logs stored in ML Metadata (MLMD). For organizations pursuing SOC 2 or ISO 27001 compliance, this automated evidence collection is invaluable. You can trace exactly which dataset version produced a specific model artifact without digging through Slack history or local filesystems. This aligns with the observability principles discussed in our monitoring ML models in production article, extending visibility from runtime metrics back to training provenance.

Beyond compliance, KFP enables genuine collaboration. Data scientists define logic in Python; platform engineers manage the underlying infrastructure; and auditors verify the process—all through the same interface. The decoupling of pipeline definition from execution means you can develop locally on Kind or Minikube and deploy to EKS, GKE, or AKS without rewriting code. This portability prevents vendor lock-in, a critical consideration for Nepali tech companies and global startups alike who need flexibility in cloud provider selection.

How do you install Kubeflow Pipelines on a production cluster?

Installation is where many teams stumble. Avoid the "full Kubeflow" distribution unless you need every component (Notebooks, Katib, KServe). For pure pipeline orchestration, the standalone KFP installation is lighter, easier to upgrade, and less prone to CRD conflicts. As of 2026, the recommended approach uses Kustomize with environment-specific overlays.

Prerequisites and Cluster Sizing

  • Kubernetes Version: v1.28+ required for current KFP v2.x releases.
  • Storage: A default StorageClass must be configured. Refer to Kubernetes Persistent Volumes and storage if your cluster lacks dynamic provisioning.
  • Resources: Minimum 4 CPU / 8GB RAM for control plane components. Add node capacity for actual workload execution.
  • Container Registry: Accessible registry (ECR, GAR, Harbor) for pushing pipeline step images.

Standalone Installation Commands

# Clone the official manifests
git clone https://github.com/kubeflow/pipelines.git
cd pipelines/manifests/kustomize

# Configure environment (e.g., AWS EKS with S3 backend)
export PIPELINE_VERSION=2.3.0
kubectl apply -k cluster-scoped-resources
kubectl wait --for=condition=established crd/applications.app.k8s.io

# Apply namespaced resources
kubectl apply -k env/platform-agnostic-prow

# Verify pods are running
kubectl get pods -n kubeflow

A common mistake is skipping the CRD wait condition. Kustomize applies resources asynchronously; if the Application CRD isn't established before dependent resources are created, the installation fails silently. Always verify pod health before proceeding. For air-gapped environments common in government or regulated sectors, pre-pull all images to your internal registry and update the Kustomize patches accordingly.

How do you build reproducible pipelines with the KFP SDK?

KFP v2 uses a decorator-based Python DSL that compiles to IR YAML. Each function decorated with @dsl.component becomes a containerized step. The key discipline here is treating components as pure functions: explicit inputs, explicit outputs, no hidden side effects.

Pipeline Execution FlowIngestRaw Dataset→ Artifact: CSVPreprocessClean & Split→ Artifact: TFRecordTrainGPU Node→ Artifact: ModelEvaluateMetrics Check→ Metric: AccuracyArtifact Storage (MinIO/S3) + ML Metadata Lineage
Typical sequential pipeline in Kubeflow: ML Pipelines on Kubernetes demonstrating artifact passing between ingest, preprocess, train, and evaluate stages.

Defining Components and Pipelines

from kfp import dsl, compiler
from kfp.dsl import Dataset, Model, Output, Input

@dsl.component(base_image='python:3.11-slim')
def preprocess_data(raw_data: str, output_dataset: Output[Dataset]):
    """Pure preprocessing step with explicit I/O."""
    import pandas as pd
    df = pd.read_csv(raw_data)
    # Cleaning logic here
    df.to_parquet(output_dataset.path, index=False)

@dsl.component(base_image='tensorflow/tensorflow:2.16.1-gpu')
def train_model(dataset: Input[Dataset], model: Output[Model], epochs: int = 10):
    """Training step requesting GPU resources."""
    import tensorflow as tf
    # Load from dataset.path, train, save to model.path
    pass

@dsl.pipeline(name='fraud-detection-training')
def training_pipeline(data_uri: str, epochs: int = 20):
    prep_task = preprocess_data(raw_data=data_uri)
    train_task = train_model(
        dataset=prep_task.outputs['output_dataset'],
        epochs=epochs
    ).set_gpu_limit(1)

if __name__ == '__main__':
    compiler.Compiler().compile(training_pipeline, 'pipeline.yaml')

Notice the explicit typing (Input[Dataset], Output[Model]). This isn't just documentation—it enables the KFP runtime to handle artifact serialization, storage paths, and metadata registration automatically. Never hardcode S3 paths inside components; let the framework inject them. This ensures portability and makes local testing possible. For teams managing complex dependencies, refer to our Docker Buildx multi-platform builds guide to create optimized base images that reduce cold-start latency in pipeline steps.

How does Kubeflow compare to Airflow and SageMaker Pipelines?

Choosing an orchestrator depends on your team's skills, compliance needs, and cloud strategy. There is no universal best option—only trade-offs.

CriteriaKubeflow PipelinesApache AirflowSageMaker Pipelines
Primary FocusML-native orchestration & lineageGeneral-purpose DAG schedulingAWS-managed ML workflow service
PortabilityAny Kubernetes clusterAny VM/K8s (Celery/K8s executor)AWS only
Artifact ManagementBuilt-in MLMD + typed artifactsXComs (limited, not ML-aware)SageMaker Model Registry
Learning CurveModerate (K8s + Python DSL)Low-Moderate (Python DAGs)Low (if already on AWS)
Compliance/AuditStrong (self-hosted, full lineage)Moderate (requires plugins)Strong (AWS Audit Manager integration)
Cost ModelSelf-hosted infra cost onlySelf-hosted or MWAA ($$)Pay-per-step + managed premium

When to choose KFP: You run multi-cloud or hybrid, need strict data sovereignty (common in Nepal's fintech sector), or require deep ML lineage without vendor lock-in. When to choose Airflow: Your workflows are primarily ETL/data engineering with occasional ML, and your team lacks Kubernetes expertise. When to choose SageMaker: You are fully committed to AWS, want zero operational overhead, and accept the cost premium for managed convenience.

In my experience helping teams achieve SOC 2 compliance, KFP's self-hosted nature gives auditors confidence because you control the entire stack. Airflow often requires additional tooling for ML lineage, while SageMaker ties your compliance posture to AWS's certification scope. For organizations building AI adoption roadmaps, starting with KFP preserves future optionality.

How do you secure and optimize Kubeflow for production workloads?

Running KFP in production demands more than a successful install. Security, cost control, and reliability require deliberate configuration.

Security Hardening Checklist

  1. Namespace Isolation: Deploy KFP in a dedicated namespace. Use NetworkPolicies to restrict egress from pipeline steps to only required endpoints (artifact store, model registry).
  2. RBAC: Create per-team ServiceAccounts with minimal permissions. Never run pipeline steps with cluster-admin privileges.
  3. Secrets Management: Integrate with External Secrets Operator or Vault. Pass credentials as mounted volumes, never environment variables. See Kubernetes secrets management done right for implementation patterns.
  4. Image Policy: Enforce signed, scanned images via admission controllers (Kyverno/OPA). Block mutable tags like :latest.
  5. Encryption: Enable TLS for intra-cluster communication and encrypt artifact storage at rest.

Cost Optimization Strategies

ML workloads can bankrupt a startup overnight. Implement these controls early:

  • Spot/Preemptible Nodes: Configure KFP to schedule training jobs on spot instances. Handle interruptions gracefully with checkpointing.
  • Resource Requests: Mandate CPU/memory requests in every component. Unbounded pods cause noisy neighbor issues and billing surprises.
  • TTL Controller: Auto-delete completed workflow pods after 24 hours to reclaim etcd storage and node resources.
  • Caching: Enable KFP's built-in caching for deterministic steps. Re-running identical preprocessing wastes money.
Development SetupProduction Hardened❌ Default namespace, shared RBAC✅ Dedicated NS, per-team ServiceAccounts❌ Secrets as env vars, :latest tags✅ Vault integration, signed immutable images❌ On-demand nodes, no resource limits✅ Spot instances, enforced requests/limits❌ No network policies, open egress✅ NetworkPolicies, restricted egress❌ Pods persist indefinitely✅ TTL controller, auto-cleanup❌ No caching, redundant compute✅ Step caching enabled, cost alerts
Production readiness checklist comparing insecure development setup versus hardened Kubeflow: ML Pipelines on Kubernetes deployment.

Monitoring and Observability

KFP exposes Prometheus metrics at /metrics on the API server and workflow controller. Track these golden signals:

  • Pipeline Run Duration: P95 latency by pipeline name. Spikes indicate resource contention or upstream data issues.
  • Step Failure Rate: Broken down by component. High failure rates in specific steps suggest flaky code or unstable dependencies.
  • Cache Hit Ratio: Low ratios mean you're recomputing unnecessarily. Investigate non-deterministic inputs.
  • Queue Depth: Pending workflows signal insufficient cluster capacity or scheduler bottlenecks.

Integrate these with your existing Prometheus and Grafana monitoring stack. Alert on failure rate thresholds, not individual failures—ML pipelines are inherently stochastic, and over-alerting causes fatigue.

Next Steps for Production ML Orchestration

Kubeflow: ML Pipelines on Kubernetes provides the foundation for mature, auditable MLOps—but it rewards preparation. Start with a single, well-defined pipeline (not your most complex one) to validate your installation, security model, and artifact storage. Document your component conventions early; consistency pays exponential dividends as your pipeline library grows. Remember that the goal isn't perfect tooling but reliable, reproducible outcomes that survive audits and team turnover.

If you're evaluating KFP for your organization or struggling with production hardening, I help teams design compliant, cost-effective ML platforms. Reach out to discuss your specific requirements—whether you're in Kathmandu or operating globally, we can build a system that scales safely.

Frequently Asked Questions

Kubeflow Pipelines is a platform for building and deploying portable, scalable machine learning workflows on Kubernetes. It orchestrates containerized steps using Argo Workflows, enabling reproducible training, evaluation, and deployment pipelines directly within your existing cluster infrastructure without managing separate MLOps servers.

Use the official kustomize manifests or Helm chart targeting Kubernetes 1.30+. Apply the standalone pipeline manifest to avoid installing the full Kubeflow suite. Verify cert-manager and Istio dependencies match current stable versions before running kubectl apply to prevent namespace conflicts during initialization.

Yes, it runs natively on EKS, GKE, and AKS. Cloud providers often offer optimized distributions with pre-configured storage classes and IAM bindings. Always check vendor documentation for specific node pool sizing recommendations, as metadata servers and persistent volume claims require proper permissions to function correctly.

Control plane components need at least four vCPUs and 8GB RAM. Worker nodes running ML tasks should have GPU access and 32GB+ RAM. Storage requires fast SSD-backed persistent volumes for artifact caching, as slow I/O severely bottlenecks pipeline execution and metadata database performance.

Kubeflow Pipelines targets ML-specific workflows with native Kubernetes pod execution and artifact tracking. Airflow excels at general data orchestration but lacks built-in ML metadata stores. Choose Kubeflow for model training and serving; use Airflow for upstream ETL or hybrid architectures where both tools integrate via operators.

Absolutely. CPU-only pipelines handle preprocessing, feature engineering, and lightweight inference fine. Configure resource requests in pipeline components to avoid GPU scheduling overhead. Reserve accelerator nodes strictly for training or heavy batch scoring tasks to optimize cluster costs and reduce unnecessary queue wait times.

Integrate with Kubernetes Secrets or external vaults like HashiCorp Vault via CSI drivers. Never hardcode credentials in pipeline DSL code. Mount secrets as environment variables or files at runtime. Enable RBAC policies restricting secret access to specific namespaces and service accounts used by pipeline runners.

Check node resource availability using kubectl describe nodes. Pending pods usually indicate insufficient CPU, memory, or GPU capacity. Verify resource quotas and limit ranges in the kubeflow namespace. Inspect Argo Workflow controller logs for scheduling errors or misconfigured tolerations preventing pod placement on tainted nodes.

Perform rolling upgrades using kustomize overlays matching your current version. Back up the MySQL metadata database and MinIO artifacts first. Upgrade control plane components incrementally, validating each stage. Existing running pipelines continue unaffected, but new submissions pause briefly during API server restarts and CRD updates.

S3-compatible object storage like MinIO or cloud-native buckets (GCS, S3) are standard for 2026 deployments. Avoid local filesystem storage for production. Configure the pipeline SDK to use IRSA or workload identity for authentication. Ensure lifecycle policies archive old artifacts to reduce costs while maintaining reproducibility.

Access pod logs via kubectl logs or the Kubeflow UI. Enable step-level logging in your Python components using standard logging libraries. Check exit codes and output artifacts for partial failures. Use kubectl exec to inspect container state mid-execution when debugging interactive issues not captured in final logs.

Yes, integrate Ray clusters as custom resources within pipeline steps. Deploy KubeRay operator alongside Kubeflow for distributed training. Define RayJob or RayCluster specs inside pipeline components to leverage elastic scaling. This combination handles large-scale hyperparameter tuning and distributed data processing efficiently on shared Kubernetes infrastructure.

Costs vary significantly by workload. A minimal dev cluster runs $150-300 monthly. Production GPU training environments easily exceed $2000. Optimize with spot instances for non-critical steps, right-size node pools, and implement auto-scaling. Monitor spend via cloud billing tags applied to kubeflow namespaces and pipeline run IDs.

Yes, use the Kubeflow Pipelines REST API or kfp CLI in GitHub Actions, GitLab CI, or Jenkins. Authenticate via service account tokens stored as CI secrets. Submit pipeline runs programmatically after code merges or data validation checks pass to automate retraining and model promotion workflows reliably.

Use kfp SDK version 2.7+ for Kubeflow Pipelines 2.x deployments in 2026. The v2 SDK uses YAML-based IR instead of Argo-specific constructs. Migrate legacy v1 decorators to @dsl.component and @dsl.pipeline syntax. Pin exact versions in requirements.txt to avoid breaking changes during minor updates.