4 ms·
The long-term goal is to switch users to use podman (and buildah I guess), with cri-o being a daemon that uses the same underlying code. The only reason a daemo
by cyphar 7y ago
The long-term goal is to switch users to use podman (and buildah I guess), with cri-o being a daemon that uses the same underlying code. The only reason a daemon is required in the first place is because the CRI uses gRPC.
This is loosely similar to how rkt operated, with rktnetes just being a front-end for rkt (though at the time, the CRI didn't exist so it was all hardcoded in Kubernetes).
The goal isn't to have a differently-named daemon required in order to do any operation, and podman enables that (though again, so did rkt).
- windexh8er 7y agoThanks for your insight! I guess I don't understand why having multiple runtimes helps. If CRI is just an agnostic interface to the tooling what is the advantage of cri-o over containerd? Why make the ecosystem harder when it's all a standard runtime interface anyway? Couldn't Docker tooling, podman and buildah all talk directly to any runtime?