Managed Kubernetes

Hippius managed Kubernetes gives you an RKE2 cluster whose control plane runs on three confidential VMs. Its admin credentials are sealed to a key generated in your browser, so Hippius never holds them in the clear. This page explains how the cluster is built, the key file you must keep, and how to create a cluster and reach its API.

Open it from the sidebar: Confidential Computing → Kubernetes.

How a cluster is built

• Three masters. Every cluster has three control-plane nodes ("masters") running RKE2 with embedded etcd, each on its own confidential VM. There is no single-master option. Each master has its own public IPv4 address for the Kubernetes API, on port 6443.
• One region. All three masters run in the country you choose. etcd commits every write on a majority of the masters, so they have to be close to each other.
• Kubernetes version. New clusters run RKE2 v1.34.3+rke2r1.
• Networking. The nodes talk to each other over your private network, with the Canal network plugin.

Compact or standard

Mode	Masters	Your workloads run on
Compact (default)	Schedulable	The three masters. Add worker pools later if you need more.
Standard	Control plane only (tainted NoSchedule)	Worker pools. Pods stay Pending until a pool has nodes.

Master sizes

Size	Each master is a VM of size
Small (default)	Medium
Medium	Large
Large	X-Large

The create form shows each size's vCPUs, memory, disk and price per master.

What isn't included yet

Plan for these before you move a workload

• No load balancers and no ingress controller. Service type=LoadBalancer isn't supported, no ingress controller is installed, and worker nodes have no public IP. There is no built-in way yet to publish a workload to the internet.
• No default storage class. Bring your own storage manager, such as Longhorn, on the nodes' local disks. /var/lib/longhorn is already on each node's encrypted data disk. Larger nodes give better storage performance.
• No upgrades yet. A cluster stays on the version it was created with, and the kubeconfig can't be reissued.
• API access ranges are set at creation. They can't be changed afterwards.

The cluster key file

When you create a cluster, the console generates a key file in your browser: hippius-cluster-NAME.key. Hippius only ever receives its public half.

You need the key file to:

• get the cluster's kubeconfig and server token, which the masters seal to your key;
• open the cluster's backups (etcd snapshots and the Velero backup keys);
• sign worker pool and node operations. The masters refuse a node you didn't sign.

A lost key file can't be recovered

Nobody, Hippius included, can recover or reset it. If you lose it, the cluster keeps running and a kubeconfig you already downloaded keeps working. But the sealed secrets and backups can never be opened again, and you can't add or replace nodes. You can still remove nodes, unless a node holds local data: accepting that loss needs a signature from your key.

Keep the key file somewhere safe and backed up, for example in a password manager. Keep the server token with it.

Create a cluster

Click New cluster. The form is one page in five steps, with a Summary panel on the side.

1. Name and region. A name of lowercase letters, digits and hyphens, up to 40 characters, for example prod-eu. It names the key file too. Then pick the country all three masters run in. The form tells you if no server there can take a master of the size you chose.
2. Control plane. Choose Compact or Standard, and the Master size. Prices are for the three masters and their three public IPv4 addresses.
3. API access. Add the IPv4 ranges allowed to reach the Kubernetes API. See Restrict API access.
4. Cluster key. Click Download hippius-cluster-NAME.key, store the file, and tick the box to confirm you stored it.
5. Add-ons. Leave Automatic backups to your Hippius S3 on, unless you have your own backups. Backups can only be turned on at creation. They need an S3 account; see Kubernetes backups.

Check the Summary and click Create cluster. Worker pools are added after the cluster is running; see Worker pools.

The cluster's page shows its progress: Masters booted, Private network joined, RKE2 installed, Masters found each other, Kubernetes API ready, Kubeconfig sealed to your key and Masters ready.

The quota and 24-hour balance checks apply to the three masters and their public IPv4 addresses. A cluster uses three of your public IPv4 quota.

Restrict API access

Only the IPv4 ranges you list can reach the Kubernetes API on port 6443. Everything else is blocked, both at the network edge and on the masters.

• Add at least one range, and at most 20.
• Add the public address you run kubectl from as a /32, for example 203.0.113.7/32. Searching "what is my IP" in a browser shows it.
• Add the addresses of anything else that calls the API, such as your CI.

You can allow 0.0.0.0/0, but the console warns you: your API is then open to the whole internet, and only its certificates protect it.

Ranges can't be changed later

The ranges are fixed when the cluster is created. Include every address you'll need, such as a fixed office or VPN address.

Get your kubeconfig

The masters seal the kubeconfig to your key 5 to 10 minutes after they are up.

1. On the cluster's page, in the Kubeconfig panel, click Load key file and choose your hippius-cluster-NAME.key. The console checks it belongs to this cluster.
2. Click Download kubeconfig. You get NAME-kubeconfig.yaml.
3. Click Download server token too, and store it with your key file. You need it to restore the cluster from an etcd snapshot.

The signature is checked and the file is decrypted in your browser. Neither your key nor the kubeconfig is sent anywhere. You can download the kubeconfig again whenever you need it, as long as you have the key file.

Then use it:

export KUBECONFIG=$PWD/NAME-kubeconfig.yaml
kubectl get nodes

The kubeconfig authenticates as the cluster administrator with a client certificate. It has one context per master, m0, m1 and m2, and m0 is selected. If a master is down, switch to another:

kubectl config use-context m1

Treat the kubeconfig as a root password

It can't be revoked or reissued yet. Anyone who has it, and can reach the API from an allowed address, is cluster administrator.

Delete a cluster

On the cluster's page, click Delete, type the cluster's name and click Delete cluster. The three masters, the workers and everything running on them are destroyed. This can't be undone. Billing stops when you ask to delete.

Backup buckets that hold backups are kept in your S3 account; see After you delete a cluster.

Billing

A cluster costs its VMs, like any VM, plus a management fee of $15 per cluster per month, whatever its size or number of workers. The VMs are the three masters at their size's price, their three public IPv4 addresses at $0.005 an hour each, and each worker at its size's price. The smallest control plane, three Medium masters, comes to $192 + about $11 for the addresses + $15 = about $218 a month, before workers. Backups are billed as S3 storage in your account, at your S3 price. See Management fees and the live price list.

If your compute usage stays unpaid, see If your balance runs out.

In a shared account, only the owner can create a cluster and open its kubeconfig and backups: they need the owner's key file.

What you trust Hippius with

After launch, Hippius holds no readable kubeconfig and no certificate authority, and no shell on the nodes: no SSH keys are installed for it and the browser terminal is refused. Adding a node or opening an access needs a signature from your key, and the kubeconfig and backup keys are stored only sealed to your key. That holds as long as the images and boot configuration Hippius gives the nodes are honest. Some trust remains:

• Images and boot configuration. Like every Hippius VM, the masters and workers run images that Hippius builds and approves, with a boot configuration that Hippius writes. A malicious or compromised Hippius could change them. See Trust model and limits.
• The launch. The public halves of your key are handed to the masters when the cluster is created, and the server token passes through Hippius once at that moment.
• The console code that generates your key and decrypts your secrets is served by Hippius.
• Adding workers. Until node attestation ships, a worker's join token passes through Hippius on its way to the new node. The private network limits who could use it, but that network is also operated by Hippius.
• Placement. The three masters are not yet guaranteed to run on three different servers.

Where to next

• Worker pools: add, scale and replace nodes.
• Kubernetes backups: etcd snapshots and Velero, and how to restore them.