4

Working on getting development environment setup in Minikube and ran across an issue pulling images from the https://quay.io/v2/ registry.

I have ran the command:
eval $(minikube docker-env) .

Which allows me to build my local Dockerfile in Minikube and it does a great job with that and deployments work great with local images.

I then used helm to install helm install stable/mssql-linux .

Which worked fine and its image points to this microsoft/mssql-server-linux:2017-CU3 HERE

I am also working with redis-ha and installed like so:
helm install stable/redis-ha --set="rbac.create=false"

The rbac.create=false seems to allow it to install in Minikube without causing all sorts of issues. However, despite creating deployments and services...the deployments ultimately fail because it cant pull the image.

I get the following error: Failed to pull image "quay.io/smile/redis:4.0.8r0": rpc error: code = Unknown desc = Error response from daemon: Get https://quay.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

The deployments point to this registry image: quay.io/smile/redis:4.0.8r0

I have changed my DNS pretty much everywhere I could to point to 8.8.8.8 as it seems like it cant resolve the URL. It could also just be that I need to add the registry someplace? I kind of feel that its registry specific since Minikube docker daemon appears to be able to pull from docker hub but not quay.io.

If I use a terminal that is not running eval $(minikube docker-env) and use the docker daemon on my host computer I can pull the quay.io/smile/redis:4.0.8r0 image just fine...ssh into minikube and try and it cant pull.

Minikube version minikube version: v0.25.0

Docker for Mac Version 17.12.0-ce-mac55 (23011)

afreeland
  • 3,889
  • 3
  • 31
  • 42

2 Answers2

1

as it seems like it cant resolve the URL

What lead you to believe that, when the error clearly states that it has a Client.Timeout exceeded while awaiting headers? It resolved the registry to an IP address, and even apparently opened a network connection to what it thinks is the registry's IP and port. But after that, the networking stack in minikube did not, in fact, allow the traffic out. Observe that the error wasn't DNS, and it wasn't connection refused, it was connection timed out. That is almost always a firewall-esque behavior.

That smells very, very much like a corporate HTTP proxy, since your machine can interact with the Internet but minikube cannot.

There are a ton of troubleshooting steps one could go through, however, if you are interested in a very quick win, you can, from your working host computer, run docker save quay.io/smile/redis:4.0.8r0 | ssh-into-minikube "docker load" and treat minikube as if it were airgapped.

mdaniel
  • 31,240
  • 5
  • 55
  • 58
  • Thanks for your opinion, I ended up running `rm -rf ~/.minikube` and reinstalled and now I am pulling images. – afreeland Mar 22 '18 at 13:25
0

I dont know what the underlying reason was...perhaps Minikube just being fragile but ended up:

Removing minikube rm -rf ~/.minikube

Running start again minikube start --vm-driver=hyperkit

Reran init helm init

Now everything is pulling as it should....

afreeland
  • 3,889
  • 3
  • 31
  • 42