Frostmoln Docs

English

Svenska
Suomi
Norsk

English

Svenska
Suomi
Norsk

Appearance

Managed Kubernetes ​

Frostmoln Managed Kubernetes runs RKE2 clusters on Frostmoln compute. You manage your workloads; the platform provisions and manages the control plane, the worker nodes, the API load balancer, and your kubeconfig.

Pilot — access is granted per project

Managed Kubernetes is rolled out as a pilot. It appears in the portal only for projects that have been granted the kubernetes entitlement — if you don't see Kubernetes in the navigation, it isn't enabled for your project yet. Contact support to request access (there is no self-service enablement during the pilot). It is currently managed through the portal — see the note on CLI / Terraform below.

Create a cluster ​

In the portal, go to Kubernetes → Clusters → Create and choose:

  • Name.
  • Kubernetes version — currently 1.34 or 1.35 (the recommended version is marked); the dropdown is the source of truth.
  • Control-plane tier:
    • development — single control-plane node (lowest cost).
    • production — single control-plane node, production SLA.
    • enterprise — highly-available control plane (3 nodes).
  • VPC + subnet the cluster runs in (the region is inherited from the VPC).
  • Floating IP (optional) — bring your own, or let the platform allocate one for the API endpoint. A platform-allocated IP is released when the cluster is deleted; a bring-your-own IP is only disassociated, never released.
  • An initial node pool — a name, a node flavor (k8s.gp1.small / k8s.gp1.medium / k8s.gp1.large), and a node count.

CLI & Terraform

Managed Kubernetes is portal-managed today — there are no fm kubernetes CLI commands or Terraform resources for clusters yet. Create and manage clusters from the portal; once you have a kubeconfig you use kubectl, Helm, and your normal Kubernetes tooling against the cluster as usual.

Get your kubeconfig ​

When the cluster is running, use Download Kubeconfig on the cluster detail page. Point kubectl at it and you're in:

bash
export KUBECONFIG=~/Downloads/my-cluster-kubeconfig.yaml
kubectl get nodes

The Kubernetes API server is reached through a dedicated load-balanced endpoint (port 6443). The cluster's credentials are generated and held securely by the platform — node bootstrapping never transmits secrets back.

Node pools ​

A cluster has one or more node pools — groups of worker nodes of a given flavor. From the cluster detail page you can:

  • Add a node pool (name, flavor, node count), optionally with labels and taints for scheduling.
  • Scale a pool by setting a new node count.
  • Delete a pool.

Scale manually for now

Cluster autoscaling is not yet available — set the node count explicitly and scale pools manually as your workload changes.

Persistent storage ​

Clusters ship with a Frostmoln CSI storage class, frostmoln-block (the default StorageClass), backed by Frostmoln block storage. Create a PersistentVolumeClaim and a volume is provisioned and attached automatically; volumes support online expansion.

yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ['ReadWriteOnce']
  storageClassName: frostmoln-block
  resources:
    requests:
      storage: 20Gi

Networking ​

The cluster CNI is Cilium. Cluster nodes have internet egress but are isolated from Frostmoln's internal networks — your workloads run in their own tenant network. Expose the API server via the cluster endpoint above; expose your own services with an Ingress controller or a NodePort reachable through the node addresses.

Limits ​

  • One zone per cluster — nodes are placed in the cluster's region/subnet; no multi-AZ spread today.
  • Cilium is the only CNI — it isn't customer-selectable.
  • No in-place version upgrades yet — choose your version at create time.
  • Autoscaling is not yet available (scale node pools manually).
  • Deleting a cluster removes its nodes, API load balancer, a platform-allocated floating IP, and its stored credentials.