CWL on Kubernetes
Calrissian is a CWL implementation designed to run inside a Kubernetes cluster. Its goal is to be highly efficient and scalable, taking advantage of high capacity clusters to run many steps in parallel.
Calrissian requires a Kubernetes or Openshift/OKD cluster, configured to provision PersistentVolumes with the
ReadWriteMany access mode. Kubernetes installers and cloud providers don't usually include this type of storage, so it may require additional configuration.
Calrissian has been tested with NFS using the nfs-client-provisioner and with GlusterFS using OKD Containerized GlusterFS. Many cloud providers have an NFS offering, which integrates easily using the nfs-client-provisioner.
Scalability / Resource Requirements
Calrissian is designed to issue tasks in parallel if they are independent, and thanks to Kubernetes, should be able to run very large parallel workloads.
calrissian, you must provide a limit the the number of CPU cores (
--max-cores) and RAM megabytes (
--max-ram) to use concurrently. Calrissian will use CWL ResourceRequirements to track usage and stay within the limits provided. We highly recommend using accurate ResourceRequirements in your workloads, so that they can be scheduled efficiently and are less likely to be terminated or refused by the cluster.
To view open issues related to conformance, see the conformance label on the issue tracker.
Please see examples for installation and setup instructions.
Calrissian's behaviors can be customized by setting the following environment variables in the container specification.
By default, pods for a job step will be deleted after termination
false, job step pods will not be deleted.
Kubernetes API retries
When encountering a Kubernetes API exception, Calrissian uses a library to retry API calls with an exponential backoff. See the tenacity documentation for details.
5. Unit for multiplying the exponent interval.
5. Minimum interval between retries.
1200. Maximum interval between retries.
10. Max number of retries before giving up.