Kubernetes limits and compatibility on Cloider
Cloider clusters run standard Kubernetes, so manifests, Helm charts and tools written for Kubernetes work on them. A few things work differently because Cloider manages the control plane, the nodes and the network for you. This page lists the versions, the limits that the platform enforces, and the differences to plan for.
Kubernetes versions
| Versions offered | 1.34, 1.33 and 1.32, newest first. The newest is the default |
| Where the list comes from | GET /api/options returns it as cluster_versions. The CLI's --version, the Terraform version attribute and the MCP version parameter are checked against it |
| Upgrades | Not in place. A cluster keeps the version it was created with; create a new cluster to move to another version |
| Exact version | Run kubectl version to see the patch version a cluster runs |
kubectl version
Client Version: v1.34.1
Server Version: v1.34.1
Moving to a new version
Since there is no in-place upgrade, a version change is a migration:
- Create a new cluster, for example
production-2, with the new version. - Deploy your workloads into it, ideally from the same manifests, Helm values or Terraform configuration.
- Copy the data of your PersistentVolumeClaims if you have any.
- Switch your targets to the new cluster's Services (
cloider target update <domain> <target-id> --cluster production-2 --service shop/web) and update DNS records for load balancer IPs. - Delete the old cluster.
Check your manifests for APIs that were removed in the new version before you move, with the Kubernetes deprecation guide.
Tool compatibility
| Tool | Notes |
|---|---|
kubectl | Use a version within one minor version of the cluster's (the standard Kubernetes version skew policy) |
| Helm | Helm 3. Preinstalled in the browser terminal |
| Terraform | The kubernetes and helm providers, configured from cloider_cluster's kube_config. The helm provider 3.x takes kubernetes as an attribute |
| Lens, k9s, kubectx, Kustomize, Skaffold, Tilt, Argo CD CLI | Work with the kubeconfig like with any cluster. See Connect with kubectl |
| CI systems | Use the kubeconfig as a secret, or cloider cluster exec with an API token |
What works as on any Kubernetes cluster
- The standard Kubernetes API: Deployments, StatefulSets, Jobs, CronJobs, Services, ConfigMaps, Secrets, ServiceAccounts, RBAC, CustomResourceDefinitions and custom resources.
- Cluster admin access through the kubeconfig's client certificate.
- Cluster DNS: Services resolve as
<service>.<namespace>.svc.cluster.local. - The metrics API: the metrics server runs in every cluster, so
kubectl topand the HorizontalPodAutoscaler work. - PersistentVolumeClaims with the storage classes Cloider provides. See Persistent volumes.
- Services of type
LoadBalancer, which get a public IP. See Load balancers. - Helm charts and operators. See Helm.
What works differently
Ingress objects aren't served
Ingress objects you create in a Cloider cluster aren't published, so they have no effect. To serve HTTP and HTTPS on a domain, create a target, which routes a domain and path to a Service and provides the HTTPS certificate. For TCP and UDP, use a LoadBalancer Service.
Nodes are managed for you
Your pods run on nodes that Cloider operates. kubectl get nodes lists the nodes your cluster can schedule onto, but you don't administer them: you can't add, remove, resize or log in to nodes, and there are no node pools. Nodes can change over time, so don't pin workloads to specific node names.
Workloads built to administer nodes, such as node-level monitoring agents, CNI plugins, node provisioners or containers that need host access, are designed for clusters where you own the machines. On Cloider the nodes are managed for you, so design workloads that don't depend on host access.
A single control plane
Every cluster has one control plane. A highly available control plane isn't available: the API rejects is_ha: true with HA clusters are not supported at the moment!. Your workloads can still run several replicas for availability.
The control plane is sized for typical applications. Very large numbers of objects, or controllers that call the API server constantly, can make it slower.
The control plane is part of your compute bill
The control plane and the cluster DNS are billed like your own pods, on the larger of their requests and their use, so a running cluster always has a small compute cost. Pausing the cluster stops it. See How is a cluster billed?.
Cloider components in kube-system
Every cluster has a few components that Cloider installs and relies on, in kube-system: the cluster DNS, the metrics server and the terminal Deployment used by the browser terminal and cloider cluster exec. Don't delete or modify them.
Limits
Account and plan limits
| Limit | Value |
|---|---|
| Clusters on the Free plan | 1 (paused clusters count, deleted ones don't) |
| Clusters on a paid plan | No fixed limit in the API |
| Creating clusters on a suspended account | Refused until the account is upgraded |
| Read-only members and Read API tokens | Can list clusters, check status and download kubeconfigs, but not create, pause, resume or delete clusters, or run exec |
Names
| Limit | Value |
|---|---|
| Cluster name characters | Lower case letters, digits and - |
| Cluster name start and end | Starts with a letter, doesn't end with - |
| Cluster name length | At least 2 characters |
| Unique cluster names | Not required. Duplicate names get labels name-1, name-2, ... |
| Target: Service name + namespace + cluster name | At most 57 characters together |
| Target paths | Start with /; letters, digits and / _ . - only |
Terminal and exec
| Limit | Value |
|---|---|
| Browser terminal tabs | Up to 4 at a time |
exec stdin | 2 MiB |
exec timeout | Default 10 minutes, at most 1 hour |
Terminal URL token (GET /api/clusters/{id}/terminal) | Valid for about 2 minutes |
| Terminal filesystem | Not persistent |
Operations
| Operation | Limit |
|---|---|
| Rename a cluster | Not possible |
| Change the Kubernetes version | Not possible in place |
Use kubectl, the kubeconfig, the terminal or exec | Only while the cluster is Ready |
CLI --wait | Waits up to --timeout, default 15 minutes |
| Terraform | Create, update (pause and resume) and delete wait up to 20 minutes by default |
Limits for other products are in Limits and quotas.
Next steps
- Troubleshooting for the errors these limits produce.
- Expose services on a domain, the replacement for Ingress.
- Pricing.
Frequently asked questions
Which Kubernetes version does Cloider run?
New clusters can be created with Kubernetes 1.34, 1.33 or 1.32, newest first. kubectl version shows the exact server version of a cluster.
Can I upgrade a Cloider cluster to a newer Kubernetes version?
Not in place. A cluster keeps the version it was created with. Create a new cluster with the newer version, deploy your workloads into it, switch your targets and DNS, then delete the old cluster.
Is the Cloider Kubernetes control plane highly available?
No. Every cluster has a single control plane, and the API rejects requests for a highly available one. Run several replicas of your own workloads for availability.
Can I use Ingress controllers on Cloider?
Ingress objects inside a Cloider cluster are not served. Use targets to route domains and paths to Services with automatic HTTPS, or a LoadBalancer Service for raw TCP and UDP.
Can I manage the nodes of a Cloider cluster?
No. Nodes are operated by Cloider. kubectl get nodes lists them, but you cannot add, remove, resize or log in to them, and there are no node pools.