Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-12T09:34:16.547Z
Answers: 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!
Answers: Morishiri
Answers: CC BY-SA 3.0
Answers: 2018-03-09T21:27:38.450Z
Answers: 2018-03-09T21:27:38.450Z
Answers: 2020-06-18T08:28:10.803Z
Answers: mico
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-12T10:07:32.537Z
Answers: Cool it works now!
Answers: mico
Answers: CC BY-SA 3.0
Answers: 2018-03-12T09:39:57.437Z
Answers: 2018-03-12T09:46:40.943Z
Answers: 2018-03-12T09:46:40.943Z
Answers: Morishiri
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-02T23:32:15.130Z
Comments: `Now when I'm trying to install something I'm getting this error`. Please add the command and file you are using.
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-03T07:27:52.940Z
Comments: @030 I updated the question with information you wanted.
Comments: Morishiri
Comments: CC BY-SA 3.0
Comments: 2018-03-03T20:19:12.913Z
Comments: Ok I will have a look. I am setting it up as well.
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-03T21:20:53.197Z
Comments: Did you try [this](https://stackoverflow.com/a/46688254/2777965)?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-03T21:23:45.350Z
Comments: Nope, I was not patching my `tiller-deploy` deployment. I will try that, but unfortunatelly at Monday.
Comments: Morishiri
Comments: CC BY-SA 3.0
Comments: 2018-03-05T07:39:31.447Z
Comments: I tried what you proposed and nothing has changed, still the same issue ;/
Comments: Morishiri
Comments: CC BY-SA 3.0
Comments: 2018-03-09T13:58:31.593Z
Comments: 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>
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-03-09T14:13:54.047Z
Comments: @Tensibai♦ when I set `HELM_HOST` to `10.38.0.1` it tells me that `Error: context deadline exceeded`
Comments: Morishiri
Tags: <kubernetes><helm>
Title: Why does Helm time out on almost every action?
UserDisplayName: Morishiri
ThreadText: # 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=<public-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!  
  
  ---
  
  