Preventing Kubernetes from pulling the pause image from the internet

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.

Just to save someone 5 minutes of research, if you are using the EKS AMIs based on AL2023 or Bottlerocket, this is already done for you by pointing to an image on ECR. At least on Bottlerocket, I haven't checked AL2023, the image is baked into the AMI so you don't even need to pull it from ECR.

I went down this rabbit hole not so long ago too.

There was a discussion open on containerd's GitHub on removing the dependency on the pause image but it has been closed as won't fix: https://github.com/containerd/containerd/issues/10505

Also, if you are using kubeadm to create your cluster, beware that kubeadm may be pre-pulling a different pause image if it does not match your containerd configuration: https://github.com/kubernetes/kubeadm/issues/2020

O/T, but I'm getting a cert error on this page - wonder if it's just me or if this site is just serving a weird cert. Looks like it's signed by some Fortinet appliance - maybe I'm getting MITMed? Would be kind of exciting/frightening if so.

EDIT: I loaded the page from a cloud box, and wow, I'm getting MITMed! Seems to only be for this site, wonder if it's some kind of sensitivity to the .family TLD.

I've used k8s before a lot and at several companies. I am convinced that 99.9% of the people who use it should not be. But it's more fun than deploying VM images at least.

I believe this has been patched time and time again in on-premises variants like OpenShift. Curious to check if it’s there in small variants like microk8s, k3s, etc., as I’m considering moving a few offline services to Talos.

Nice to know, though I wonder how many companies are really using all private images? I've certainly had a client running their own Harbor instance, but almost all others pulled from Docker Hub or Github (ghcr.io).

Yeah that pause image was really annoying when I was hosting a k8s cluster on Hetzner, since the `registry.k8s.io` -registry was blocking some Hetzner IPs, since its hosted on Google.

This is insane, am I the only one being shocked to learn about this? This reeks of bad engineering, is there at least a plan to make this go away by embedding "pause" with the distribution?

Easy. Dont use kubernetes. You'll thank me later.

I went down this rabbit hole not so long ago too.

There was a discussion open on containerd's GitHub on removing the dependency on the pause image but it has been closed as won't fix: https://github.com/containerd/containerd/issues/10505

Yeah that pause image was really annoying when I was hosting a k8s cluster on Hetzner, since the `registry.k8s.io` -registry was blocking some Hetzner IPs, since its hosted on Google.

This is insane, am I the only one being shocked to learn about this? This reeks of bad engineering, is there at least a plan to make this go away by embedding "pause" with the distribution?

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.

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.

It's implementation of cri plugin.

> This should be part of the containerd distribution

containerd is not the only CRI runtime out there.

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.

We removed the image registry dependency on AL2023 as well. :)

https://github.com/awslabs/amazon-eks-ami/pull/2000

Thank you, was just about to task my team with figuring out how affected we are by this.

EDIT: I loaded the page from a cloud box, and wow, I'm getting MITMed! Seems to only be for this site, wonder if it's some kind of sensitivity to the .family TLD.

Ooft. If it helps, this is the PEM I'm getting. LetEncrypt signed.

I've used k8s before a lot and at several companies. I am convinced that 99.9% of the people who use it should not be. But it's more fun than deploying VM images at least.

I'm running k3s at home on single node with local storage. Few blogs, forum, minIO.

Very easy, reliable.

Without k3s I would have use Docker, but k3s really adds important features: easier to manage network, more declarative configuration, bundled Traefik...

So, I'm convinced that quite a few people can happily and efficiently use k8s.

In the past I used other k8s distro (Harvester) which was much more complicated to use and fragile to maintain.

I use k3s for my home and for dev envs I think it's completely fine especially when it comes to deployment documentation.

I am way more comfortable managing a system that is k3s rather than something that is still using tmux that gets wiped every reboot.

Well... it's what I would have said until bitnami pulled the rug and pretty much ruined the entire ecosystem as now you don't have a way to pull something that you know is trusted with similar configuration and all from a single repository which makes deployments a pain in the ass.

