There are several reasons for running a local registry for your Docker images on your cluster. The Internet access might be limited or non-existing at times, or maybe you just want to try it out. Kubernetes schedules pods on your cluster, which requires images to be available at all times so that all nodes can access all images if needed. This guide will show you how to set up a local registry with Luxas' Kubernetes on ARM.
The figure below shows the role of the registry, and that Docker Hub can be replaced with other registries. More details can be found at Docker's own site.
Enabling the registry
If you don't already have a cluster up and running, you can follow one of our other guides. When Kubernetes on ARM is up and running, it is as simple as running the following command on your master:
kube-config enable-addon registry
This creates, among other things, a service with the name
registry in the namespace
kube-system exposing port 5000. If you already have the DNS addon running it is fairly simple to find the service in the cluster. If you don't have it running then I suggest you run:
kube-config enable-addon dns.
Combining the namespace, service name and port number results in the following:
registry.kube-system:5000 which works as a prefix instead of implicitly choosing Docker Hub. The DNS will resolve
registry.kube-system to the endpoint of the service behind the scenes.
Pushing and pulling
Enough with the theory, let's try it out. If you have built an image on a node, then you need to tag it before you can push it to the registry. The following example tags an image called
username/greeter with a prefix that corresponds the registry's service endpoint. The
username illustrates that it corresponds to your Docker Hub user. Afterwards the image is pushed to the local registry.
$ docker tag username/greeter:latest registry.kube-system:5000/username/greeter:latest $ docker push registry.kube-system:5000/username/greeter:latest The push refers to a repository [registry.kube-system:5000/username/greeter] 1ed3d60213f5: Pushed 5f70bf18a086: Pushed 9d3a922efd6f: Pushed bbd9b8251f5f: Pushed b2d9159cb296: Pushed 7a3f611b0ebd: Pushed latest: digest: sha256:88af3e5e9836060c2c71628422cbfbb54975a882f33994e3d54791943efb0046 size: 2994
The example above explicitly states that the tag is
latest in both cases, but if you don't provide a tag Docker assumes
latest. You will probably notice the limitation of your Raspberry Pis's performance while pushing.
From another node (or the same) within the cluster, you can now pull the image by running.
$ docker pull registry.kube-system:5000/username/greeter:latest latest: Pulling from username/greeter 234876e69431: Pull complete 5a98a2f1f5d9: Pull complete e84549343770: Pull complete a3ed95caeb02: Pull complete f09aa00a3317: Pull complete 665a508175f6: Pull complete Digest: sha256:88af3e5e9836060c2c71628422cbfbb54975a882f33994e3d54791943efb0046 Status: Downloaded newer image for registry.kube-system:5000/username/greeter:latest