Serverless Kubernetes abstracts the control plane and worker nodes - the team submits YAML manifests, the cloud provider runs the API server, scheduler, and worker nodes on demand, billed per pod resource consumption. AWS EKS Auto Mode, GKE Autopilot, and Azure Container Apps are the canonical serverless k8s offerings. The team that picks serverless k8s skips node management, autoscaling, and capacity planning; the team that needs custom CNI, kernel modules, or specific instance types picks standard managed k8s.
Table of contents
- What serverless Kubernetes actually abstracts
- The three main offerings compared
- When serverless Kubernetes wins
- When standard Kubernetes is the right choice
- Migration patterns
- FAQ
What serverless Kubernetes actually abstracts
The control plane: API server, scheduler, etcd, controller manager. Standard managed k8s (EKS, GKE, AKS) runs the control plane; the team manages worker nodes. Serverless k8s also runs the control plane but bills it per-pod, not as a fixed cluster fee.
The worker nodes: where pods actually run. Standard k8s requires the team to provision node groups, choose instance types, and manage autoscaling. Serverless k8s auto-provisions nodes based on pod requirements - the team declares CPU/memory requests, the provider allocates matching nodes.
The networking layer: CNI, service mesh, ingress. Standard k8s has the team install and configure these. Serverless k8s has a fixed, opinionated network stack (e.g., GKE Autopilot uses Google’s Cilium-based CNI). The team that needs custom networking picks standard k8s.
The three main offerings compared
GKE Autopilot (Google Cloud): Most mature serverless k8s. The team submits YAML; Google runs nodes. Billing is per-pod resource requests. Restrictions: no privileged containers, no custom node configs, no host networking. The team that runs standard Kubernetes workloads on Autopilot gets them running; the team that needs DaemonSets, privileged pods, or custom kernels picks standard GKE.
EKS Auto Mode (AWS): Newer than Autopilot (GA 2025). The team submits YAML; AWS runs nodes on EC2. Billing includes node hours. Restrictions: similar to Autopilot - no privileged containers, no custom AMIs. The team that runs EKS gets the Auto Mode abstraction as an option, falling back to standard EKS node groups when needed.
Azure Container Apps: Kubernetes-based but exposes a higher-level API (not raw k8s). The team deploys containers; Azure runs the k8s underneath. The team that wants k8s primitives (Deployments, Services, Ingress) picks AKS with Automatic mode or standard AKS. The team that wants a PaaS experience picks Container Apps.
When serverless Kubernetes wins
Variable workloads with bursty traffic. The team that has an app that runs at 1 pod for hours, then bursts to 50 pods during traffic spikes, picks serverless k8s. The provider scales nodes automatically; the team pays only for what runs.
Small teams without dedicated platform engineers. The team that has 3 backend developers and no platform team picks serverless k8s. The team that runs standard k8s needs at least one person who understands nodes, networking, and upgrades; the team that runs serverless k8s has the provider handle that.
Cost optimization for low-utilization clusters. The team that runs a dev cluster at 5% CPU utilization 90% of the time picks serverless k8s. Pay-per-pod beats pay-per-node for low utilization. The team that runs a prod cluster at 80% utilization 24/7 may find standard k8s cheaper due to per-pod pricing premiums.
When standard Kubernetes is the right choice
Custom CNI, kernel modules, or specific instance types. The team that needs a particular CNI (Calico with custom config), kernel module (eBPF, WireGuard), or GPU instance type (A100, H100) picks standard k8s. Serverless k8s has a fixed, opinionated stack that does not allow these customizations.
DaemonSets, privileged containers, host networking. The team that runs Datadog agent as a DaemonSet, or needs privileged containers for system tools, picks standard k8s. Serverless k8s blocks these for security reasons.
Predictable cost with continuous utilization. The team that runs at 80% utilization 24/7 may find serverless k8s more expensive than standard k8s. The per-pod pricing premium is worth it for bursty workloads; for continuous workloads, reserved instances or savings plans on standard k8s win.
Migration patterns
Start with standard k8s, migrate specific workloads to serverless. The team that has an existing EKS cluster can move dev/test workloads to EKS Auto Mode while keeping prod on standard EKS. The team that gets comfortable with serverless k8s expands the scope.
Run serverless k8s for new projects. The team that starts a new project picks serverless k8s (GKE Autopilot) from day one. The team that picks standard k8s for a small project pays for unused capacity.
Use kubectl with both - the API is the same. Serverless k8s exposes the same Kubernetes API as standard k8s. The team that has kubectl configured for one cluster uses it for both. The team that runs kubectl get pods on a serverless cluster sees the same output as on a standard cluster.
FAQ
What is the difference between GKE Autopilot and standard GKE?
Standard GKE: the team manages node pools, instance types, and autoscaling. Autopilot: the team only manages pods and Deployments; Google manages nodes. Autopilot bills per-pod resource requests; standard GKE bills per-node. Autopilot restricts privileged containers, DaemonSets, and host networking; standard GKE allows them.
Is EKS Auto Mode the same as Fargate?
No. Fargate runs ECS or EKS pods on AWS-managed infrastructure without EC2 nodes - pure serverless compute. EKS Auto Mode runs EKS pods on EC2 nodes that AWS auto-manages - you still see the nodes, but AWS handles provisioning, scaling, and patching. The team that picks Fargate has no node management at all; the team that picks Auto Mode has managed nodes.
Can I run stateful workloads on serverless Kubernetes?
Yes, with persistent volumes. GKE Autopilot supports PersistentVolumeClaims; EKS Auto Mode supports EBS-backed PVCs. The team that runs databases on serverless k8s uses PVCs for storage. The team that needs high-performance storage (NVMe local SSDs) picks standard k8s for node local storage.
What is the pricing model?
GKE Autopilot: per-pod resource request (CPU, memory, ephemeral storage). EKS Auto Mode: per-node (EC2) with no cluster fee for the control plane. Azure Container Apps: per-vCPU-second and GB-memory-second of active containers. The team that compares per-pod pricing to per-node pricing does the math based on utilization pattern.
Can I use Helm charts on serverless Kubernetes?
Yes. Helm is a templating tool; the resulting manifests run on any k8s. The team that uses serverless k8s with Helm gets the same chart ecosystem. Restrictions come from the serverless k8s platform (privileged containers, DaemonSets) not from Helm.
What are the limitations of serverless Kubernetes?
GKE Autopilot: no privileged containers, no host networking, no custom node configs, no DaemonSets. EKS Auto Mode: similar restrictions. The team that needs these features picks standard k8s. The team that does not need them gets simpler operations from serverless k8s.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: