Skip to content

CONCEPT Cited by 1 source

Nodeless Kubernetes

Nodeless Kubernetes is the architectural stance of running a Kubernetes API surface without any real Node objects or worker VMs under the control of the cluster operator. Capacity planning (what the Nodes look like, how big they are, how many exist, how they are patched) is owned by the cloud provider; the operator sees only Pods, Services, Deployments, etc.

Definition

Classical Kubernetes exposes three worker-tier concerns to the operator:

  1. Node shape / size — instance family, CPU, memory.
  2. Node count — how many Nodes, across which zones / regions.
  3. Node lifecycle — patching, draining, replacing, scaling.

Nodeless Kubernetes eliminates all three from the operator's API surface. The Kubelet "there" on the cluster is a Virtual Kubelet — a fake Node that forwards Pod-create requests into the cloud's compute primitive (typically a micro-VM or a function service), and the provider's scheduler (not K8s' kube-scheduler on the operator's behalf) decides where the workload physically lands.

From the Fly.io FKS beta announcement:

A key thing to notice above is that there's no "Node".

and

It [Virtual Kubelet] instead behaves like an API, receiving requests from Kubernetes and transforming them into requests to deploy on a cloud compute service. … This shifts the burden of managing hardware capacity from you to us.

Canonical production instances

  • Fly Kubernetes (FKS) — K3s + an in-house Virtual-Kubelet provider that maps Pods to Fly Machines (Firecracker micro-VMs).
  • AWS Fargate on EKS — Pods backed by Firecracker micro-VMs on Fargate; no Node management.
  • Azure AKS Virtual Nodes — Pods backed by Azure Container Instances via a Virtual-Kubelet provider.

Trade-offs

  • ✅ No capacity planning for the operator. No Node-shape selection, no HPA-and-CA feedback loop tuning, no bin-packing.
  • ✅ Per-Pod billing granularity — the provider can bill at Pod shape, not at Node shape.
  • ❌ Leaky abstraction at Kubelet-adjacent APIs. Some responsibilities that belong to a "real" Kubelet (e.g. kubectl exec, kubectl port-forward) may not be implemented until the VK provider grows them. FKS explicitly notes this and routes users to flyctl instead.
  • ❌ Support-matrix gaps. Not every K8s API object maps cleanly to a cloud compute primitive. Multi-container Pods, init containers, emptyDir, NetworkPolicies, StatefulSets are common omissions at launch (all missing at FKS beta).
  • ❌ Conformance question. CNCF conformance tests assume a standard Node surface; nodeless distributions may not certify.

Seen in

Last updated · 200 distilled / 1,178 read