Skip to content
Permalink
main
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

cri-o/ADOPTERS.md

Go to file
 
 
Cannot retrieve contributors at this time
24 lines (22 sloc) 2.77 KB
Raw Blame
Open in GitHub Desktop

CRI-O Adopters

Below is a non-exhaustive list of CRI-O adopters in production environments:

  • Red Hat's Openshift Container Platform uses CRI-O as the only supported CRI implementation starting with the release of OpenShift 4. CRI-O was chosen because it provides a lean, stable, simple and complete container runtime that moves in lock-step with Kubernetes, while also simplifying the support and configuration of clusters.
  • Oracle Linux Cloud Native Environment has used CRI-O since release due to its tight focus on the Kubernetes CRI and its ability to manage both the runc and Kata Containers runtime engines.
  • SUSE CaaS Platform uses CRI-O since version 3. It has been initially supported as technology preview in version 3 and moved to the default Kubernetes container runtime since version 4 as a replacement for Docker.
  • openSUSE Kubic is a Certified Kubernetes distribution based on openSUSE MicroOS. It uses CRI-O as a supported container runtime for Kubernetes.
  • Digital Science is using CRI-O as the runtime in data processing clusters behind Dimensions due to it being just enough runtime for Kubernetes, and the flexibility to use more than runc.
  • HERE Technologies uses CRI-O as the runtime for our home grown Kubernetes clusters. We like that it is purpose built for Kubernetes and has a strong community backing it.
  • Particule uses CRI-O as part of our bare metal solution Symplegma to deploy Kubernetes with Ansible. We aim to be as vanilla and up to date with community standards as possible.
  • Nestybox distributes CRI-O together with the Sysbox container runtime, to enable running secure "VM-like" pods on Kubernetes clusters (voiding the need for privileged pods in many scenarios). CRI-O was chosen as it's the only container manager that supports creating pods that are strongly isolated using the Linux user-namespace (as of Jan 2022).
  • Lyft has used CRI-O since 2017, alongside our CNI IPvlan networking in AWS. All of Lyft runs on top of our Kubernetes stack.
  • Reddit has been using CRI-O as the runtime for all self-managed Kubernetes clusters since 2021. CRI-O was chosen for its clean and easy to reason about codebase, its good observability, and its ability to allow for transparently rewriting image registries for mirroring.