skip to Main Content


TL;DR: The alpha release of the Singularity CRI can be found here; it is validated on a continuous basis. 

Last week, we tagged the alpha release of Singularity Container Runtime Interface (CRI) via the project’s GitHub repository. For those who haven’t been following our succession of updates in arriving at this important milestone to natively integrate the Singularity container runtime with Kubernetes, suffice it to say that this project has advanced rapidly over the past three months! In this post we describe the alpha release itself, our process of continuous validation, and close out with next steps.

The Alpha Release Itself

Even though we still have a few issues to address (see below), the alpha tag means we’re extremely keen to have you following the installation instructions we’ve documented here in building the CRI from source. Once you have a working deployment, you can test out a simple usage example that, of course, involves cat pictures.

If you’d prefer to bypass the need to build from source, you can jump to the Sykube part of our documentation here. Inspired by Minikube, Sykube allows you to run a Kubernetes (K8s) container cluster locally that includes the Singularity runtime and Singularity CRI; of course, we are distributing ready to use Sykube as a Singularity container via the Sylabs Cloud Container Library. Armed with Sykube, you can test the Singularity CRI with an arbitrary number of nodes, and even deploy a K8s environment that exists emphermerally in a temporary filesystem. Once deployed, this Sykube based environment can be employed to work through the feline use case example alluded to above.   

When you have something to do, implement a CRI in our case, the first thing to consider is which tools to use and why. Go was initially designed to build things like this, it has a great standard library and awesome built-in features. That allows developers to focus on writing what is really needed, without thinking hard about how to organize things. Moreover, taking into account that Go is the de facto language for everything to do with containers (Docker, Kubernetes, OCI packages, cni, etc.), using it means having the ability to reuse software from a huge open source codebase. Last but not least, Go has recently introduced modules support; this support eliminates dependency tracking issues, and makes the build and deploy process easy and reproducible

Sasha Yakovtseva, lead contributor, Singularity CRI  

Continuous Validation

Because any CRI needs to pass a suite of validation tests, there exists a quantitative measure of compliance. When the project was first announced at the end of November 2018, Singularity CRI passed only 10 of 71 validation tests – frankly speaking, that wasn’t too shabby for our early commits. As of the latest alpha release however, Singularity CRI is now passing 70 of 74 validation tests. If you’re interested in the details, by checking here, you’ll be able to identify the final four tests that remain outstanding. Of these, one simply does not apply, whereas another will be addressed with our next release of SIF – the Singularity Image Format employed to containerize runtimes for use in Singularity. The final two tests that still require some attention only apply to those making use of SELinux – tests we’ll continue to work on with the assistance of the open source community.

If you’ve been following Sylabs and the broader Singularity development in almost any way, it’ll come as no surprise to you that we’ve collectively and systematically been placing increasing emphasis on the quality of our software. Fortunately, for all stakeholders, this same emphasis is being applied to Singularity CRI. In fact, the 74 CRI validation tests alluded to above now comprise unit tests in our Continuous Integration (CI) workflow. A high-level overview of this workflow is as follows:

  • Each time code is committed to the master branch for this project, our CI solution (namely CircleCI) checks out a copy for testing purposes
  • CircleCI runs the checked out code through a five-step workflow that includes the validation tests detailed here – tests that ultimately quantify the results of testing via artifacts (the validation.out file of validation_tests job)

With CI in place, the validity of the Singularity CRI implementation will be assessed on an ongoing basis – literally, with each code commit. With this almost real time feedback, and as development becomes increasingly DevOps, all stakeholders are kept apprised as to the continuously validated quality of this integration – for example, as Go modules are systematically introduced.

Next Steps

Whether your preference is to work from the source-code level or via Sykube, we encourage to investigate Singularity CRI as soon as possible. In so doing you will, of course, be contributing to the Singularity community. We look forward to your feedback, and learning how Singularity CRI might factor into your initiatives.

Back To Top