Skip to content

Kubernetes on whitesky.cloud — batteries included

CAPVCO turns a few lines of YAML into a production-grade Kubernetes cluster on whitesky.cloud. You describe the cluster you want; a controller builds and continuously reconciles everything underneath it — cloudspaces, VMs, disks, load balancers, DNS, storage — the Cluster API way.

It’s not a thin "boot some VMs and run kubeadm" provider. Geo-redundancy, tested etcd backup/restore, encrypted persistent storage, external DNS, load balancers, air-gapped installs and day-2 automation are first-class and included — not bolt-ons you assemble yourself.

whitesky.cloud and the VCO model

whitesky.cloud is a Virtual Cloud Operator (VCO) platform: a wholesale cloud model borrowed from telecom’s MVNE/MVNO structure — one operator runs the underlying cloud, and partners resell fully white-labeled clouds on top of it. You connect to a whitesky.cloud portal (a branded instance). CAPVCO is the Cluster API provider for that platform — the "VCO" in CAPVCO, VCOCluster and VCOMachine refers to this Virtual Cloud Operator model. New to it? See Core concepts or the VCO model explainer.

  •   Never deployed Kubernetes? Start here.

    A guided path from zero — the concepts, the prerequisites, and your first working cluster, copy-paste by copy-paste, with the output you should expect at every step.

    Getting started

  •   Already run clusters? Jump in.

    Task-focused guides for every capability, a complete configuration reference, and day-2 operational runbooks written for real 3 a.m. incidents.

    Guides · Reference · Operations

What you get out of the box

  • Geo-redundant control plane

    One logical cluster stretched across multiple cloudspaces and datacenters, meshed over an automatically-built site-to-site VPN, with a DNS control-plane endpoint that always resolves to a live, local API server. Survive a whole datacenter going dark.

    Geo-redundancy

  • Tested etcd backup & restore

    Hourly encrypted etcd snapshots to S3/objectspace with Object-Lock WORM protection and grandfather-father-son retention — plus a restore path that has actually been exercised, not just documented.

    Backup & restore

  • Storage, including encrypted

    The whitesky.cloud CSI driver ships as an add-on: standard and physical-disk StorageClasses, online volume expansion, and LUKS2 at-rest encryption backed by Vault/OpenBao.

    Persistent storage

  • ExternalDNS & load balancers

    Service type=LoadBalancer gets a real external IP via a whitesky.cloud load balancer, and ExternalDNS publishes your ingress/service hostnames into whitesky.cloud-managed DNS automatically.

    DNS & load balancing

  • Air-gapped, zero-egress

    Run clusters with no public-internet egress: an in-cloudspace registry, pre-seeded with every image the cluster needs, serves all pulls locally over TLS.

    Air-gapped clusters

  • Day-2 on autopilot

    Rolling Kubernetes upgrades, MachineHealthCheck-driven self-remediation, automatic certificate & credential rotation, disk auto-growth, and drift/orphan garbage collection.

    Day-2 operations

Why it’s different

How many Cluster API providers give you geo-redundant Kubernetes with tested DR, encrypted storage, external DNS and air-gapped installs — all included, all reconciled? CAPVCO’s design principle is that the hard, boring, safety-critical parts of running clusters (backups you can actually restore from, upgrades that preserve etcd quorum, credentials that rotate before they expire) are the product, not an exercise left to the reader.

It is also white-label-generic: the whitesky.cloud portal URL, IAM/JWT-refresh URL, customer id and credentials are all deployment configuration — nothing brand-specific is compiled in — so the same build works against any whitesky.cloud portal. You run one provider instance per portal.

The mental model

flowchart LR
  subgraph mgmt["Management cluster"]
    capi["Cluster API core"]
    capvco["CAPVCO controller"]
  end
  subgraph wsc["whitesky.cloud"]
    cs["Cloudspace(s) — per cluster, isolated"]
    lb["L4 load balancer (:6443 endpoint)"]
    cp["Control-plane VMs"]
    wk["Worker VMs"]
  end
  user["You: kubectl apply cluster.yaml"] --> capi
  capi --> capvco
  capvco -->|provision + reconcile| cs
  cs --> lb --> cp
  cs --> wk

You apply a Cluster (+ VCOCluster, KubeadmControlPlane, MachineDeployment) to the management cluster. CAPVCO reconciles it into real whitesky.cloud infrastructure and hands you back a workload cluster you use like any other Kubernetes.

CRD Role
VCOCluster Cluster-scoped infra: cloudspace(s), control-plane endpoint/LB, geo mesh, backups, registry, storage & drift policy.
VCOMachine One VM: image, sizing, data/etcd disks, disk-growth policy, provider-id, addresses.
VCOClusterTemplate / VCOMachineTemplate Templates consumed by CAPI’s Cluster / KubeadmControlPlane / MachineDeployment.

The complete, field-by-field reference is generated from the Go types — see Reference → CRD API.

Next step

New to all this? → Core concepts explains Kubernetes, Cluster API and whitesky.cloud in plain terms, then walks you to a running cluster. In a hurry and already fluent? → Install the provider.