What are your plans for rkt? It’s great alternative in a docker-dominated ecosystem and much more solid architecture but haven’t seen much progress lately. Doesn’t seem to be getting a lot of love
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
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.
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.
Can you share your perspective on this?
* 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.
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.