microk8s: upgrade to 1.14 seems to have broken my access to private registries
I’m under some restrictions about uploading the tarball from microk8s inspect, but
user@orion-a:~$ microk8s.inspect
Inspecting services
Service snap.microk8s.daemon-containerd is running
Service snap.microk8s.daemon-apiserver is running
Service snap.microk8s.daemon-proxy is running
Service snap.microk8s.daemon-kubelet is running
Service snap.microk8s.daemon-scheduler is running
Service snap.microk8s.daemon-controller-manager is running
Service snap.microk8s.daemon-etcd is running
We’ve been using imagePullSecrets successfully on previous version (1.13.3), but the automatic upgrade to 1.14 both surprised me and seems to have broken the ability to pull from our private registry. (registry is using https://github.com/cesanta/docker_auth and registry:2)
this caused all of our microk8s installs to fail around 17 hours ago when the snap was released.
I checked this issue: https://github.com/containerd/cri/issues/848 but we are using the modern syntax (dockerconfigjson) and haven’t been having an issue prior to yesterday
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 22 (4 by maintainers)
I got this to work!
I checked
cri’s source code and saw this:If we trace that further, the hostname comes from the ‘pull image request’. I wasn’t entirely sure what that is but I figured it could very well be the hostname of the image repository, so then I tried editing
/var/snap/microk8s/current/args/containerd-template.tomlwith:Restarted the service, tried deploying
bbox.yamlagain and it worked!Bottom line is it seems we can’t just put any arbitrary text after
plugins.cri.registry.mirrors., it has to match the host of the registry.EDIT: after further investigation, I can confirm that it works like stated above. ParseNormalizedName will convert the image name into a fully qualified one that Docker can use unambiguously. When there’s no host name,
docker.iois preppended to the name, hence the default[plugins.cri.registry.mirrors."docker.io"]. See test. This makes me wonder about https://github.com/containerd/cri/blob/master/docs/registry.md, which seems misleading as there’s no description abouttest.secure-registry.ioandtest.insecure-registry.ioand it leads to think that you can put anything there.I too can’t access my private registry and getting
https://192.168.3.25:5000/v2/my-busybox/manifests/latest: http: server gave HTTP response to HTTPS client.My setup is:
And I’ve got a private registry at port 5000. Note that this registry is not in Kubernetes.
I’ve edited
/etc/docker/daemon.jsonto include"insecure-registries" : ["192.168.3.25:5000"], so I’m able to:My
/var/snap/microk8s/current/args/containerd-template.tomlalso includesBut then when I try to
kubectl apply -f bbox.yamlI get the dreaded
Failed to pull image "192.168.3.25:5000/my-busybox:latest": rpc error: code = Unknown desc = failed to resolve image "192.168.3.25:5000/my-busybox:latest": no available registry endpoint: failed to do request: Head https://192.168.3.25:5000/v2/my-busybox/manifests/latest: http: server gave HTTP response to HTTPS clientAfter investigating for a while and going through https://github.com/containerd/containerd/issues/2758, I tried doing
But then if I try with
--plain-httpit works!So it seems
containerdwithinmicrok8sis not checking the insecure repository mirror entry. Is this a bug or is there anything else I could do?@maltebaumann, thank you for the detailed description.
There are two things that look strange. First you never tell docker you are talking to an insecure registry yet you can push images there (https://docs.docker.com/registry/insecure/). Second I was able to correctly reference the my-busybox image like this
image: localhost:31813/my-busyboxwhile havingin contanerd configuration.
fwiw, to the folks saying “add the configuration the the containerd config”, that’s not how kubernetes works, i need to be able to set the values using secrets
Thanks to your hint I at least managed to get Polyaxon working again: After inspecting polyaxon/registry.py to find out where the
127.0.0.1comes from, I adjusted the corresponding values in the globalpolyaxon-polyaxon-configConfigMap:POLYAXON_REGISTRY_IN_CLUSTER= “false” # To force use of HOST & PORTPOLYAXON_REGISTRY_HOST= “localhost”POLYAXON_REGISTRY_PORT= “31813”I’m now able to run experiments like I did before, but don’t think this is a ‘clean’ solution.