virtualbox: Image pull failing with TLS handshake timeout error #3704
Comments
|
Is it possible that you have a proxy, vpn, or firewall that might be interfering with access? Since you mention that it's intermittent, it could just be a bad internet connection that kubeadm isn't able to deal with for some reason. Curious. |
|
Thanks for your reply @tstromberg! No VPN or Proxy in the network, just a regular NAT connection from VirtualBox to access the network of my localhost. Also, when I say intermitent, it means that happens at random time, but once it happens, just a machine restart solves the problem, while Thanks! |
And now I simply cannot start Minikube at all, since the |
|
I'll have to think about this a bit, but two possible workarounds:
Overall this feels like Virtualbox just can't get out to the internet in a stable fashion, so there probably isn't any minikube options that are going to help here. What version of virtualbox are you running? |
|
Thanks, @tstromberg ! For now, I've migrated from Minikube to Kubernates support on DockerDesktop, which uses Hyperkit underneath (which, btw, is working well), but I'll also give a try on Thanks! |
|
Same issue here on OS X: Logs are pretty much the same as @mauricioklein. Also, Issue is when trying to pull images from minikube: I am running this while in work office, behind a proxy so will run again when home to test on different connection. |
|
@mrowebot - For what it's worth, your issue does seem different, and likely indicates that the proxy isn't configured inside of the VM: https://github.com/kubernetes/minikube/blob/master/docs/http_proxy.md |
tstromberg
changed the title
|
Fixed by running the following: The issue seems to have been that even though I had env vars set for |
tstromberg
added
kind/bug
|
Same issue occurred and I re-tried after deleting ~.minikube folder and the error is no longer there. Environment: |
|
I think it's also worth while to upgrade to minikube v1.0.0 |
|
I believe this issue was resolved in the v1.1.0 release. Please try upgrading to the latest release of minikube, and if the same issue occurs, please re-open this bug. Thank you opening this bug report, and for your patience! If you run into TLS handshake problems, be sure to check out: https://github.com/kubernetes/minikube/blob/master/docs/http_proxy.md |
|
Thanks @tstromberg! |
|
I'm afraid this issue still exists. I'm having exactly the same issue as @mauricioklein reported with v1.1.0. Only restart the host can fix the issue but after a while it happens again. if I virtualbox: Oracle VM VirtualBox VM Selector v6.0.8 other info |
|
An update. After using hyperkit instead of virtualbox seems having no issue so far. Try this if anyone having the same issue. https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperkit-driver |
Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT
Environment:
Minikube version:
0.34.0MacOS Mojave 10.14.3virtualboxminikube-v0.33.1.isoWhat happened:
Minikube is failing to download Docker images frequently. The error is always the same: "TLS handshake timeout" (see image attached). It happens in both
minikube startand when rolling out a deployment usingkubectl apply -f.Accessing Minikube terminal (
minikube ssh) and trying to reach a random webpage (e.g.curl google.com), it never returns, which indicates that maybe the VM lost connection with the internet, but everything works on the physical machine.Apparently, the only way to solve the problem and bring Minikube back is:
VM memory was increased from 2GB to 4GB, but problem persists.
What you expected to happen:
Docker images are downloaded normally during both Minikube startup and rollouts
How to reproduce it:
This is an intermittent error, so no deterministic way to reproduce. However, it normally happens on Minikube startup (
minikube start) and deployment rollouts (kubectl apply -f .).Output of
minikube logs(if applicable):Anything else do we need to know:
Follow a screenshot of the error (
TLS handshake timeout) during a Minukube startup:The text was updated successfully, but these errors were encountered: