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.

Accessing Disa with Rancher¶

Rancher is a software of Kubernetes management. At C3SE, we use it for project/member management, as will as a web interface for installing Helm charts. It is currently the primary entrypoint of Disa, to start using Disa, login to rancher at:

https://rancher.c3se.chalmers.se

You should be redirected to Chalmers login, and if you are a member of a Disa project, you should see the resources belonging to your projects.

Helm charts¶

You can deploy pre-defines "Helm charts" (applications in Kubernetes world) via the web interface. In a nutshell:

• In Cluster > Projects/Namespaces, create a Namespace for your app;
• In Apps > Charts, choose a chart and go through the questions;
• Common options are exposed as a web form;
• You can also access more options by editing the values.yaml file directly.

Tools¶

In rancher, you can run some basic kubectl and helm commands, or use the k9s with a "Kubectl shell" (at the top bar). Those allows you to inspect and deploy Kubernetes resources directly. If you prefer running those on your own computer, you can also download you credential as KubeConfig.

See also:

• https://kubernetes.io/docs/reference/kubectl/

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).