Running on GKE
Some platform teams already run Kubernetes and would rather add machine learning to it than run a second platform. Pipewright runs the same compiled pipelines on Kubeflow Pipelines in a private GKE cluster, with KubeRay for Ray steps and KServe for serving. This tutorial is reading, not a build: the cluster is the platform team’s.
Why a team chooses GKE
- It already runs Kubernetes, with the tooling and on-call rotas for it.
- It must stay inside a perimeter. Under an enforced VPC Service Controls perimeter, Ray runs inside the cluster.
- It wants control of the machines: node pools, reserved GPUs, a cluster that stays up.
- It wants the open-source pieces, which run on any Kubernetes.
The price is that someone runs the cluster: upgrades, node pools, the Kubeflow and KServe installations, and the images they pull. On Agent Platform, Google does that.
One line in the manifest
The platform team sets orchestrator: kfp in the environment’s manifest, with the cluster’s details. Pipewright reaches the Kubernetes API through the cluster’s DNS endpoint as a Google identity, with no kubeconfig, and each team’s steps run as its runner service account through Workload Identity.
What does not change
The use case files, the pipeline code and the release. Pipewright compiles a pipeline once; the environment decides where it runs. BigQuery, Model Registry, the event log and everything outside the cluster stay where they were.
What changes
| Agent Platform | Private GKE | |
|---|---|---|
| Pipelines | Agent Platform Pipelines | Kubeflow Pipelines, steps as pods |
| Ray steps | A Ray on Agent Platform cluster per step | A KubeRay cluster per step, on a node pool kept for Ray |
| Serving | Agent Platform endpoints, canaries | KServe, model.serving.target: kserve, behind an internal load balancer |
| Schedules | Cloud Scheduler | Kubernetes CronJobs, where the manifest says so |
| Images | Pulled from Google’s registries | Mirrored into your Artifact Registry, for a private cluster |
On KServe, online requests send objects ([{"customer_id": "c-42"}]), since its serving envelope refuses bare strings, and there is no canary to promote. pipewright model endpoint prints the in-cluster URL, the load balancer’s address and the route.
Pipewright Enterprise’s private blueprint builds the cluster, the mirror, Kubeflow, KubeRay and KServe from one platform file, inside the perimeter, with keys you hold. Read more.