'Unable to connect to the server: net/http: TLS handshake timeout

On minikube for windows I created a deployment on the kubernetes cluster, then I tried to scale it by changing replicas from 1 to 2, and after that kubectl hangs and my disk usage is 100%. I only have one container in my deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: first-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      run: app
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: demo
        image: ner_app
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 5000

all I did was run this after the pods were successfully deployed and running

kubectl scale --replicas=2 deployment first-deployment

In another terminal I was watching the pods using

kubectl get pods --watch

But everything is unresponsive and I'm not sure how to recover from this.

When I run kubectl get pods again it gives the following message

PS D:\docker\ner> kubectl get pods
Unable to connect to the server: net/http: TLS handshake timeout

Is there a way to recover, or cancel whatever process is running?

Also my VM's are on Hyper-V for Windows 10 Pro (minikube and Docker Desktop) both have the default RAM allocated - 2048MB

The container in my pod is a machine learning process and the model it loads could be large, in the order of 200MB to 300MB

kubernetesminikube


Solution 1:[1]

You may have some proxy problems. Try following commands:

$ unset http_proxy
$ unset https_proxy

and repeat your kubectl call.

Solution 2:[2]

You can set up resource limits on deployments so that pods will not use the entire available resource in the node.

Solution 3:[3]

In my case I have my private EKS cluster and there is no 443(HTTPS) enabled in security groups.

My issue is solved after enabling the (HTTPS)443 port in security groups.

Kindly refer for AWS documentation for more details: "You must ensure that your Amazon EKS control plane security group contains rules to allow ingress traffic on port 443 from your connected network"

Solution 4:[4]

For me, the problem is that Docker ran out of memory. (EDIT: Possibly anyway; I wrote this post a while ago, and am now not so sure that is the root case, but did not write down my rationale, so idk.)

Anyway, to fix:

  1. Fully close your k8s emulator. (docker desktop, minikube, etc.)
  2. Shutdown WSL2. (wsl --shutdown) [EDIT: This step is apparently not necessary -- at least not always, since this time I skipped it, and the problem still resolved.]
  3. Restart your k8s emulator.
  4. Rerun the commands you wanted.

Sometimes it also works to simply:

  1. Right click the Docker Desktop tray-icon, press "Restart Docker", and wait a few minutes for things to restart. (sometimes this fails, with Docker Desktop saying "Docker failed to start", so I'd generally recommend the more thorough process above)

Solution 5:[5]

i solved this problem when execute the following command

minikube delete

and then start it

minikube start --vm-driver="virtualbox"

if use this why your pods will deleted

and when run kubectl get pods

you can see this result No resources found in default namespace.

Solution 6:[6]

You could try $ unset all_proxy to reset the socket proxy.

Also, if you're connected to a VPN, try disconnecting - it seems that can interfere with connecting to a cluster.

Solution 7:[7]

I think the other answers don't really mention or refer to the vpn and proxy documentation for minikube: https://minikube.sigs.k8s.io/docs/handbook/vpn_and_proxy/

The NO_PROXY variable here is important: Without setting it, minikube may not be able to access resources within the VM. minikube uses two IP ranges, which should not go through the proxy:

192.168.99.0/24: Used by the minikube VM. Configurable for some hypervisors via --host-only-cidr
192.168.39.0/24: Used by the minikube kvm2 driver.
192.168.49.0/24: Used by the minikube docker driver’s first cluster.
10.96.0.0/12: Used by service cluster IP’s. Configurable via --service-cluster-ip-rang

So adding those IP ranges to your NO_PROXY environment variable should fix the issue.

Solution 8:[8]

Just happened to me on a new Windows 10 install with Ubuntu distro in WSL2. I solved the problem by running:

$ sudo ifconfig eth0 mtu 1350

(BTW, I was on a VPN connection when trying the 'kubectl get pods' command)

Solution 9:[9]

Simply closing cmd, opening again, then

minikube start

And then executing the commands again solved this issue for me. P.S: minikube start took less than a minute

Solution 10:[10]

Adding the IP address to the no_proxy list worked for me.

Obtain the IP address from ip addr output.

export no_proxy=localhost,127.0.0.1,<IP_ADDRESS>

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Daniel Perník
Solution 2 rphv
Solution 3 7hills
Solution 4
Solution 5
Solution 6
Solution 7
Solution 8 Dror Harari
Solution 9 Raman Mishra
Solution 10 Arun

Related Questions