The section on Docker on MacOS is inaccurate

[alionell]

What Happened?

The section on Docker on MacOS is inaccurate with regards to the port number being used by the registry, which is apparently not 5000. It is apparently 32773, which I've not been able to test out yet. But following the instructions given under that section only results in an address in use error and does not perform as said.

Attach the log file

log.txt

Operating System

macOS (Default)

Driver

HyperKit

[afbjorklund]

The minikube registry addon relies on localhost:5000 being recognized by default as an insecure registry (HTTP).

Therefore it also shows you, how you can set up a tunnel for that address. The docker published port will be random.

CONTAINER ID   IMAGE                                                         COMMAND                  CREATED         STATUS          PORTS                                                                                                                                  NAMES
de0019ca9771   gcr.io/k8s-minikube/kicbase-builds:v0.0.36-1668787669-15272   "/usr/local/bin/entr…"   17 hours ago    Up 30 seconds   127.0.0.1:49162->22/tcp, 127.0.0.1:49161->2376/tcp, 127.0.0.1:49160->5000/tcp, 127.0.0.1:49159->8443/tcp, 127.0.0.1:49158->32443/tcp   minikube
d5a3d43f873b   b8604a3fe854                                                  "/entrypoint.sh /etc…"   11 months ago   Up 28 hours     0.0.0.0:5000->5000/tcp, :::5000->5000/tcp                                                                                              registry

Here: 127.0.0.1:49160->5000/tcp is the minikube registry, while 0.0.0.0:5000->5000/tcp is my docker registry

When using a driver with a real VM network, such as HyperKit, you can use the IP address of the VM and NodePort 5000.

But in that case, you will need to configure your local client to use HTTP to talk to it (add it as an insecure registry)

https://minikube.sigs.k8s.io/docs/handbook/registry/#enabling-insecure-registries

https://github.com/kubernetes/kubernetes/blob/6f48d86f0fde19ac71c234fcbb4917b6a1318014/cluster/addons/registry/README.md

https://docs.docker.com/registry/deploying/

https://docs.docker.com/engine/reference/commandline/dockerd/#insecure-registries

---

The registry addon was abandoned 5 years ago, and is looking for someone to take over and document it better...

• Multiarch support for registry addon #10780

Minikube doesn't use a registry by default, and if it did - it would make more sense to run the registry on the host.

• Add possibility to use host docker registry #12087

[alionell]

Thanks for the explanation. I think it makes a little sense now. But honestly anyone who stumbles upon that documentation and find it not working will scratch their head.

[afbjorklund]

It is supposed to be straightforward, from within the cluster (localhost:5000). It can get a bit tricky if you are trying to access it from the outside, but the docker driver has a helper:

Registry addon with {{.driver}} driver uses port {{.port}} please use that instead of default port 5000

So it is supposed to tell you the random port, like that 49160 above. It is also possible to use the minikube image commands, since those run inside the minikube cluster already.

minikube image tag my/image localhost:5000/myimage
minikube image push localhost:5000/myimage

For the other drivers you can use minikube ip, the downside being that you have to configure the local client first.

http: server gave HTTP response to HTTPS client

https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry

---

$ docker inspect --format='{{(index (index .NetworkSettings.Ports "5000/tcp") 0).HostPort}}' minikube
49155
$ docker tag busybox localhost:49155/myimage
$ docker push localhost:49155/myimage
Using default tag: latest
The push refers to repository [localhost:49155/myimage]
b64792c17e4a: Pushed 
latest: digest: sha256:907ca53d7e2947e849b839b1cd258c98fd3916c60f2e6e70c30edbf741ab6754 size: 528

$ minikube ip
192.168.58.2
$ docker tag busybox 192.168.58.2:5000/myimage
$ docker push 192.168.58.2:5000/myimage
Using default tag: latest
The push refers to repository [192.168.58.2:5000/myimage]
Get "https://192.168.58.2:5000/v2/": http: server gave HTTP response to HTTPS client

