Managed Kubernetes clusters
Create and size tenant Kubernetes clusters from Skyline.
Use managed Kubernetes when you need a tenant cluster created from the platform template. Use Skyline for one-off clusters and inspection. Use Terraform when cluster creation should be repeatable.
🧭 Plan before creating clusters
Kubernetes clusters consume quota across compute, networking, and storage. Decide the template, master count, master flavor, worker sizing, network, and kubeconfig handling before submitting the request.
Current tenant template
The current tenant-facing Kubernetes template is:
| Field | Value |
|---|---|
| Cluster template | k8s-capi-helm-ubuntu-v1.34.7 |
| Node image | ubuntu-jammy-kube-v1.34.7 |
| Kubernetes version | v1.34.7 |
Use this template when creating the cluster from Skyline or Terraform. If the visible template list differs, use the template documented by your project onboarding before creating the cluster.
Template
Select k8s-capi-helm-ubuntu-v1.34.7.
Network and access
Confirm network, floating IP, security group, and app exposure requirements.
Kubeconfig
Treat generated kubeconfigs as sensitive files and keep them out of Git.
Creation time
Wait for a clear final state before deleting and recreating a cluster.
Find cluster templates
In Skyline, open Containers, then Cluster Templates to confirm:
- Template name.
- Kubernetes version.
- Node image.
- Allowed networking and flavor options.
Templates define what tenants can request.
Plan a cluster
Before creating a cluster, decide:
- Project and quota.
- Cluster template:
k8s-capi-helm-ubuntu-v1.34.7. - Number of Master Nodes.
- Master flavor.
- Worker node count.
- Worker flavor.
- Keypair, if requested by the form.
- Network and floating IP requirements.
- Security groups and app exposure model.
- Where the kubeconfig will be stored.
Master nodes
Use an odd number of master nodes. Recommended values are 1, 3, or 5.
For a stable default cluster, use 3 master nodes with the m1.medium flavor or larger. The master count should be odd because the Kubernetes control plane and etcd rely on quorum. Avoid 2 master nodes: an even control-plane count does not improve quorum behavior the way users usually expect.
Use at least m1.medium for master nodes. In this cloud, m1.medium provides:
| Resource | Minimum recommended value |
|---|---|
| vCPU | 2 |
| RAM | 4 GiB |
Smaller master flavors are likely to be unstable or slow for the Kubernetes API server, scheduler, controller manager, etcd, cluster startup, and addons.
Worker nodes
Size worker nodes separately from the control plane. m1.medium is a safe default, but smaller worker flavors can be acceptable for light test workloads when the pods fit.
With autoscaling enabled:
| Field | Meaning |
|---|---|
| Number of Master Nodes | Exact control-plane count. |
| Number of Nodes | Maximum worker count. |
min_node_count | Initial and minimum worker count. |
Without autoscaling, treat Number of Nodes as the requested worker count.
Cluster storage
Storage for the current template is controlled by template labels, not by the flavor disk size.
Current baseline:
| Node type | Storage |
|---|---|
| Master | 20 GiB root disk plus 5 GiB etcd disk |
| Worker | 20 GiB root disk |
Generated kubeconfigs are sensitive. Do not commit or share them.
🔒 Keep kubeconfigs private
A kubeconfig can grant cluster access. Store it like a secret and never commit it.
Create from Skyline
- Switch to the correct project.
- Open Containers, then Clusters.
- Click Create Cluster.
- Select the cluster template
k8s-capi-helm-ubuntu-v1.34.7. - Enter the cluster name, master count, master flavor, worker count, worker flavor, and required network details.
- Submit the request and monitor cluster status.
Cluster creation can take time. Backend polling errors or temporary status messages do not always mean final failure. Avoid deleting and recreating repeatedly unless the cluster reaches a clear failed state.
Use Terraform for repeatable clusters
Terraform is often better for managed Kubernetes because it keeps cluster size, template choice, generated files, and related network resources together. The mustelinet tenant workflow should use the public template values exposed to tenants.
Keep generated cluster files under a local generated/ directory when applicable, and exclude kubeconfigs and private keys from version control.