Cluster

A Cordium Cluster runs on top of an existing Octelium Cluster. Before installing Cordium, you must have a working Octelium Cluster running on Kubernetes. See the Octelium installation guide for instructions.

Preparing Kubernetes Nodes

Cordium Workspaces run inside ordinary Kubernetes pods managed by the Cordium controllers. Nodes that are allowed to host Workspaces must be explicitly labeled. For example, to allow a node named node-1 to host Cordium Workspaces:

In other words, Cordium only schedules Workspaces onto nodes explicitly labeled with octelium.com/node-mode-cordium. You can repeat this operation for multiple nodes or node pools if you want to dedicate several nodes to Workspaces. This separation is intentional and allows operators to isolate Workspaces from Cordium control plane components, as well as Octelium control-plane and data-plane components running on the same Kubernetes cluster.

Installing the Cordium Package

After preparing the Kubernetes nodes, you can install Cordium as an Octelium package using the octops install-package command as follows:

You can override the kubeconfig path explicitly:

Storage

Cordium uses Kubernetes persistent storage for Workspace filesystems. Storage is provisioned via a CSI driver and a StorageClass. There are two distinct storage requirements with different levels of necessity.

StorageClass

Every Workspace, persistent or ephemeral, uses a PersistentVolumeClaim. A StorageClass capable of dynamic PVC provisioning is required for Cordium to function. Workspace PVCs use ReadWriteOnce access mode, since each Workspace attaches its PVC to a single pod. Suitable drivers include Longhorn, AWS EBS CSI, GCP Persistent Disk CSI, Azure Disk CSI, Rook-Ceph with RBD, and OpenEBS with block storage.

If the cluster has multiple StorageClasses, Cordium selects the one to use for a given Workspace through a CEL expression configured in ClusterConfig. The expression receives the Workspace spec and context and returns a StorageClass name. This allows different storage tiers to be assigned to different Workspace types. For example, you can dynamically use fast NVMe-backed storage for interactive development Workspaces and standard block storage for ephemeral agent runs.

VolumeSnapshotClass

Template pre-builds work by snapshotting the fully initialized storage of a completed build Workspace and restoring from that snapshot on subsequent Workspace starts. This requires a CSI driver that implements the Kubernetes VolumeSnapshot API and a corresponding VolumeSnapshotClass installed in the cluster.

Without snapshot support, Cordium installs and operates normally but Template pre-builds are unavailable. Every Workspace starts from scratch regardless of whether a pre-build has been triggered. Block storage drivers that support VolumeSnapshot include Longhorn, AWS EBS CSI, GCP Persistent Disk CSI, Azure Disk CSI, and Rook-Ceph with RBD. As with StorageClass, you can also dynamically choose VolumeSnapshotClass on a per-Template basis via CEL expressions.