However, on the plus side I've just been creating my own every time I need one with the help of claude using bitnami as reference and honestly it doesn't take that much more time and keeping them up to date is relatively easy as well with ci automations.

Same here, I went through a few projects since 2021 where doing Kubernetes setups were part of my role on the consulting project, and I would say prefer managed containers solutions, e.g. Azure Web Apps, or when running locally plain systemd or Docker Compose.

Anything else, most companies aren't Web scale enough to set their full Kubernetes clusters with failover regions from scratch.

What makes you come to that conclusion?

Talos' KubeSpan is backed by Sidero-hosted disovery service that cannot be self-hosted without a commercial license

Lots of medical and governmental organisations are not allowed to run in public cloud environments. It's part of my job to help them get set up. However, in reality that often boils down to devs wining about adding a registry to Harbor to cache; nobody is going to recompile base images and read through millions of lines of third party code.

A lot of security is posturing and posing to legally cover your ass by following an almost arbitrary set of regulations. In practice, most end up running the same code as the rest of us anyway. People need to get stuff done.

Pretty much all enterprises are using their own ECR/GCR/ACR.

I work on the container registry team at my current company running a custom container registry service!

The Public Sector and anyone concerned with compliance under the Cyber Resilience Act should really use their own private image store. Some do, some don't.

I think once your eng org > 300 people and you have a dedicated infra and security team, it's going to be on their radar to do at some point.

Some people run Artifactory as a cache in front of Docker Hub etc, which allows some governance

We removed the image registry dependency on AL2023 as well. :)

https://github.com/awslabs/amazon-eks-ami/pull/2000

Ooft. If it helps, this is the PEM I'm getting. LetEncrypt signed.

Thank you, was just about to task my team with figuring out how affected we are by this.

It's implementation of cri plugin.

> This should be part of the containerd distribution

containerd is not the only CRI runtime out there.

> 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.

The nomad team made this configurable afterwards.

That nomad was hit with this after years of notice and deprecation extension, seems a sign of serious maintenance issues

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.

I use k3s for my home and for dev envs I think it's completely fine especially when it comes to deployment documentation.

I am way more comfortable managing a system that is k3s rather than something that is still using tmux that gets wiped every reboot.

The situation with bitnami is getting fixed, but it takes time for all the holes to be plugged.

I knew bitnami were trouble when I saw their paid tier prices. Relevant article: https://devoriales.com/post/402/from-free-to-fee-how-broadco...

Oh, and it's owned by Broadcom.

> I am way more comfortable managing a system that is k3s rather than something that is still using tmux that gets wiped every reboot.

Thoughts on Tmux-resurrect[1] , it can even resurrect programs running inside of it as well. It feels like it can as such reduce complexity from something like k3s back to tmux. What are your thoughts on it?

[1]:https://github.com/tmux-plugins/tmux-resurrect?tab=readme-ov...

I'm running k3s at home on single node with local storage. Few blogs, forum, minIO.

Very easy, reliable.

Without k3s I would have use Docker, but k3s really adds important features: easier to manage network, more declarative configuration, bundled Traefik...

So, I'm convinced that quite a few people can happily and efficiently use k8s.

In the past I used other k8s distro (Harvester) which was much more complicated to use and fragile to maintain.

Check out Talos Linux if you haven't already, it's pretty cool (if you want k8s).

> 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.

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.

That nomad was hit with this after years of notice and deprecation extension, seems a sign of serious maintenance issues

The situation with bitnami is getting fixed, but it takes time for all the holes to be plugged.

I knew bitnami were trouble when I saw their paid tier prices. Relevant article: https://devoriales.com/post/402/from-free-to-fee-how-broadco...

Oh, and it's owned by Broadcom.

Pretty much all enterprises are using their own ECR/GCR/ACR.

I think once your eng org > 300 people and you have a dedicated infra and security team, it's going to be on their radar to do at some point.

The Public Sector and anyone concerned with compliance under the Cyber Resilience Act should really use their own private image store. Some do, some don't.

Some people run Artifactory as a cache in front of Docker Hub etc, which allows some governance

> I am way more comfortable managing a system that is k3s rather than something that is still using tmux that gets wiped every reboot.

