Kubernetes

What it is

A Kubernetes cluster here is a group of virtual machines provisioned as one unit: a load balancer, the control plane nodes for the cluster type you picked, and a pool of worker nodes running Talos Linux, on a private network with one public IPv4 address. You get a kubeconfig for the cluster from the panel or the API, and the platform installs the optional components you selected when you created it. Everything the cluster contains is billed against your prepaid cloud balance.

Getting started

1. Create an account and confirm your email address. No cloud resource, a cluster included, can be created while the address is unverified.
2. Add funds. Creating a cluster checks that your balance covers at least one hour of the whole thing: the public IPv4 address, the load balancer, every control plane node and every worker node.
3. Open Kubernetes in the panel and go to Clusters, then Add, at /panel/kubernetes/clusters/add/. Choose Development or Production, a worker node package, and a pool size between the minimum and maximum that cluster type allows.
4. Select the optional components you want installed with the cluster: cert-manager, Ceph CSI, Metrics Server, CloudNative PG, MariaDB Operator and MongoDB Operator.
5. Create the cluster, then take the kubeconfig from the cluster page or from GET /api/v1/kubernetes/clusters/{id}/kubeconfig/. A POST to the same address issues a fresh one.
6. The same cluster can be created in one call with POST /api/v1/kubernetes/clusters/, and the cluster types on offer are listed at /api/v1/kubernetes/cluster-types/.

Production clusters are created with delete protection switched on. You turn it off yourself on the cluster page; until you do, both the panel and the API refuse to destroy the cluster.

Limits

The first two apply per account and are raised by support on request. A resource pool is a group of worker nodes inside a cluster and every cluster needs one, so the pool limit caps how many clusters you can run as well. The rest are properties of a single cluster, fixed when it is built.

The storage rows are worth reading twice. The quota itself is a soft figure, and nothing happens the moment you pass it. When usage reaches the quota plus 100 GB, the cluster storage stops accepting writes: running pods keep reading, but nothing new can be written. That reverses on its own once usage drops back under the threshold.

Funds matter after creation too. A cloud service is suspended 2 days after it stops being paid for, and everything it owns is suspended with it, a Kubernetes cluster included. It is destroyed 7 days after that.

What needs support

• Raising the number of clusters or resource pools your account may have.
• Raising a cluster storage quota. You cannot set it yourself from the panel or the API.
• Encrypted traffic between cluster nodes. It is switched off on the platform, and where it is switched on only staff can change it, so it is not something you can turn on for your own cluster.
• Choosing or forcing a load balancer upgrade. The platform works out on its own whether one is available for your cluster and which one it is. You never name it, and when nothing is on offer there is nothing to press.
• The Beta cluster type. It exists for testing candidate images and is refused to customers at every entry point.
• Recovering a destroyed cluster. Destruction takes the nodes with it and releases the cluster network back to the pool, so there is nothing left to restore.

Where to go next

• Kubernetes packages and pricing
• Kubernetes API quickstart