That’s correct. That’s what is happening when you run docker pull <my-ip>:<port>/kube-scheduler-amd64:v1.10.11
When you do docker pull k8s.gcr.io/kube-scheduler-amd64:v1.10.11 your machine will go out to k8s.gcr.io to download the image. This does not go to your Nexus Repository Manager.
The image name is just “kube-scheduler-amd64”. The part before the “/” in your docker pull command tells your machine where to download the image.
In the NPM and MVN case, you have done some configuration (.npmrc or settings.xml) that tells those tools to always go to Nexus. So, what needs to happen is that during your Docker for Windows and Kubernetes installs for your ‘offline’ machines, you need to have it go to <my-ip>:<port>. I am still trying to understand some of this myself. The documentation and Google results are all over the place, but from what I can tell, the “Registry Mirrors” configuration in Docker for Windows does not strictly redirect all traffic to the mirror. Even if the Registry Mirrors setting worked as we expect, it is clearly defined as a mirror of Docker Hub only. I doubt that would redirect the k8s.gcr.io image request to the mirror.
Due to the simple install and everything packaged together, Docker for Windows/Mac was appealing to me for my local development and testing. However, given your use case of packing the software for offline environment, it may be worth exploring one of the other solutions listed on the kubernetes site: https://kubernetes.io/docs/setup/pick-right-solution/