To be fair, the "branch standard" solution for the container runtime behind Kubernetes these days (and definitely looking to the future) is not Docker. It's CRI-O (of which podman can work concurrently with) or Containerd. Most of the main k8s distributions have already migrated to a CRI native container runtime and as Docker-shim is going to be removed from k8s in a future release, going with the right implementation now may save dev work in the future.
True, In was mostly describing the "pick one to go with and stick with it till it's done" issue, than trying to explain the relationship between docker/others and orchestrators.
Under the hood SCALE is using k3s, which uses Docker with Containerd under the hood. The k3s project will potentially migrate away from Docker one day in line with other distributions
(*), and
already supports any CRI implementation today.
Thats interesting insight, thank you! :)
Personally, I can't wait for people to longer think or associate Docker with Kubernetes in anything but a historical sense.
Guess it's a bit like the clusterfuck with swarm and swarm-mode, folks tend to have something in-their-mind and it's hard to change that thought patern.
Doesn't help the homelabbers much of course as that community often feels k8s is too much for their needs (personally I disagree k3s is almost perfect for that group!)
I'm currently spending quite some weeks learning to move from swarm-mode to k8s. The learning curve is higher imho, but I don't think it's "too much for my needs" as you don't have to use everything within k8s if you don't want to. A simple "take this docker, connect ports and attatch storage"-container is perfectly possible. Both things like healthchecks are a LOT more solid imho.
but I wonder how much $ Ix makes from the non-enterprise customer base anyway.
The thing is: most things they write for their enterprise customers are useable by their non-enterprise customers too.
The margins on the non-enterprise hardware are nice and while I agree that the revenue won't even be comparable to the enterprise customers, it's basically: Free extra revenue, Free extra testers, Free extra PR, Free source to look for new employees etc. All of which are have a significant value ;-)
Not that this should all matter much, as if someone is using SCALE as intended then they'll be using the helm based plugins and shouldn't care too much about the underlying container runtime. If someone is wanting to do significant manual CLI work/manual deployments then one could assume this may eventually cause issues and they'd be better off running it in a VM or elsewhere.
Precisely.
Also,
@ikke, you can always install Podman manually and give it a go (it used to conflict with Docker but I've just checked and that seems to be resolved). I can understand why they wouldn't bundle it in given if they include it they'd have to support it for their Enterprise customers so the less moving parts you ship the easier that support becomes.
A VM might be cleaner though.... plain deb10 or something like it...
(* As a senior employee of SUSE, who recently announced their acquisition of Rancher/k3s this should not be taken as indicative of any product roadmap announcement but a comment on a general trend in the k8s upstream community)
Posts with disclaimers are the best posts
