Kubernetes resource¶

C3SE operates a shared Kubernetes cluster (Disa) for users who wish to run containerized applications, with support for GPU workloads and persistent services. C3SE maintains several ready-to-deploy Helm charts, and advanced users may define their own services with standard Kubernetes API.

Getting started¶

Disa is currently running experimentally. Access to Disa is provided to researchers at cost, please contact us for details.

Differences from HPC resource¶

Services¶

Services on Disa can be easily published to be accessed elsewhere, for instance, you may host your database to be accessed on a HPC cluster, or host an AI to be integrated to other services; you may also bring your own authentication method to provide your service to users that are not suitable as project members (e.g. to host a service for participants of an experiment).

Batch jobs vs Deployments¶

While one run batch jobs on Disa, the typical usage for Kubernetes are the so-called Deployments. A Deployment defines a persistent application, for instance, running a LLM Deployment would ensure that one instance of the specified Pod is running, in the case of software of hardware failure, Kubernetes will automatically start a new pod. You may also replicate the Pods to achieve load-balancing or high availability.

Scheduling¶

Disa schedules workloads with the kueue scheduler. Like the Slurm scheduler on a HPC cluster, kueue manages workloads with fair-share mechanism to ensure efficient and fair usage of resources, unlike Slurm, workloads within your allocation are allowed to run persistently and bonus workloads are preempted promptly.

For example, if you have a project that allocates 4 GPUs, you may keep get more than 4 GPU tasks scheduled if the cluster is not busy; once other users request more resource, your excess workloads will be preempted (depending on your past usage).