<p>You have found a Kubernetes issue <a href="https://github.com/kubernetes/kubernetes/issues/22770" rel="nofollow noreferrer">#22770</a>, where there is a workaround mentioned <a href="https://github.com/kubernetes/helm/issues/1455" rel="nofollow noreferrer">here</a> and it goes like follows:</p>
<blockquote>
<p>What you're experiencing is a known issue with k8s where for some operations it expects to be able to resolve your node names in the global DNS.</p>
<p>And suggested a work around would be to:</p>
<ul>
<li>Add entries to /etc/hosts on the master mapping your hostnames to their public IPs</li>
<li>Install dnsmasq on the master (e.g. apt install -y dnsmasq)</li>
<li>Kill the k8s api server container on master (kubelet will recreate it)</li>
<li>Then systemctl restart docker (or reboot the master) for it to pick up the /etc/resolv.conf changes</li>
</ul>
</blockquote>
<p>As last comment on the issue #22770 there is</p>
<blockquote>
<p>I can confirm that adding the names of the our nodes to /etc/hosts on the kubernetes master resolves this problem for us too :)</p>
</blockquote>
<p>, so there is not a fix in k8s coming in any upcoming version. At least from this particular ticket.</p>

CC BY-SA 3.0
2018-03-12T09:34:16.547Z
Thank you very much! That was not the issue, but you lead me to it. I will provide proper solution in separate answer. Thanks for turining my attention to IPs!
Morishiri
CC BY-SA 3.0
2018-03-09T21:27:38.450Z
2018-03-09T21:27:38.450Z
2020-06-18T08:28:10.803Z
mico
<p>The problem was that nodes, while registered with <code>kubeadm init</code> were providing their private IPs to the cluster master. This caused problems, because master was trying to reach <code>192.0.*.*</code> addresses which were not resolved as nodes from it's point of view.</p>

<p>I needed to edit <code>/etc/systemd/system/kubelet.service.d/10-kubeadm.conf</code> and specify public IP of the node on <code>--node-ip=&lt;public-node-ip&gt;</code> parameter. The reload the service and restart it as mentioned in <a href="https://github.com/kubernetes/kubeadm/issues/203#issuecomment-335416377" rel="nofollow noreferrer">https://github.com/kubernetes/kubeadm/issues/203#issuecomment-335416377</a></p>

<p>Then I registered nodes again and everything was working fine.</p>

CC BY-SA 3.0
2018-03-12T10:07:32.537Z
Cool it works now!
mico
CC BY-SA 3.0
2018-03-12T09:39:57.437Z
2018-03-12T09:46:40.943Z
2018-03-12T09:46:40.943Z
Morishiri
<p>I'm trying to set up <code>helm</code> for the first time and I'm having troubles.</p>

<p>First, I've created account with <code>cluster-admin</code> role. (According to <a href="https://github.com/kubernetes/helm/blob/master/docs/rbac.md#example-service-account-with-cluster-admin-role" rel="noreferrer">https://github.com/kubernetes/helm/blob/master/docs/rbac.md#example-service-account-with-cluster-admin-role</a> ).</p>

<p>After that I've initialized brand new <code>helm</code> tiller by using <code>helm init --service-account=tiller</code> and it was successful.</p>

<p>Now when I'm trying to install something:</p>

<ul>
<li><p>First try:</p>

<pre><code>$ helm repo add gitlab https://charts.gitlab.io
$ helm install --name gitlab-runner -f gitlab-runner-values.yaml gitlab/gitlab-runner
</code></pre>

<p>where <code>gitlab-runner-values.yaml</code> looks like this:</p>

<pre><code>gitlabUrl: https://my-gitlab.domain.com
runnerRegistrationToken: "MY_GITLAB_RUNNER_TOKEN"
concurrent: 10
</code></pre></li>
<li><p>Second try (as I was not sure if there is an issue with custom repo, so I tried from official):</p>

<pre><code>$ helm install stable/kibana
</code></pre></li>
</ul>

<p>I'm getting this error:</p>

<pre><code>Error: forwarding ports: error upgrading connection: error dialing backend: dial tcp 192.168.0.18:10250: getsockopt: connection timed out
</code></pre>

<p>I noticed that <code>192.168.0.18</code> is visble on pod list:</p>

<pre><code>kube-system   kube-proxy-kzflh                        1/1       Running   0          7d        192.168.0.18   kube-worker-7
kube-system   weave-net-jq4n4                         2/2       Running   2          7d        192.168.0.18   kube-worker-7
</code></pre>

<p>and that <code>tiller</code> is running on the same node:</p>

<pre><code>kube-system   tiller-deploy-5b48764ff7-qtv9v          1/1       Running   0          3m        10.38.0.1      kube-worker-7
</code></pre>

<p>I was told that I probably don't have permission to <code>pods/port-forward</code> and <code>list pods</code>, but <code>kubectl auth can-i create pods/portforward</code> tells me that I can do this (the same with <code>list pods</code>) </p>

<p>Also <code>helm list</code> is throwing the same error as <code>install</code>.</p>

