Dear Lord, please stop people from enforcing standards and bypassing them themselves.

Take kubernetes for example. Since v1.24 CRI has been announced as the standard, and kubernetes is shifting to live by it.

But it's not.

Yes, it's got the CRI spec defined and the unix://cri.sock used for that standardised communication. What nobody's telling you, is that that socket MUST be on the same runtime as the kube. I.e. you can't simply spin up a dockerd/containerd/cri-o server and share its CRI socket via CIFS/NFS/etc. Because kube-cp will assume that contained is running on the same host as cp and will try to access its services via localhost.

So effectively you feed the container via a socket to another machine, it spins up the container and that container tries to
- bind to your local machine's IP (not the one's the container is running on)
- access its dependencies via localhost:port, while they are actually running on your local machine (not the CRI host)

I HOPE this will change some day. And we'll have a clear cut between dependencies and dependents, separated by a single communications channel - a single unix socket. That'd be a solution I'd really enjoy working with. NOT the ip-port-connect-bind spaghetti we have now.

  • 3
    All this feels oddly like vsphere and VMware in the late 2000s....

    Did we go too far with container management?
  • 2
    @sariel Yes. I heard someone say Kubernetes was the new VMWare yesterday and I wanted to eat my router.
  • 3

    Atleast you had some salt on it before you ate it?
  • 1
    @ComputerToucher time to punch some people in the throats.

    Containers were developed in the first place because VMs suck and are slow as fuck to deploy.
Add Comment