Burst incredible.
No hassle.

Cloudburst is a Kubernetes controller that adds burst nodes when pods can’t be scheduled. It asks CloudBroker for the cheapest VM that fits, provisions it on the right cloud (e.g. GCP, AWS, Hetzner, Scaleway — more coming), and bootstraps it with Tailscale + kubeadm join. When the node is empty long enough, it cordons, drains, and deletes the VM.

CloudBroker (for recommendations), Tailscale (for networking), and provider API credentials. You define NodePool and NodeClass; the system creates NodeClaims and VMs. See the repo for config/samples/ and make kind-setup-and-deploy.

It’s open source. You run it. You pay for the VMs you burst to — and the controller picks the cheapest one that fits. No monthly fee to us.

Yes. When the node has been empty for ttlSecondsAfterEmpty (set in NodePool), the controller cordons, drains, and deletes the VM. Billing stops.

Burst nodes talk to the control plane over Tailscale. To measure latency:

• Burst node → control plane: kubectl exec into a pod on a burst node and ping the control plane Tailscale IP (from your NodeClass hostApiServer). For API round-trip: curl -o /dev/null -w "%{time_total}s" -k https://<TAILSCALE_IP>:6443/healthz.
• Worker ↔ worker: Run debug pods on different nodes and ping each other’s node IP (Tailscale IP for burst nodes). Use kubectl get nodes -o wide to see IPs.

Tailscale may use DERP relays when direct connectivity fails, which can add latency. For low-latency workloads, prefer burst nodes in regions close to your control plane.

The Tailscale Kubernetes Operator lets you expose cluster workloads to your tailnet via LoadBalancer Services or Ingress. No public IPs, no cloud load balancers, no extra cost. Create a Service with loadBalancerClass: tailscale or an Ingress with ingressClassName: tailscale — the operator provisions a Tailscale node and gives you a MagicDNS name. Access from any device on your tailnet. See the Tailscale Operator example for full manifests.

Two options work well with Cloudburst clusters:

• Local Path Provisioner: Simple local storage on each node. Uses /opt/local-path-provisioner by default. Suitable for dev/test and single-node workloads. Install with kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.34/deploy/local-path-storage.yaml. Use storageClassName: local-path in your PVCs.
• Longhorn: CNCF distributed block storage. Replicates data across nodes, supports snapshots and backups. Suitable for workloads that need durability and HA. Install with kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.9.1/deploy/longhorn.yaml or via Helm. Use storageClassName: longhorn in your PVCs.

See Local Path Provisioner and Longhorn for full PVC and Pod manifests.

Traffic between pods on different burst nodes can incur cloud egress charges. Use Kubernetes pod affinity to co-locate related pods on the same node so they communicate over the node network instead of crossing nodes.

Hard affinity (required): the pod must run on a node that already has a matching pod. Use when co-location is critical (e.g. app + cache sidecar):

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: my-app
      topologyKey: kubernetes.io/hostname

Soft affinity (preferred): the scheduler tries to co-locate but will place elsewhere if needed. Use when you want to reduce egress without blocking scheduling:

affinity:
  podAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels:
            app: my-app
        topologyKey: kubernetes.io/hostname

When to spread instead: For HA, use podAntiAffinity with topologyKey: kubernetes.io/hostname to spread replicas across nodes — but expect cross-node traffic and egress. Balance co-location (fewer nodes, less egress) vs. spreading (more resilience). See Pod affinity and Pod anti-affinity for more patterns.