CC BY-SA 3.0
2018-03-02T23:32:15.130Z
`Now when I'm trying to install something I'm getting this error`. Please add the command and file you are using.
030
CC BY-SA 3.0
2018-03-03T07:27:52.940Z
@030 I updated the question with information you wanted.
Morishiri
CC BY-SA 3.0
2018-03-03T20:19:12.913Z
Ok I will have a look. I am setting it up as well.
030
CC BY-SA 3.0
2018-03-03T21:20:53.197Z
Did you try [this](https://stackoverflow.com/a/46688254/2777965)?
030
CC BY-SA 3.0
2018-03-03T21:23:45.350Z
Nope, I was not patching my `tiller-deploy` deployment. I will try that, but unfortunatelly at Monday.
Morishiri
CC BY-SA 3.0
2018-03-05T07:39:31.447Z
I tried what you proposed and nothing has changed, still the same issue ;/
Morishiri
CC BY-SA 3.0
2018-03-09T13:58:31.593Z
Notice your tiller pod has IP 10.38.0.1 and not 192.168.0.18. I can't remember exactly but I think you need to do a export HELM_HOST=<proper values here>
Tensibai
CC BY-SA 3.0
2018-03-09T14:13:54.047Z
@Tensibai♦ when I set `HELM_HOST` to `10.38.0.1` it tells me that `Error: context deadline exceeded`
Morishiri
<kubernetes><helm>
Why does Helm time out on almost every action?
Morishiri
# Why does Helm time out on almost every action?

(Asked by: username_0 on 2018-03-02)

I'm trying to set up helm for the first time and I'm having troubles.
First, I've created account with cluster-admin role. (According to https://github.com/kubernetes/helm/blob/master/docs/rbac.md#example-service-account-with-cluster-admin-role ).
After that I've initialized brand new helm tiller by using helm init --service-account=tiller and it was successful.
Now when I'm trying to install something:

First try:
$ helm repo add gitlab https://charts.gitlab.io
$ helm install --name gitlab-runner -f gitlab-runner-values.yaml gitlab/gitlab-runner

where gitlab-runner-values.yaml looks like this:
gitlabUrl: https://my-gitlab.domain.com
runnerRegistrationToken: "MY_GITLAB_RUNNER_TOKEN"
concurrent: 10

Second try (as I was not sure if there is an issue with custom repo, so I tried from official):
$ helm install stable/kibana


I'm getting this error:
Error: forwarding ports: error upgrading connection: error dialing backend: dial tcp 192.168.0.18:10250: getsockopt: connection timed out

I noticed that 192.168.0.18 is visble on pod list:
kube-system   kube-proxy-kzflh                        1/1       Running   0          7d        192.168.0.18   kube-worker-7
kube-system   weave-net-jq4n4                         2/2       Running   2          7d        192.168.0.18   kube-worker-7

and that tiller is running on the same node:
kube-system   tiller-deploy-5b48764ff7-qtv9v          1/1       Running   0          3m        10.38.0.1      kube-worker-7

I was told that I probably don't have permission to pods/port-forward and list pods, but kubectl auth can-i create pods/portforward tells me that I can do this (the same with list pods) 
Also helm list is throwing the same error as install.

**Tags:** kubernetes, helm

> **Comments:**
> **username_1**: `Now when I'm trying to install something I'm getting this error`. Please add the command and file you are using.  
> **username_0**: @username_1 I updated the question with information you wanted.  
> **username_1**: Ok I will have a look. I am setting it up as well.  
> **username_1**: Did you try [this](https://stackoverflow.com/a/46688254/2777965)?  
> **username_0**: Nope, I was not patching my `tiller-deploy` deployment. I will try that, but unfortunatelly at Monday.  
> **username_0**: I tried what you proposed and nothing has changed, still the same issue ;/  
> **username_2**: Notice your tiller pod has IP 10.38.0.1 and not 192.168.0.18. I can't remember exactly but I think you need to do a export HELM_HOST=<proper values here>  
> **username_0**: @username_2♦ when I set `HELM_HOST` to `10.38.0.1` it tells me that `Error: context deadline exceeded`  

---

## 2 answers

### Answer by username_0 on 2018-03-12. Score: 4 | Accepted answer

The problem was that nodes, while registered with `kubeadm init` were providing their private IPs to the cluster master. This caused problems, because master was trying to reach `192.0.*.*` addresses which were not resolved as nodes from it's point of view.

I needed to edit `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and specify public IP of the node on `--node-ip=` parameter. The reload the service and restart it as mentioned in <https://github.com/kubernetes/kubeadm/issues/203#issuecomment-335416377>

Then I registered nodes again and everything was working fine.

> **Comments:**
> **username_3**: Cool it works now!  

---

### Answer by username_3 on 2018-03-09. Score: 3

You have found a Kubernetes issue [#22770](https://github.com/kubernetes/kubernetes/issues/22770), where there is a workaround mentioned [here](https://github.com/kubernetes/helm/issues/1455) and it goes like follows:

> What you're experiencing is a known issue with k8s where for some operations it expects to be able to resolve your node names in the global DNS.
>
> And suggested a work around would be to:
>
> * Add entries to /etc/hosts on the master mapping your hostnames to their public IPs
> * Install dnsmasq on the master (e.g. apt install -y dnsmasq)
> * Kill the k8s api server container on master (kubelet will recreate it)
> * Then systemctl restart docker (or reboot the master) for it to pick up the /etc/resolv.conf changes

As last comment on the issue #22770 there is

> I can confirm that adding the names of the our nodes to /etc/hosts on the kubernetes master resolves this problem for us too :)

, so there is not a fix in k8s coming in any upcoming version. At least from this particular ticket.

> **Comments:**
> **username_0**: Thank you very much! That was not the issue, but you lead me to it. I will provide proper solution in separate answer. Thanks for turining my attention to IPs!  

---

