Before you migrate your existing Google Kubernetes Engine (GKE) clusters from Dataplane V1 to GKE Dataplane V2, use this document to check whether your clusters are eligible, learn what happens during migration, and plan for workload disruption.
As a Platform admins and operators or Networking specialists, use this overview to plan your migration strategy. To perform the migration, see Migrate an existing cluster to GKE Dataplane V2.
Benefits of migrating
After you migrate to GKE Dataplane V2, you will gain the scalability, security, and operational advantages it provides.
- Enforce network policies in place: apply Cilium-based network policies to your existing cluster without moving workloads to a new cluster.
- Troubleshoot network issues faster: debug network flows by using built-in GKE Dataplane V2 metrics and events.
Check whether your cluster is eligible
Before you migrate, verify that your cluster meets the following requirements:
- Routing type: VPC-native. You can't migrate routes-based clusters.
- Cluster version: 1.35.3-gke.1155000 or later.
- Node pool version: 1.35.1-gke.1516000 or later.
- Istio version: if you use Cloud Service Mesh or open source Istio, 1.23 or later. This version supports Container Network Interface (CNI) specification 1.1.0.
Unsupported configurations
The following configurations are not supported in GKE Dataplane V2:
- Custom CNI plugins: plugins that you install to replace the CNI plugin that GKE manages.
- Custom eBPF programs: programs that you attach to managed interfaces. If you attach them before Cilium programs, they might prevent Cilium programs from running. If you attach them after Cilium programs, Cilium bypasses them.
To find these configurations in your cluster, check Active Assist or the cluster details page for recommendations that might conflict with the migration.
What happens during migration
Migration has four phases. GKE does most of the work, but some phases need action from you:
| Phase | What GKE does | What you do |
|---|---|---|
| Diagnose | Monitors your cluster and flags unsupported configurations in Active Assist recommendations. | Review the recommendations and resolve flagged configurations. |
| Initiate | — | Start the migration by updating your cluster by using a patch request. For more information, see Migrate an existing cluster to GKE Dataplane V2. |
| Patch nodes | Updates each Dataplane V1 node pool to use GKE Dataplane V2, following your maintenance windows and upgrade strategies. | Before you start, configure maintenance windows and upgrade strategies to control when and how your nodes update. |
| Finalize | Patches the cluster to ADVANCED_DATAPATH after it updates all node pools. |
No action required. |
Plan for workload disruption
Because GKE recreates your nodes during migration, GKE reschedules your Pods onto the new nodes.
What's next
- To migrate a cluster, see Migrate an existing cluster to GKE Dataplane V2.
- To understand how GKE Dataplane V2 works, see About GKE Dataplane V2.
- To troubleshoot network flows after you migrate, see GKE Dataplane V2 observability.