How Google’s GKE Migration Agent Aims to Make EKS-to-GKE Moves Safer

Google’s newly open-sourced GKE agentic migration tool is intended to make EKS-to-GKE migration more structured than an engineer prompting an LLM for replacement configuration. Google describes an agent plugin that combines model reasoning with deterministic tooling and guardrails. That division of labor matters: an LLM can propose a translation, but a proposal still needs independent checks and a controlled path to deployment. 2

From migration intent to reviewable configuration

An EKS-to-GKE move is not simply a matter of renaming Kubernetes fields. Teams may need to translate infrastructure-as-code and manifests while preserving what the original setup does: which workloads can access which resources, where traffic goes, and how nodes provide capacity. Google’s broader container-migration guidance likewise starts with assessing workloads and dependencies before migration. 19

The workflow described for this agent gives the model a reasoning role and the plugin a tooling role. A Model Context Protocol (MCP) interface can make tools available to an agent; it does not itself establish that the resulting configuration is correct. Google’s announcement confirms the combination of LLM reasoning and deterministic tooling, but the provided excerpt does not spell out every plugin operation or conversion rule. 2

Three proposed translations deserve particular scrutiny:

• AWS identity to GKE workload identity: Does the destination preserve the intended access, without granting more than the workload needs?
• Load-balancer ingress to Gateway API: Will requests still reach the right services under the expected routing rules?
• Node provisioning: Will workloads retain the scheduling behavior and capacity they require?

These are review questions for the mappings described in the migration workflow, not independently verified guarantees that the tool handles every case. A generated manifest can be syntactically valid while still changing permissions, traffic behavior, or capacity assumptions.

Why deterministic validation and pull requests matter

Deterministic offline checks offer a different kind of assurance from an LLM’s explanation: the same proposed files can be tested against the same rules before anyone deploys them. But their scope is limited to what those rules actually check. They cannot, on their own, prove that an application will behave identically after cutover. Google characterizes the release as protected by deterministic guardrails; the available announcement excerpt does not specify the full coverage of its offline validation. 2

The pull-request approach described for the tool would put generated changes in front of engineers and existing CI/CD gates rather than directly modifying a live cluster. Reviewers could inspect diffs and require tests, policies, and approvals before promotion. That fits Google’s documented guidance on using source control and CI/CD for GKE deployments, though the provided announcement excerpt does not independently confirm every step of this tool’s pull-request workflow. 172

Persistent EVP Rahul Shrivastava calls the approach a “provable, compiler-grade migration factory” in Google’s announcement. It is a useful analogy for generating and checking migration artifacts, not evidence of a mathematical proof that an entire migration is safe. Runtime behavior, access, performance, dependencies, and cutover still require testing. 2

Where Intrinsic Core fits in the larger picture

Two days before the GKE announcement, Intrinsic introduced Intrinsic Core at ROSCon 2026 in Toronto. Its open-source, ROS-compatible robotics foundation includes reusable capabilities for control, motion and grasp planning, simulation, and pose estimation; reporting identifies the release as Apache 2.0–licensed. Intrinsic also describes a hardware-agnostic real-time control framework and digital-twin capabilities. 403337

The connection is strategic rather than technical: GKE’s migration tool could lower the work required to move workloads toward Google Cloud, while Intrinsic Core could lower the work required to build industrial-robotics applications. Reporting frames the latter as an “Android of robots” approach—making a foundation broadly available and seeking an ecosystem around it. Neither release, by itself, demonstrates that developers will buy Google AI services or that AWS customers will switch clouds. 230

The practical verdict: Google’s GKE design addresses the infrastructure-automation trust gap by separating AI-generated proposals from validation and deployment authority. That can make a migration easier to evaluate within established engineering processes. It does not remove the need to verify each workload’s behavior, and the provided sources offer no measured reduction in migration failures or costs. 219