<p>I am trying to deploy a private docker registry on Kubernetes using the official Docker image for the registry. However, I am getting some warnings on the deployment and also I am not able to access it in the pod.</p>

<p>The output from the registry container:</p>

<pre><code>time="2019-04-12T18:40:21Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_PORT" 
time="2019-04-12T18:40:21Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_PORT_5000_TCP"  
time="2019-04-12T18:40:21Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_PORT_5000_TCP_ADDR" 
time="2019-04-12T18:40:21Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_PORT_5000_TCP_PORT" 
time="2019-04-12T18:40:21Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_PORT_5000_TCP_PROTO" 
time="2019-04-12T18:40:21Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_SERVICE_HOST" 
time="2019-04-12T18:40:21Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_SERVICE_PORT" 
time="2019-04-12T18:40:21.145278902Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable." go.version=go1.11.2 instance.id=988660e4-d4b9-4d21-a42e-c60c82d00a73 service=registry version=v2.7.1 
time="2019-04-12T18:40:21.145343563Z" level=info msg="redis not configured" go.version=go1.11.2 instance.id=988660e4-d4b9-4d21-a42e-c60c82d00a73 service=registry version=v2.7.1 
time="2019-04-12T18:40:21.149771291Z" level=info msg="Starting upload purge in 2m0s" go.version=go1.11.2 instance.id=988660e4-d4b9-4d21-a42e-c60c82d00a73 service=registry version=v2.7.1 
time="2019-04-12T18:40:21.163063574Z" level=info msg="using inmemory blob descriptor cache" go.version=go1.11.2 instance.id=988660e4-d4b9-4d21-a42e-c60c82d00a73 service=registry version=v2.7.1 
time="2019-04-12T18:40:21.163689856Z" level=info msg="listening on [::]:5000" go.version=go1.11.2 instance.id=988660e4-d4b9-4d21-a42e-c60c82d00a73 service=registry version=v2.7.1 
</code></pre>

<p>The yaml files for the deployment on Kubernetes:</p>

<pre><code>104 apiVersion: extensions/v1beta1
105 kind: Deployment
106 metadata:
107   name: registry
108   namespace: docker
109 spec:
110   replicas: 1
111   template:
112     metadata:
113       labels:
114         name: registry
115     spec:
116       containers:
117       - resources:
118         name: registry
119         image: registry:2
120         ports:
121         - containerPort: 5000
122         volumeMounts:
123         - mountPath: /var/lib/registry
124           name: images
140       volumes:
141       - name: images
142         hostPath:
143           path: /mnt/nfs/docker-local-registry/images
150       nodeSelector:
151         name: master
152 ---
153 apiVersion: v1
154 kind: Service
155 metadata:
156   name: registry
157   namespace: docker
158 spec:
159   ports:
160   - port: 5000
161     targetPort: 5000
162   selector:
163     name: registry
</code></pre>

<p>Even if I ignore those warnings, accessing the registry in pod level with <code>registry.docker:5000/image_name</code> and <code>registry.docker.svc.cluster.local/image_name</code> won't work because the host cannot be resolved. I don't want the registry exposed. All that I want is to be able pods to pull the images from there.</p>

thzois
<p>Not sure, I understand your use case completely, but if you want to start a pod that is based on an image served from the internal registry, it is important to understand that not the pod but the dockerd on the cluster node is pulling the image. The internal DNS names like *svc.cluster.local cannot be resolved there. At least in many K8s environments this is the case. 
Some people were discussing this here: <a href="https://github.com/knative/serving/issues/1996" rel="nofollow noreferrer">https://github.com/knative/serving/issues/1996</a>
It might help, if you post which Kubernetes provider (GKE, EKS etc.) you are using.
The solution is to configure the cluster nodes to resolve these names, or to expose your registry externally using an ingress.</p>
