Re:Roadmap for CoreOS Integration with Red Hat OpenShift
by zapita on Wednesday May 09, 2018 @08:06PM
(#17035414)
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.
Thanks for enlightening me, if only accidentally.
Re:Roadmap for CoreOS Integration with Red Hat OpenShift
by davidmr on Wednesday May 09, 2018 @10:00PM
(#17035898)
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.
* be exactly what Kubernetes needs and no more
* 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.