It bugs me that this implementation detail of containerd has leaked to such an extent. This should be part of the containerd distribution, and should not be pulled at runtime.

Instead of just swapping out the registry, try baking it into your machine image.

▲

chupasaurus a day ago | parent | next [-]

It's implementation of cri plugin.

> This should be part of the containerd distribution

containerd is not the only CRI runtime out there.

	▲	cmckn 19 hours ago \| parent [-]
		> It's implementation of cri plugin. Right, that’s the point. A user of the CRI should not have to care about this implementation detail. > containerd is not the only CRI runtime out there. Any CRI that needs a pause executable should come with one.

▲

kawsper a day ago | parent | prev | next [-]

Relying on an hosted image also caused some disruptions for Nomad (the scheduler from Hashicorp), because the default pause image was hosted at gcr.io which google killed, and it moved to registry.k8s.io.

The nomad team made this configurable afterwards.

	▲	verdverm 21 hours ago \| parent [-]
		That nomad was hit with this after years of notice and deprecation extension, seems a sign of serious maintenance issues

▲

spwa4 a day ago | parent | prev [-]

More general one would wish that Kubernetes had a few extra ways to get images, so you could grow on a scale from "minimal infrastructure" to "fully CI/CD". Starting with just sending the image in the RPC itself or even just on local disk (you figure out how to get it there), all the way up to registries with tightly controlled versioning.

	▲	p_l a day ago \| parent [-]
		It's possible to do that, as kubernetes only passes the image information to CRI. You can also setup a separate service to "push" images directly to your container runtime, someone even demoed one in Show HN post some time ago I think.