GKE just put hardware-isolated pods into the GA column: microVM sandboxes are now generally available in the GKE 1.37 release series, implemented with Kata Containers backed by Cloud Hypervisor. This isn’t a marginal security toggle — it’s a platform-level admission that some workloads belong inside microVMs, not just in privileged containers or complex VMs.
Why it matters right now
The adoption vector is obvious: untrusted code, multi-tenant SaaS, and agentic AI runtimes that execute third-party or dynamically generated code. Kata Containers with Cloud Hypervisor gives you a tighter boundary than user-space syscall isolation (gVisor) or seccomp alone, while still keeping the pod lifecycle and Kubernetes primitives teams already manage.
MicroVMs add measurable isolation without forcing you to run separate VM stacks, VM images, or a VM-centric deployment workflow. You get stronger isolation with less operational churn than full VMs — and with GKE making it a first-class, GA option, platform teams can standardize on it instead of inventing ad-hoc VM wrappers. This is the right call; delaying this would have left teams to build brittle, inconsistent isolation layers themselves.
The new trust boundary
Cloud Run’s recent previews — instance exec (an interactive shell capability) and a preview for directly addressable, long-lived instances — expose the other side of the same trend: stateful, interactive, singleton-friendly serverless. Giving human operators and debuggers an exec session into managed serverless instances is extremely useful for troubleshooting, but it also creates a fresh trust boundary. Interactive shells bypass much of what request-level IAM and observability expect. If you enable this and don’t track session creation, duration, and privilege elevation, you’ve just opened a new attack surface.
Likewise, addressable, long-lived Cloud Run instances break the implicit contract that serverless instances are ephemeral, identical, and replaceable. Teams will now mix singleton state with autoscaling request-serving — and if they do it naively, they'll bleed sticky state into autoscaling decisions and latency budgets.
EKS-to-GKE Agentic Migration: automation meets complexity
Google Cloud’s migration tooling (Migrate for Anthos and GKE, plus other modernization utilities) and early previews that advertise more automated EKS→GKE workflows aim to automate discovery, manifest translation, and storage/network mapping for Kubernetes migrations. Automation here is powerful: translating CRDs, mapping PV semantics across clouds, and suggesting network policies reduces toil on big migrations. But "agentic" migration that rewrites manifests deserves scrutiny — automated translation is only as good as the assumptions it encodes about CRD compatibility, storage class semantics, and IAM mappings. If you hand a complex cluster to a translator and accept the output wholesale, you will inherit subtle behavioral differences.
What platform engineers should actually be doing
- Treat microVM sandboxes as a new compute class in your platform catalog, not a drop-in replacement for existing node pools. Expect differences around device plugins, privileged DaemonSets, and CSI drivers.
- Instrument and audit Cloud Run exec sessions from day one. Require session metadata, short-lived service accounts scoped for debugging, and centralized session recording where policy requires it.
- Use migration preview tooling for discovery and dry runs, not automated cutovers. Validate translated manifests in staging clusters that mirror networking and storage behavior precisely.
A final take
Google Cloud’s moves add up to a platform designed for agentic, stateful, and multi-tenant workloads: hardware-isolated pods, addressable serverless instances, and migration automation to move workloads into that stack. That’s the correct direction — but it forces a little engineering discipline. Platform teams who treat microVMs and addressable instances as knobs without rethinking lifecycle, access, and operational tooling are going to get surprised by trust boundaries and behavioral mismatches.
If you run multi-tenant or AI-agent workloads, start designing your isolation, observability, and migration workflows around microVMs and instance-oriented serverless today. Google’s shipping the primitives; your job is to keep the operational surface area from turning into an attack surface.
Related reading: see our piece on persistent singletons and agent substrates in GKE and Cloud Run: GKE Agent Substrate (Evaluation) & Cloud Run Instances (Preview) Persistent Singletons for Google Cloud Agents.