Cluster Configuration and Management Guide on Cozystack

Scheduling Classes

Mon, 01 Jan 0001 00:00:00 +0000

SchedulingClass is a cluster-scoped custom resource that lets administrators define placement policies for tenant workloads. When a tenant is assigned a scheduling class, all of its pods are automatically routed to the Cozystack custom scheduler, which merges the class-defined constraints with any constraints already present on the pod.

This allows platform operators to pin tenants to specific data centers, availability zones, or node groups — without modifying individual application charts.

Running Containerized GPU Workloads

Mon, 01 Jan 0001 00:00:00 +0000

This page covers running GPU workloads in regular Kubernetes pods (CUDA, ML training, inference) on Cozystack management cluster nodes. It targets the typical Linux GPU node shape — apt-installed NVIDIA driver plus nvidia-container-toolkit on Ubuntu/Debian — and uses the container variant of the cozystack.gpu-operator package. Other distros with an equivalent driver + toolkit package layout should work the same way but are not regularly tested.

If instead you want to pass whole GPUs to KubeVirt VMs, see GPU Passthrough and GPU Sharing with HAMi (HAMi provides fractional sharing in tenant Kubernetes clusters; stacking it directly on the container variant on the management cluster is not a supported combination yet — see Fractional GPU sharing below).

storageClass is immutable after creation

Mon, 01 Jan 0001 00:00:00 +0000

Every stateful Cozystack application that exposes a storageClass parameter declares it immutable in the chart schema (x-kubernetes-validations: [{rule: "self == oldSelf"}]). This document explains the contract and where it is enforced.

Why

storageClass binds the StatefulSet’s PVC template. Kubernetes fixes PersistentVolumeClaim.spec.storageClassName at PVC creation time — editing volumeClaimTemplates[].spec.storageClassName on an existing StatefulSet does not retroactively migrate any data. A user who edits storageClass on an existing resource may believe their data is being moved to the new class; it is not. Locking the field at the schema layer makes that contract explicit.