[1]:https://github.com/tmux-plugins/tmux-resurrect?tab=readme-ov...

I had it break enough times to where I just don't bother.

Check out Talos Linux if you haven't already, it's pretty cool (if you want k8s).

I tried Talos few month ago. Found it unstable and complicated; reported few bugs.

And because they are "immutable" - I found it's significantly more complicated to use with no tangible benefits. I do not want to learn and deal declarative machine configs, learn how to create custom images with GPU drivers...

Quite a few things which I get done on Ubuntu / Debian under 60 seconds - takes me half an hour to figure out with Talos.

How do you manage node settings k8s does not yet handle with Talos?

Anything else, most companies aren't Web scale enough to set their full Kubernetes clusters with failover regions from scratch.

I like Docker(compose) + Portainer for small deployments

What makes you come to that conclusion?

They’ve never worked on a real soa/multi-team/microservices project with more than 20 separate deployments before and assumes no one else does.

Talos' KubeSpan is backed by Sidero-hosted disovery service that cannot be self-hosted without a commercial license

Hmmm. So I need to find something equivalent as a base OS. Maybe it's time to do Fedora Core.

I work on the container registry team at my current company running a custom container registry service!

I like Docker(compose) + Portainer for small deployments

They’ve never worked on a real soa/multi-team/microservices project with more than 20 separate deployments before and assumes no one else does.

20? That's still on the small end.

Hmmm. So I need to find something equivalent as a base OS. Maybe it's time to do Fedora Core.

How does this require a whole team? Unless you're working at a hyperscaler

I had it break enough times to where I just don't bother.

Well firstly I would love to know more about your workflow where it actually broke etc. because I feel like tmux-ressurect team could help or something for sure.

I haven't used the tool itself so I am curious as I was thinking of a similar workflow as well sometime ago

Now please answer the above questions but also I am going to assume that you are right about tmux-ressurect, even then there are other ways of doing the same thing as well.

https://www.baeldung.com/linux/process-save-restore

This mentions either Criu if you want a process to persist after a shutdown, or the shutdown utility's flags if you want to temporarily do it.

I have played around with Criu and docker, docker can even use criu with things like docker checkpoint and I have played with that as well (I used it to shutdown mid compression of a large file and recontinue compression exactly from where I left)

What are your thoughts on using criu+docker/criu + termux, I think that it itself might be an easier thing than k3s for your workflow.

Plus, I have seen some people mention vps where they are running the processes for 300 days or even more without a single shutdown iirc and I feel like modern VPS providers are insanely good at uptime, even more so than sometimes cloud providers.

Skill issue. It works just fine

How do you manage node settings k8s does not yet handle with Talos?

Talos has it's own API that you interact with primarily through the talosctl command line. You apply a declarative machineconfig.yaml with which custom settings can be set per-node if you wish.

I tried Talos few month ago. Found it unstable and complicated; reported few bugs.

Quite a few things which I get done on Ubuntu / Debian under 60 seconds - takes me half an hour to figure out with Talos.

Learning new things takes time.

It sounds like an immutable kubernetes distro doesn't solve any problems for you.

Skill issue. It works just fine

Talos has it's own API that you interact with primarily through the talosctl command line. You apply a declarative machineconfig.yaml with which custom settings can be set per-node if you wish.

Learning new things takes time.

It sounds like an immutable kubernetes distro doesn't solve any problems for you.

20? That's still on the small end.

How does this require a whole team? Unless you're working at a hyperscaler

Not a hyperscaler, but we’re multi-cloud and probably one to two steps down.

My team’s service implements a number of performance and functionality improvements on top of your typical registry to support the company’s needs.

I can’t say much more than that sadly.

Please describe their system for us, including system throughput, the hardware they're on, networking constraints, and how many people are allowed to be needed to operate it.

Maybe they work for docker

Well firstly I would love to know more about your workflow where it actually broke etc. because I feel like tmux-ressurect team could help or something for sure.

I haven't used the tool itself so I am curious as I was thinking of a similar workflow as well sometime ago

Now please answer the above questions but also I am going to assume that you are right about tmux-ressurect, even then there are other ways of doing the same thing as well.

