[Image credit: Yu-Ju Hong, Software Engineer, Google
Introducing Container Runtime Interface (CRI) in Kubernetes
Basically, the Singularity CRI implementation is a gRPC server which serves Kubelet requests by interoperating with the Singularity runtime. This server will interact with the Kubernetes CRI to natively spawn Singularity containers, and add SIF support to Kubernetes. As of this writing, the Kubernetes integration effort is underway, and the Singularity CRI already possesses an ImageService interface implemented and ready for testing; this ImageService interface is responsible for pulling, removing, and maintaining the list of local images. The Community’s efforts with respect to the RuntimeService remains challenging and ongoing at the present time.
Based upon the compute-services hybrid use case we shared earlier, you can well appreciate the enthusiasm with which the pursuit of integration with Kubernetes is being both pursued and received within the Singularity Community – let’s face it, it’s not every day that entirely new workflow patterns are enabled for complex use cases that span EPC and services-oriented computing.
Dockerfile Syntax Support
As of the version 3.0 release, not only can Singularity still make use of existing Docker images from the Docker Hub repository, it can reformat them into SIF. Once reformatted into SIF, of course, the reliance upon the source Docker image is removed, and the image can be managed as any other SIF file – as the single means for encapsulating the runtime corresponding to a Singularity container.
Owing to the predominance of Docker in architecting microservices based applications, and the unsurprising and significant investment made by those making use of the technology including repository-hosted images, interoperability with Docker has always been a strength of Singularity. In broadening and deepening that interoperability, support for Docker in Singularity is about to be further enhanced through the addition of direct support for the Dockerfile syntax. Paring down Docker images to a build ‘recipe’ captured through a single text file, Dockerfiles are representative of the most-efficient means for detailing containerized images – Singularity, of course, employs definition files for this purpose. When you review definition files, such as those rapidly appearing in the examples area of the project’s GitHub site, you’ll quickly appreciate just how valuable direct support for the Dockerfile syntax has the potential to be. Furthermore, owing to the not always subtle implementation differences between Docker and Singularity, by working at the build level it is expected that higher degrees of compatibility will be ultimately ensured.
As noted in the section that provided the motivating use case for our roadmap, Nomad is already factoring into some leading-edge use case examples. To reiterate here, Nomad is being used to deploy application workflows in Kubernetes container clusters. From hardened use case pioneers to those wanting to employ Nomad for the first time, it is clear that there is value in integrating the Nomad runtime with Singularity directly; thus, through use of a (Nomad) plugin, Singularity will be enabled as a container runtime under Nomad.
From native runtime interfaces for Singularity in Kubernetes and Nomad, to OCI standards compliance plus direct support for the Dockerfile syntax, there are a number of projects underway at the present time. Owing to the anticipated release of these latest efforts by and for the Singularity Community, in tandem with the potential to rapidly accelerate the implementation of game-changing compute-services hybrid use cases, realization of these roadmap projects will deliver immediately leverageable implementations while addressing important strategic objectives.
Call to Action
As outlined in a recent blog post, SC18 provides numerous opportunities to engage formally or informally with Singularity and its rapidly growing Community – from BoFs and a panel in the Technical Program to presentations, hands-on workshops, and scavenger hunts on the exhibits floor. Because there are certain to be discussions as to current challenges and opportunities within the container ecosystem, in this post we’ve made efforts to ensure you are aware of the progress that has been made in 2018, and what you can expect from all of us over the next few weeks, months, and quarters. As of this writing, Singularity has progressed significantly, and established a vibrant and active Community; however, there is always room for additional Community members and a variety of ways in which contributions can be made. The Singularity Community looks forward to the discussions at SC18 and beyond, as together we can continue to develop this unique approach for containerization into an even better solution for your existing and future use cases in HPC, EPC, and more.