Red Hat is backing CRI-O for an alternative OCI runtime.
While we did pave the way for creating alternatives for Docker in Kubernetes, CoreOS never quite got rkt to 100% stability in Kubernetes. Personally, I love a lot of things about rkt, but the project's ultimate goal was to have standards, regardless of whether or not it was AppC.
If you're still interested in rkt (it's great tech that we still use to this day to run kubelet for all Tectonic clusters), I recommended chatting to the awesome folks at Kinvolk[0]. They maintain rkt alongside CoreOS and support customers using it in production.
Chris from Kinvolk here. As Jimmy mentioned, we've done a good chunk of the work on rkt with CoreOS and are happy to support customers using rkt, and have done so for CoreOS, BlaBlaCar, NASDAQ and others in the past.
But we've chosen not to go the startup route, which means we can only really afford to work on rkt in the context of paid work. We're looking at doing more of this in the future through support contracts for Flatcar Linux[0], a fork of CoreOS' Container Linux, which includes rkt in the images, and through the contracts we get here and there from users looking for new features in, or support for, rkt directly.
But rkt, as is, remains a great container runtime. It's our preferred runtime when running outside of Kubernetes, atm. The Kubernetes integration via rktlet[1] works well but does not have 100% functional parity with the default CRI implementation. It probably needs about 3 person-months of work to get there at this point.
So yeah, it works well, but does indeed need a bit more love. If you're interested in helping out, get in touch.
May I ask why you're pushing cri-o instead of the more mature containerd? All the technical explanations I got were hand-wavy and unconvincing.
The only explanation I see is that containerd is backed by Docker, a competitor of Red Hat, and that business rivalry overrode engineering common sense. Now we have to suffer yet another "war of the container runtimes", as if the original dockerd vs rkt wasn't painful enough.
* work with OCI-standard runtimes (runc, gvisor, runv, kata, clearcontainers, etc) in order to accomplish the above
* integrate well with Linux (use systemd for process management, bias towards tools that already exist in Linux or improve existing tools) to accomplish the above
I don’t think there’s a war. Use what you like. OpenShift specifically supports exact versions of cri-o and Docker 1.13 in order to provide the best Kubernetes experience and ensure clusters always work. There are pros and cons to all container runtimes, but it wasn’t a business decision, it was a technical decision for us.
cri-o is supported for production workloads under OpenShift 3.9 and RHEL 7.5 and we use it on our largest Online clusters. We see better memory use and predictable latency for containers than Docker and containerd for Kubernetes in general.
We don’t want anyone to feel like they can’t use other runtimes, but being Kubernetes-first has always been a goal we didn’t want to compromise on.
Your answer is 99% techno-marketing bullshit, but you still delivered the kernel of a credible explanation: systemd.
It makes perfect sense now. cri-o, being "daemonless", reinforces the central role of systemd in orchestrating system resources, whereas containerd, being a daemon, weakens it. I can see how Red Hat architects would not love the idea, given the importance of systemd in the RHEL/Openshift stack.
There’s no call to be so rude. The RH/CoreOS people here are acting in good faith, I think they’re being exceptionally helpful, and they don’t even need to be answering questions at all.
While we did pave the way for creating alternatives for Docker in Kubernetes, CoreOS never quite got rkt to 100% stability in Kubernetes. Personally, I love a lot of things about rkt, but the project's ultimate goal was to have standards, regardless of whether or not it was AppC.
If you're still interested in rkt (it's great tech that we still use to this day to run kubelet for all Tectonic clusters), I recommended chatting to the awesome folks at Kinvolk[0]. They maintain rkt alongside CoreOS and support customers using it in production.
[0]: https://kinvolk.io