https://www.baeldung.com/linux/process-save-restore

This mentions either Criu if you want a process to persist after a shutdown, or the shutdown utility's flags if you want to temporarily do it.

What are your thoughts on using criu+docker/criu + termux, I think that it itself might be an easier thing than k3s for your workflow.

failure scales exponentially with servers due to design limitations

even using tmux resurrect on my personal machine I've had it fail to resurrect anything

again - lack of documentation and loosy tmux resurrect state is not what I want to go thru when working in unfamilar environments

why are you getting downvoted

docker compose also has issues but at least it is defined, again if you are managing 10+ machines docker becomes a challenge to maintain especially when you have 4 to 5 clusters, when you are familiar with kubernetes there's virtually no difference between docker tmux or raw k8s, although I heavily recommend k3s due to its ability to maintain itself.

Please describe their system for us, including system throughput, the hardware they're on, networking constraints, and how many people are allowed to be needed to operate it.

Not a hyperscaler, but we’re multi-cloud and probably one to two steps down.

My team’s service implements a number of performance and functionality improvements on top of your typical registry to support the company’s needs.

I can’t say much more than that sadly.

failure scales exponentially with servers due to design limitations

even using tmux resurrect on my personal machine I've had it fail to resurrect anything

again - lack of documentation and loosy tmux resurrect state is not what I want to go thru when working in unfamilar environments

why are you getting downvoted

Maybe they work for docker

Publish Date: November 3, 2025

I don’t normally write blog posts that regurgitate information from normal documentation, but this particular subject irks me.

If you are running an internal Kubernetes (k8s) platform, you owe it to yourself to make sure there is nothing external to your platform determining your reliability.

You could ask yourself: How many internet dependencies do you have to start a pod? Should be zero, right???

If you use stock k8s, you might be surprised to know that each of your k8s nodes is actually reaching out to registry.k8s.io on first pod creation to get the pause image:

$ sudo crictl images
IMAGE                                     TAG                 IMAGE ID            SIZE
registry.k8s.io/pause                     3.9                 e6f1816883972

If you want to change that, you can update your containerd (1.x) toml:

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "YOUR_REGISTRY/pause:3.10"

And depend on one less thing. The rest of the blog post will go deeper into why this is the case.

What Is The Pause Image Anyway?

The pause image is the container image that backs the k8s “sandbox” of a pod. This pause container is designed to hold the linux namespaces. The pause container used to also reap zombie processes from the other containers in a pod, its duty as PID1, but that isn’t the case by default anymore in k8s 1.8+.

The sandbox of a pod is part of the CRI spec. The CRI spec is a generic way for k8s to talk pods (and sandboxes) that is not specific to any particular container runtime (like containerd). Any container runtime that implements the CRI spec can, in theory, run k8s pods.

This means that the pause image has more to do with CRI than it does with k8s.

Where The Pause Image Comes From (CRI)

When a CRI-enabled container runtime needs to create a sandbox, at least with the case of containerd, it does this by creating a real container.

The image containerd is configured to use (by default) to create that sandbox, is the pause image. You can see this in code here.

How To Point Containerd To Your Local Pause Image

Per the current docs, you can overwrite the containerd sandbox image with a containerd configuration like this (assuming you have mirrored to a local registry):

(containerd 1.x)

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "YOUR_REGISTRY/pause:3.10"

(containerd 2.x)

version = 3

[plugins]
  [plugins.'io.containerd.cri.v1.images']
    ...
    [plugins.'io.containerd.cri.v1.images'.pinned_images]
      sandbox = 'YOUR_REGISTRY/pause:3.10'

Don’t take my word for it here, this particular setting has changed over time, check the official docs.

Conclusion

If you go to registry.k8s.io you will see:

Please note that there is NO uptime SLA as this is a free, volunteer managed service. We will however do our best to respond to issues and the system is designed to be reliable and low-maintenance. If you need higher uptime guarantees please consider mirroring images to a location you control.

So yea, this is your PSA. Please mirror like they recommend and reconfigure as needed to not depend on the internet.

Comment via email

Hacker Times