Lightspeed Cloud's Kubernetes Service lets you spin up a managed Kubernetes cluster without provisioning and wiring together the underlying VMs yourself. The platform handles creating the control plane and worker node VMs, networking between them, and keeping the cluster in a known-good state.
Creating a cluster
From Containers → Kubernetes → Create Cluster, choose:
- A Kubernetes version from the supported list
- A compute offering for control plane and worker nodes
- The number of control plane nodes (for HA) and worker nodes
- The network the cluster should attach to - shared, isolated, or a VPC tier (see Networking Basics and VPC & Advanced Networking)
Cluster creation takes a few minutes while the underlying VMs are provisioned and Kubernetes is bootstrapped. Once ready, you can download the cluster's kubeconfig from the portal to manage it with kubectl.
Accessing the cluster
Beyond the downloaded kubeconfig, nodes are reachable over SSH through the cluster's public IP - port 2222 for the control plane, 2223 and up for worker nodes. The Kubernetes dashboard, if deployed, is typically reached by running kubectl proxy locally and logging in with a token, rather than being exposed directly.
Scaling a cluster
Worker node count can be increased or decreased after creation from the cluster's detail page - useful for handling more load or scaling back down during quiet periods. Scaling adds or removes worker VMs without affecting the control plane.
You can also move nodes to a larger compute offering after creation, but this is one-directional - scaling up to a bigger offering is supported, scaling back down to a smaller one isn't. If you need smaller nodes, scale worker count down and redeploy at the size you want instead.
Stopping and starting a cluster
A cluster that isn't in use can be stopped to save on compute costs, and started again later. Stopping a cluster stops the underlying VMs; workloads won't be reachable while it's stopped, but cluster state is preserved.
Upgrading Kubernetes versions
When a new Kubernetes version is available, existing clusters can be upgraded in place from the portal. The upgrade is rolled out node by node to minimise disruption to running workloads - schedule upgrades during a maintenance window for anything customer-facing.
Upgrades move one minor version at a time (e.g. 1.29 → 1.30, not 1.29 → 1.31 directly) - if you're several versions behind, you'll need to upgrade through each intermediate minor version in turn. Patch releases within the same minor version can be applied directly.
Deleting a cluster
Deleting a cluster tears down all of its control plane and worker VMs. As with any destructive action, make sure anything you need (persistent volumes, exported manifests, etc.) is backed up outside the cluster first.