why do i need to pull images over and over again? #6360
-
|
I need to load the same images over and over again. Is there a way to say k3s to “persist” the images, so that I don’t have to pull them again? When I run I tried to set What I’m doing wrong? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 6 replies
-
|
Images are pruned when you get low on disk space on the image filesystem. Raising the GC thresholds isn't a great idea, you'll probably just run out of space and have a completely different set of problems. The best way to resolve this is just to use a larger disk on your node. Also, that's not the right syntax for a yaml file. You'd want something like: kubelet-arg:
- image-gc-high-threshold=99
- image-gc-low-threshold=98If pulling images is slow, you may want to look into setting up a local registry mirror, where you can have more control over which images are cached and for how long. |
Beta Was this translation helpful? Give feedback.
-
|
You need to use |
Beta Was this translation helpful? Give feedback.
-
I'm wondering what rate of disk on the node is used by k3s for images. I'm currently trying to install an image of about 650M on a worker node. The disk usage on this node looks like this: Deploying the image fails and results in DiskPressure, so the svclb-traefik pod is evicted. How can I tell k3s to add from free space on the disk to the image file system? |
Beta Was this translation helpful? Give feedback.
-
|
You have a 3.8gb root partition, that's tiny. Did you mean to make it so small? |
Beta Was this translation helpful? Give feedback.
-
|
It's a heterogeneous cluster with a variety of embedded platforms. This is a Xilinx board running aarch64 and petalinux. I just started with the sd card from the factory setup of the platform. Maybe I should expand the disk size, but I don't think that was the problem. I saw that the image wasn't code compatible with the platform. It's a problem that can be caused by docker's buildx on the build host or containerd on the worker node. buildx didn't report any problems, even the base image is not available for the aarch64 architecture. On the k3s cluster, the image crashed and restarted several times, throwing a diskpressure event. But it was actually a consequent error. |
Beta Was this translation helpful? Give feedback.
-
|
ok. I'm not sure what the image arch has to do with it getting cleaned up under disk pressure but it sounds like you have it figured out? |
Beta Was this translation helpful? Give feedback.
-
|
For testing purposes, I tainted all but one of the worker nodes. After the pod crashes, it keeps restarting. This results in multiple instances of the pod on the node in different states, which triggers the DiskPressure event. The question for me is why doesn't containerd recognize that the container is not available for the architecture and pull the container and try to start it. But this is an off-topic question here, I think. Thank you for your valuable assistance. |
Beta Was this translation helpful? Give feedback.
Images are pruned when you get low on disk space on the image filesystem. Raising the GC thresholds isn't a great idea, you'll probably just run out of space and have a completely different set of problems. The best way to resolve this is just to use a larger disk on your node.
Also, that's not the right syntax for a yaml file. You'd want something like:
If pulling images is slow, you may want to look into setting up a local registry mirror, where you can have more control over which images are cached and for how long.