Principle:Kubeflow Kubeflow Core Infrastructure Deployment
| Knowledge Sources | |
|---|---|
| Domains | Kubeflow, Platform Deployment, Service Mesh, Security |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Core infrastructure deployment is the process of provisioning the foundational platform services (Istio service mesh, cert-manager, and Dex OIDC provider) that all Kubeflow components depend upon.
Description
Kubeflow requires three infrastructure services to be operational before any ML-specific component can be deployed:
- Istio provides the service mesh layer that handles traffic routing, mutual TLS between services, and ingress gateway functionality. Kubeflow uses Istio to expose the Central Dashboard and to enforce network-level access control via AuthorizationPolicy resources.
- cert-manager automates the provisioning and renewal of TLS certificates within the cluster. It is used by multiple Kubeflow components for securing internal communication and can be configured with external certificate authorities for production deployments.
- Dex is an OpenID Connect (OIDC) identity provider that serves as the authentication layer for Kubeflow. It federates identity from upstream providers (LDAP, SAML, GitHub, Google) and issues tokens that Kubeflow uses for user authentication and multi-tenancy enforcement.
These three services create dedicated namespaces (istio-system, cert-manager, auth) and must be fully running before any Kubeflow component deployment begins. The deployment order matters: cert-manager should be deployed first (as Istio may use it for certificate management), followed by Istio, and then Dex.
Usage
Deploy core infrastructure in the following scenarios:
- Initial Kubeflow installation on a fresh Kubernetes cluster
- Rebuilding a Kubeflow environment from scratch after a cluster replacement
- Upgrading core infrastructure components independently of Kubeflow ML components
- Migrating from a non-Istio ingress to Istio-based ingress for an existing cluster
Theoretical Basis
The deployment follows a strict ordering to respect inter-service dependencies:
Phase 1: cert-manager Deployment
- Apply the cert-manager CRDs and controller deployment
- Wait for the cert-manager webhook to become ready
- Verify certificate issuance by creating a self-signed test certificate
Phase 2: Istio Deployment
- Install Istio using the istio-cni plugin for enhanced pod security
- Configure the Istio ingress gateway in the istio-system namespace
- Verify Istio sidecar injection is working by deploying a test pod
- Ensure PodSecurityStandards are configured to allow Istio init containers
Phase 3: Dex Deployment
- Deploy Dex into the auth namespace
- Configure the OIDC issuer URL, client ID, client secret, and redirect URIs
- Connect Dex to the upstream identity provider (static passwords for dev, LDAP/SAML for production)
- Verify Dex is issuing tokens by performing a test authentication flow
Validation Gate:
- All pods in istio-system, cert-manager, and auth namespaces must be in Running or Completed state
- The Istio ingress gateway must be accepting connections
- Dex must respond to OIDC discovery requests at its well-known endpoint