[Guide] Local registry in Kubernetes on ARM

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.
Docker Architecture

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