[afbjorklund]

It seems like the documentation is somewhat outdated.

At least with regards to the minikube "registry" addon:

https://minikube.sigs.k8s.io/docs/handbook/registry/

The registry runs on 80/443, the proxy runs on 5000.

---

$ kubectl describe svc -n kube-system registry

Port:              http  80/TCP
TargetPort:        5000/TCP
Port:              https  443/TCP
TargetPort:        443/TCP

$ kubectl describe ds -n kube-system registry-proxy

    Port:       80/TCP
    Host Port:  5000/TCP

In the cluster, the cluster IP range is added to the "insecure registries" by default:

kubectl get svc -n kube-system
NAME       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP   40h
registry   ClusterIP   10.108.246.190   <none>        80/TCP,443/TCP           16m

docker info
...
 Insecure Registries:
  10.96.0.0/12
  127.0.0.0/8
...

docker@minikube:~$ docker tag busybox 10.108.246.190/myimage
docker@minikube:~$ docker push 10.108.246.190/myimage
Using default tag: latest
The push refers to repository [10.108.246.190/myimage]
b64792c17e4a: Pushed 
latest: digest: sha256:907ca53d7e2947e849b839b1cd258c98fd3916c60f2e6e70c30edbf741ab6754 size: 528

So in there it is possible to use registry.kube-system.svc.cluster.local instead.

[medyagh]

alionell do you linking to the exact page ?

if you are refering to https://minikube.sigs.k8s.io/docs/handbook/pushing/#4-pushing-to-an-in-cluster-using-registry-addon
I think our documenation could use a Tabbed View for Docker Desktop that shows different Port for Docker desktop

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[afbjorklund]

/remove-lifecycle rotten

[sigma-andex]

It seems like the documentation is somewhat outdated.

At least with regards to the minikube "registry" addon:

https://minikube.sigs.k8s.io/docs/handbook/registry/

The registry runs on 80/443, the proxy runs on 5000.

$ kubectl describe svc -n kube-system registry

Port:              http  80/TCP
TargetPort:        5000/TCP
Port:              https  443/TCP
TargetPort:        443/TCP

$ kubectl describe ds -n kube-system registry-proxy

    Port:       80/TCP
    Host Port:  5000/TCP

In the cluster, the cluster IP range is added to the "insecure registries" by default:

kubectl get svc -n kube-system
NAME       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP   40h
registry   ClusterIP   10.108.246.190   <none>        80/TCP,443/TCP           16m

docker info
...
 Insecure Registries:
  10.96.0.0/12
  127.0.0.0/8
...

docker@minikube:~$ docker tag busybox 10.108.246.190/myimage
docker@minikube:~$ docker push 10.108.246.190/myimage
Using default tag: latest
The push refers to repository [10.108.246.190/myimage]
b64792c17e4a: Pushed 
latest: digest: sha256:907ca53d7e2947e849b839b1cd258c98fd3916c60f2e6e70c30edbf741ab6754 size: 528

So in there it is possible to use registry.kube-system.svc.cluster.local instead.

@afbjorklund could you explain that a bit more? I have a knative service, how would I refer to that image? registry.kube-system.svc.cluster.local/myname/myimage:mytag ?
Is it still necessary to do
docker run --rm -it --network=host alpine ash -c "apk add socat && socat TCP-LISTEN:5000,reuseaddr,fork TCP:$(minikube ip):5000" as described in the docs? I tried to get this running now for a couple of hours but all this information is really confusing.
Thanks!

[afbjorklund]

It is confusing. There is a registry running in the cluster, but in order to not have to deploy a certificate for running it with https or setup the local "insecure registries" settings there is a proxy deployed on localhost:5000 to use HTTP instead...

The original documentation (which since has been deprecated and removed) explains it a little bit better: https://github.com/kubernetes/kubernetes/blob/6f48d86f0fde19ac71c234fcbb4917b6a1318014/cluster/addons/registry/README.md

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.