A local registry lets you use the same image URLs in all clusters, in-container (Kaniko builds, Knative tag-to-digest resolver etc.) as well as on nodes (dockerd image pull). Local registry with temporary storage eliminates a security concern and bandwidth cost of playing around with Knative. Local registry with S3/GCS persistence lets multiple clusters share images. If desired, any one of them can be your production registry, exposed with your choice of security to outside the cluster.
The question is: How do we chose the hostname for our image URLs? Running registry in Kubernetes is trivial, but:
- We can't use a real SSL certificate issuer.
- Docker on k8s nodes typically fails to resolve cluster DNS names.
Knative doesn't (yet?) abstract out the registry host from Source-to-URL workflows, so we need the same user-facing FQDNs to work both with Knative and nodes' Docker.
In this example setup we've chosen knative.registry.svc.cluster.local
as the registry host.
Using .local
we by docker conventions avoid SSL,
and we communicate the scope of the configuration.
You must chose how to make a registry DNS name resolvable to nodes. There are basically three options:
- Docker daemons somehow resolve Kubernetes services
*.svc.cluster.local
. - You add the chosen registry FQDN to
/etc/hosts
on all nodes, including those provisioned in future. - A local DNS points
knative.registry.svc.cluster.local
to theclusterIP
of the service.
Apply the templates folder.
There's also a script ./minikube-start.sh
that sets up a Knative-compatible Minikube with local registry.
If docker pull fails, which is likely (you can use our test jobs to check), you need to fix name resolution. There's a suggestion in the sysadmin folder.
Note that this setup uses transient registry storage. See Registry docs for options on how to make it persistent, and modify config and/or volume(s) accordingly.
It's worth pointing out that S3/GCS persistence is particularily useful for local registry,
as any other cluster or registry setup that can access the same bucket is automatically a mirror.
Furthermore it makes horizontal scaling as easy as kubectl scale
on the registry replicaset.
Beware that this setup grants anyone access. See the Registry docs for how to enable authentication.
To keep using Knative locally without a service account
but provide outside access with authentication,
start a separate Registry deployment backed by the same bucket
or expose a proxy.
The nginx:alpine
image can use htpasswd
files created by registry.
We would love your feedback on this project so don't hesitate to let us know what is wrong and how we could improve it, just file an issue
This work is by no means part of CNCF but we abide by its code of conduct