You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The guides at https://k3d.io/v5.6.0/usage/registries/#using-k3d-managed-registries to "Create a dedicated registry together with your cluster" and to "Create a customized k3d-managed registry" use different naming, the first one mycluster-registry, the second one myregistry.localhost. Tests later on use the second format with names ending in localhost. This leads to ImagePullBackoff/ErrImagePull errors when trying to test the dedicated registry with the nginx deployment with mycluster-registry.localhost.
Note that the instructions mention "k3d sets everything up in the cluster for containerd to be able to pull images from that registry (using the registries.yaml file)", which is not helpful at all. Should I create registries.yaml? What contents? How to use it?
Also, the test comes with this assumption: "In the following test cases, we assume that the registry name k3d-registry.localhost resolves to 127.0.0.1 in your local machine (see section preface for more details) and to the registry container IP for the k3d cluster nodes (K3s containers)."
In my case, mycluster-registry and mycluster-registry.localhost both resolve to 127.0.0.1 in my local machine. How do I ensure or verify this for the k3d cluster nodes? In particular, I expected this to work out of the box when creating a "dedicated registry". Maybe add some pointer for instructions to verify this?
The fix is to use image: mycluster-registry:12345/nginx:latest in the deployment (without .localhost).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The guides at https://k3d.io/v5.6.0/usage/registries/#using-k3d-managed-registries to "Create a dedicated registry together with your cluster" and to "Create a customized k3d-managed registry" use different naming, the first one
mycluster-registry
, the second onemyregistry.localhost
. Tests later on use the second format with names ending inlocalhost
. This leads toImagePullBackoff
/ErrImagePull
errors when trying to test the dedicated registry with the nginx deployment withmycluster-registry.localhost
.It was not obvious to me that I must leave out
.localhost
in the test for the dedicated registry. Maybe add "(where you replacek3d-registry.localhost
withmycluster-registry
)" after "3. Test your registry" under https://k3d.io/v5.6.0/usage/registries/#create-a-dedicated-registry-together-with-your-cluster.More specifically, I tried this:
The above works. The following as well (with appropriate port instead of 12345;
.localhost
can be left out):However, that deployment test fails to pull the image with
ImagePullBackoff
/ErrImagePull
:Note that the instructions mention "k3d sets everything up in the cluster for containerd to be able to pull images from that registry (using the registries.yaml file)", which is not helpful at all. Should I create registries.yaml? What contents? How to use it?
Also, the test comes with this assumption: "In the following test cases, we assume that the registry name k3d-registry.localhost resolves to 127.0.0.1 in your local machine (see section preface for more details) and to the registry container IP for the k3d cluster nodes (K3s containers)."
In my case, mycluster-registry and mycluster-registry.localhost both resolve to 127.0.0.1 in my local machine. How do I ensure or verify this for the k3d cluster nodes? In particular, I expected this to work out of the box when creating a "dedicated registry". Maybe add some pointer for instructions to verify this?
The fix is to use
image: mycluster-registry:12345/nginx:latest
in the deployment (without.localhost
).Besides, under https://k3d.io/v5.6.0/usage/registries/#create-a-customized-k3d-managed-registry the part "could be used with automatic resolution of *.localhost, see next section" would benefit from a hyperlink into the appropriate section. That is probably a previous section, isn't it?
Beta Was this translation helpful? Give feedback.
All reactions