This folder contains Kubeflow Pipelines Standalone Kustomize manifests.
Kubeflow Pipelines Standalone is one option to install Kubeflow Pipelines. You can review all other options in Installation Options for Kubeflow Pipelines.
To install Kubeflow Pipelines Standalone, follow Kubeflow Pipelines Standalone Deployment documentation.
There are environment specific installation instructions not covered in the official deployment documentation, they are listed below.
Install:
KFP_ENV=platform-agnostic
kubectl apply -k cluster-scoped-resources/
kubectl wait crd/applications.app.k8s.io --for condition=established --timeout=60s
kubectl apply -k "env/${KFP_ENV}/"
kubectl wait pods -l application-crd-id=kubeflow-pipelines -n kubeflow --for condition=Ready --timeout=1800s
kubectl port-forward -n kubeflow svc/ml-pipeline-ui 8080:80
Now you can access Kubeflow Pipelines UI in your browser by http://localhost:8080.
You can install them by changing KFP_ENV
in above instructions to the variation you want.
Data:
Application data are persisted in in-cluster PersistentVolumeClaim storage.
IBM Cloud uses the NFS storage with UID support to make sure all pods can run as non-root users.
Please follow the IKS group ID storage setup before running the above standalone install commands.
Cloud Storage and Cloud SQL are better for operating a production cluster.
Refer to Google Cloud Instructions for installation.
S3 and RDS MySQL are better for operating a production cluster.
Refer to AWS Instructions for installation.
Note: Community maintains a different opinionated installation manifests for AWS, refer to e2fyi/kubeflow-aws.
If the installation is based on CloudSQL/GCS, after the uninstall, the data is still there, reinstall a newer version can reuse the data.
### 1. namespace scoped
# Depends on how you installed it:
kubectl kustomize env/platform-agnostic/ | kubectl delete -f -
# or
kubectl kustomize env/dev | kubectl delete -f -
# or
kubectl kustomize env/gcp | kubectl delete -f -
# or
kubectl delete applications/pipeline -n kubeflow
### 2. cluster scoped
kubectl delete -k cluster-scoped-resources/
- User facing manifest entrypoints are
cluster-scoped-resources
package andenv/<env-name>
package.cluster-scoped-resources
should collect all cluster-scoped resources.env/<env-name>
should collect env specific namespace-scoped resources.- Note, for multi-user envs, they already included cluster-scoped resources.
- KFP core components live in
base/<component-name>
folders.- If a component requires cluster-scoped resources, it should have a folder inside named
cluster-scoped
with related resources, but note thatbase/<component-name>/kustomization.yaml
shouldn't include thecluster-scoped
folder.cluster-scoped
folders should be collected by top levelcluster-scoped-resources
folder.
- If a component requires cluster-scoped resources, it should have a folder inside named
- KFP core installations are in
base/installs/<install-type>
, they only include the core KFP components, not third party ones. - Third party components live in
third-party/<component-name>
folders.
Env specific overlays live in env/<env-name>
folders, they compose above components to get ready for directly deploying.
Please compose base/installs/<install-type>
and third party dependencies based on your own requirements.
Constraints for namespaced installation we need to comply with (that drove above structure):
- CRDs must be applied separately, because if we apply CRs in the same
kubectl apply
command, the CRD may not have been accepted by k8s api server (e.g. Application CRD). - A Kubeflow 1.0 constraint is that we should separate cluster scoped resources from namespace scoped resources, because sometimes different roles are required to deploy them. Cluster scoped resources usually need a cluster admin role, while namespaced resources can be deployed by individual teams managing a namespace.