> ## Documentation Index
> Fetch the complete documentation index at: https://www.latitude.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Clusters
> Create, access, upgrade, and delete LKS Clusters from the dashboard
An LKS Cluster is a managed Kubernetes Control Plane plus one or more [Node Pools](/docs/lks/node-pools) of bare metal Nodes. Latitude.sh runs the Control Plane; you manage the Cluster's Workloads and Node Pools.
## Prerequisites
* A [verified account](/docs/account-setup/verify-account) with a [payment method](/docs/billing/payment-methods).
* A [project](/docs/projects) selected in the dashboard.
* [`kubectl`](https://kubernetes.io/docs/tasks/tools/#kubectl) installed on your machine.
## Create a Cluster
Go to **LKS** in the sidebar and click **Create Cluster**.
Choose the region where the Cluster runs. Plan availability and pricing vary by region.
Enter a name of 3-63 lowercase letters, numbers, or hyphens, starting and ending with a letter or number. It must be unique within the project.
Add an optional description, up to 200 characters, to record what the Cluster is for.
Select the Kubernetes version for the Control Plane. The newest available version is selected by default.
Add one or more Node Pools. Each Node Pool has a **Plan** and a number of **Nodes**, and can carry its own Labels and Taints. See [Node Pools](/docs/lks/node-pools) for details.
Expand **Cluster networking** to set custom Pod, Service, and Node CIDRs. Most Clusters use the defaults. See [Cluster networking](#cluster-networking).
Review the [hourly price](https://www.latitude.sh/pricing) and click **Create Cluster**. You're taken to the Cluster overview while it provisions.
The Control Plane is fully managed. You don't size or access Control Plane Nodes, and no SSH keys are needed to create a Cluster.
## Cluster networking
A Cluster has three IP ranges: the Pod CIDRs, the Service CIDRs, and the Node CIDRs. LKS applies defaults that fit most Clusters, so you can accept them and skip this. To set your own ranges, expand **Cluster networking** in the create form and enter one IPv4 CIDR per field.
| Network | Default | Used for |
| - | - | - |
| Pod CIDRs | `10.0.0.0/12` | IP addresses assigned to Pods. |
| Service CIDRs | `10.96.0.0/15` | Virtual IPs assigned to ClusterIP Services. |
| Node CIDRs | `10.16.0.0/21` | Node addresses, from one range shared by every Node Pool. |
Each field is a list (`pod_cidrs`, `service_cidrs`, `node_cidrs`) in the [create cluster API](/docs/api-reference/lks/create-an-lks-cluster), but only a single value per field is supported today.
Only IPv4 ranges are accepted, and each must be a network address (host bits set to 0), for example `10.0.0.0/12`.
The three ranges are set only when the Cluster is created and can't be changed afterward, and they must not overlap each other. Choose them with room to grow.
### How Pod addresses are allocated
Cilium runs the Cluster network with cluster-pool IPAM. It carves the Pod CIDRs into a `/23` block for each Node, giving every Node about 510 Pod addresses, enough for the maximum of 500 Pods per Node. This per-Node block is fixed when the Cluster is created and is the same across every Node Pool.
Because Cilium manages Pod IPAM, LKS does not use the Kubernetes `Node.spec.podCIDRs` field. Ignore it: it isn't populated and isn't the source of truth for a Node's Pod range. That range is recorded on the Node's `CiliumNode` resource instead.
### Sizing custom ranges
Each Node takes a `/23` from the Pod CIDRs, so a shorter prefix allows more Nodes:
| Pod CIDR prefix | Max Nodes |
| - | - |
| `/12` (default) | 2,048 |
| `/14` | 512 |
| `/16` | 128 |
| `/18` | 32 |
| `/20` | 8 |
Size the Node CIDRs to hold at least as many addresses as the Pod CIDRs allow Nodes. A simple rule is to set the Node CIDR prefix to the Pod CIDR prefix plus 9: the default `/12` supports about 2,048 Nodes, matched by the default `/21` Node CIDRs.
## Cluster status
The Cluster list and overview show the current state:
| Status | Meaning |
| - | - |
| Provisioning | The Cluster is being created. |
| Active | The Cluster is ready to use. |
| Updating | A configuration change is being applied. |
| Upgrading | A Kubernetes version upgrade is in progress. |
| Degraded | The Cluster is running with reduced health. |
| Paused | Paused by Latitude support; changes are blocked until it's unpaused. |
| Deleting | The Cluster is being removed. |
| Error | The last operation failed. |
## Access the Cluster
Download the kubeconfig from the Cluster **Overview** tab, under **Cluster access**:
* **Download kubeconfig**: save the file to your machine.
* **Copy to clipboard**: copy the kubeconfig contents.
* **View**: preview the kubeconfig in the dashboard.
Connect with `kubectl`:
```bash theme={null}
kubectl --kubeconfig=./my-cluster-kubeconfig.yaml get nodes
```
The kubeconfig is available once the Cluster is **Active**.
## Name and description
On the **Settings** tab you can edit the Cluster's **Name** (its display name) and its **Description** (up to 200 characters).
## Upgrade the Kubernetes version
Latitude.sh publishes the Kubernetes versions available for upgrade. To upgrade the Control Plane, open the **Settings** tab. When a newer version is available, the **Version** row shows **Upgrade to** `{version}`; otherwise it shows **Up to date**.
A Control Plane upgrade can't be reversed.
Node Pools stay on their current version until you upgrade them, and a Node Pool can run at most one minor version behind the Control Plane. Upgrade each pool after the Control Plane. See [Upgrade a Node Pool](/docs/lks/node-pools#upgrade-a-node-pool).
## Delete a Cluster
Open the **Settings** tab and click **Delete**, or use **Delete Cluster** in the Cluster's actions menu. Type the Cluster name to confirm.
Deleting a Cluster is permanent. All Node Pools and their Nodes are destroyed, the LoadBalancer IP is released, and all data and Workloads are lost.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.