This message was deleted.
# rancher-desktop
a
This message was deleted.
m
what did you meen with "privat registry"? If you do a docker build and tag the image you should be able to see the image with "docker image ls", after this you can create a pod with this image but make sure that the imagePullPolicy is set to "IfNotPresent" otherwise K3S will try to pull the image from dockerhub.
t
I can definitely see the image when doing
nerdctl images
. I'll try the pullPolicy
Just changed the policy, now I have this:
Failed to pull image "haproxy-agent-service-checker:latest": rpc error: code = Unknown desc = failed to pull and unpack image "<http://docker.io/library/haproxy-agent-service-checker:latest|docker.io/library/haproxy-agent-service-checker:latest>": failed to resolve reference "<http://docker.io/library/haproxy-agent-service-checker:latest|docker.io/library/haproxy-agent-service-checker:latest>": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
And the complementary event:
Back-off pulling image "haproxy-agent-service-checker:latest"
I don't get why k3s tries to pull from docker instead of local registry
Copy code
# nerdctl images
REPOSITORY                       TAG       IMAGE ID        CREATED         PLATFORM       SIZE         BLOB SIZE
haproxy-agent-service-checker    latest    164609860dc6    4 hours ago     linux/amd64    107.1 MiB    39.3 MiB
t
specifically
nerdctl --namespace <http://k8s.io|k8s.io> build --tag nginx-helloworld:latest .
t
Can't I build onto default registry and let K3s to pick in it?
Or is it bound to k8s.io ?
t
🤷 I don’t know K3 well enough TBH But it’s one way or the other (either push it where k8s knows, or change where k8s is looking)
f
@tall-insurance-55443 is correct: you need to build the image in the
<http://k8s.io|k8s.io>
namespace for kubernetes to "see" it. Note that these are containerd namespaces, not kubernetes namespaces, which may contribute to the confusion
t
Indeed it confuses. Can't we allow K3s to see default containerd namespace ?
f
No, this is the way k8s and containerd work; I'm not sure this is configurable, but even if it were, I would strongly recommend against it.
t
That's fine, I'll stick with k8s.io namespace
f
Note that this namespace is "owned" by kubernetes, so if you would create a container in it, kubelet would just kill it as soon as it notices. For that reason
nerdctl -n <http://k8s.io|k8s.io> build ...
does not actually build in the target namespace, but copies/links the image over, so kubelet can see it.
t
Gotcha
Hmmm, for some reasons I still have the same issues pulling the image from k8s.io internal registry:
f
Oh, this is because you are using the
latest
tag. It implies
imagePullPolicy: Always
, so kubelet will check if there is a newer version of the image on the registry. You need to either specify
imagePullPolicy: Never
in your Pod spec, or use any tag other than
latest
.
t
You got it!
Thank you Jan
👍 1
640 Views