The defaultRegistry flag solves the problem if images, for example, in the deployment, are specified as image: user123/super-app:v1.0.0. Then the value from defaultRegistry will substitute the necessary repository (possibly a private one).
I encountered an issue in a communal Kubernetes cluster when applications were deployed from Helm charts (actually, it depends on how) and the manifests specified images with a "full" path, for example, quay.io/user123/super-app:v1.0.0, and then I received an error in k8s-iae that the repository was inaccessible (because the perimeter is closed).
I solved this problem with the image-mirrors flag.
As an example:
Thus, I achieve dynamic replacement of the original repository with a mirror.
Of course, it would be possible to give container permissions to map the configuration file (Docker JSON or registries.conf for CRI-O) and parse it, but this, in my opinion, would be overhead.
nabokihms
commented
5 months ago
The
defaultRegistryflag solves the problem if images, for example, in thedeployment, are specified asimage: user123/super-app:v1.0.0. Then the value fromdefaultRegistrywill substitute the necessary repository (possibly a private one). I encountered an issue in a communal Kubernetes cluster when applications were deployed from Helm charts (actually, it depends on how) and the manifests specified images with a "full" path, for example,quay.io/user123/super-app:v1.0.0, and then I received an error ink8s-iaethat the repository was inaccessible (because the perimeter is closed). I solved this problem with theimage-mirrorsflag. As an example:Thus, I achieve dynamic replacement of the original repository with a mirror. Of course, it would be possible to give container permissions to map the configuration file (Docker JSON or registries.conf for CRI-O) and parse it, but this, in my opinion, would be overhead.