Hi
@rapid-appointment-17222
We haven’t tested this yet, but yes, it should work. Nothing in Flyte 2 needs node-level access: the control plane is a single Deployment, task pods are plain pods, and the secrets webhook is scoped by label so it never touches GKE-managed namespaces. GPU config already uses GCP accelerator names, you just set gpu-device-node-label:
cloud.google.com/gke-accelerator.
There’s one default you’ll want to override: Flyte annotates every task pod with
cluster-autoscaler.kubernetes.io/safe-to-evict: “false”. On Autopilot that requests an extended-run-time pod, which caps you at 50 such workloads per cluster, raises the enforced resource minimums, rules out Spot, and tries to put each pod on its own node. Drop it from k8s.default-annotations and apply it selectively if you need it.
Other things to consider:
• Autopilot enforces a CPU:memory ratio (1:1 to 1:6.5 on general-purpose) and caps ephemeral storage at 10GiB per pod, which matters for tasks staging large inputs locally.
• Since every pod can trigger node provisioning, heavy map-task fan-out will be slower and pricier than on Standard node pools. I’d suggest Autopilot for the control plane and lighter workloads, The standard deployment for fan-out heavy projects.
As I mentioned we don’t test against Autopilot in CI, so this is from reading the code against GKE’s restrictions rather than a deployment we’ve run.
Would you be open to try it? We’d love to work with you on getting a docs guide for this