Run Slurm as a Kubernetes scheduler. A Slinky project.
Slurm and Kubernetes are workload managers originally designed for different kinds of workloads. Kubernetes excels at scheduling workloads that run for an indefinite amount of time, with potentially vague resource requirements, on a single node, with loose policy, but can scale its resource pool infinitely to meet demand; Slurm excels at quickly scheduling workloads that run for a finite amount of time, with well-defined resource requirements and topology, on multiple nodes, with strict policy, and a known resource pool.
This project enables the best of both workload managers. It contains a Kubernetes scheduler to manage select workloads from Kubernetes, which allows for co-location of Kubernetes and Slurm workloads within the same cluster. This means the same hardware can be used to run both traditional HPC and cloud-like workloads, reducing operating costs.
Using slurm-bridge, workloads can be submitted from within a Kubernetes
context as a Pod, PodGroup, Job, JobSet, or LeaderWorkerSet and from a
Slurm context using salloc or sbatch. Workloads submitted via Slurm will
execute as they would in a Slurm-only environment, using slurmd. Workloads
submitted from Kubernetes will have their resource requirements translated into
a representative Slurm job by slurm-bridge. That job will serve as a
placeholder and will be scheduled by the Slurm controller. Upon resource
allocation to a K8s workload by the Slurm controller, slurm-bridge will bind
the workload's pod(s) to the allocated node(s). At that point, the kubelet will
launch and run the pod the same as it would within a standard Kubernetes
instance
For additional architectural notes, see the architecture docs.
Slurm is a full featured HPC workload manager. To highlight a few features:
- Priority: assigns priorities to jobs upon submission and on an ongoing basis (e.g. as they age).
- Preemption: stop one or more low-priority jobs to let a high-priority job run.
- QoS: sets of policies affecting scheduling priority, preemption, and resource limits.
- Fairshare: distribute resources equitably among users and accounts based on historical usage.
- Exclusive, whole node allocations are made for each pod.
Create a secret for slurm-bridge to communicate with Slurm.
export SLURM_JWT=$(scontrol token username=slurm lifespan=infinite)
kubectl create namespace slurm-bridge
kubectl create secret generic slurm-bridge-jwt-token --namespace=slinky --from-literal="auth-token=$SLURM_JWT" --type=OpaqueInstall the slurm-bridge scheduler:
helm install slurm-bridge oci://ghcr.io/slinkyproject/charts/slurm-bridge \
--namespace=slinky --create-namespaceFor additional instructions, see the quickstart guide.
Project documentation is located in the docs directory of this repository.
Slinky documentation can be found here.
Feature requests, code contributions, and bug reports are welcome!
Github/Gitlab submitted issues and PRs/MRs are handled on a best effort basis.
The SchedMD official issue tracker is at https://support.schedmd.com/.
To schedule a demo or simply to reach out, please contact SchedMD.
Copyright (C) SchedMD LLC.
Licensed under the Apache License, Version 2.0 you may not use project except in compliance with the license.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.