kubectl: A conexão com o servidor XXX.XXX.XXXXXX foi recusada

Question

Estou tentando conectar-me ao mestre do Kubernetes (cluster) no Google Cloud Engine.

O erro que sempre recebo quando o kubectl tenta acessar o mestre do kubernetes é:

The connection to the server XXX.XXX.XXX.XXX was refused - did you specify the right host or port?

Por exemplo:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server XXX.XXX.XXX.XXX was refused - did you specify the right host or port?

Até agora eu verifiquei o cliente está usando a mesma versão que o servidor (versão 1.5.2). Mas, por alguma razão estranha, está se recusando a se conectar.

$ gcloud beta container get-server-config
Fetching server config for europe-west1-c
defaultClusterVersion: 1.5.2
defaultImageType: GCI
validImageTypes:
- CONTAINER_VM
- GCI
validMasterVersions:
- 1.5.2
- 1.4.8
validNodeVersions:
- 1.5.2
- 1.5.1
- 1.4.8
- 1.4.7
- 1.4.6
- 1.3.10
- 1.2.7

No cluster mestre do kubernetes (versão do servidor), recebo o seguinte erro:

# kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Eu sigo estas etapas para a criação do mestre do cluster do kubernetes:

export APP_NAME=brand-project
export GOOGLE_CONTAINER_NAME=b.gcr.io/brand/project
gcloud container clusters create $APP_NAME --zone europe-west1-c --machine-type g1-small --num-nodes 1

Eu recebo e defino perfeitamente as credenciais:

gcloud config set container/cluster $APP_NAME
gcloud container clusters get-credentials $APP_NAME
gcloud auth application-default login

A descrição é boa:

gcloud container clusters describe $APP_NAME

O google config também:

gcloud config list

O contexto também parece legítimo em:

kubectl config get-contexts

Mesmo eu posso ssh para o cluster mestre do kubernetes, mas apenas SSH, HTTP ou HTTPS ou, por exemplo, executar corretamente o kubectl.

Eu também leio em documentos do Kubernetes :

Google Container Engine uses SSH tunnels to protect the Master -> Cluster communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. This tunnel ensures that the traffic is not exposed outside of the private GCE network in which the cluster is running.

Portanto, não sei como abrir a porta 8000 no masturador do Kubernetes Cluster para permitir a conexão (e abrir todas as portas no firewall no Google Cloud Engine parece não funcionar também).

Estou sem ideias e pesquiso principalmente todas as entradas relacionadas ao google. Então eu não tenho idéia de como resolver se conectar com o servidor ou o que estou fazendo de errado no processo. Qualquer ajuda é muito apreciada!

EDITAR:

Depois de verificar " Avisos de desaprovação do Registro de contêiner ", o local do contêiner foi atualizado para a UE .gcr.io em vez de b.gcr.io de acordo com:

On February 28th, 2017, the use of “bring your own bucket” registries such as b.gcr.io and bucket.gcr.io is considered deprecated. After that date, Container Registry will no longer serve any container images that you had in those buckets.

Mas o problema ainda persiste.

    

Answer 1

Resolvendo minha própria resposta. Parece que o problema real foi o acesso e a conexão a accounts.google.com via DNS. Depois de verificar que tenho ping:

$ ping accounts.google.com
PING accounts.google.com (216.58.201.141) 56(84) bytes of data.
64 bytes from mad06s25-in-f13.1e100.net (216.58.201.141): icmp_seq=1 ttl=56 time=21.9 ms
64 bytes from mad06s25-in-f13.1e100.net (216.58.201.141): icmp_seq=2 ttl=56 time=19.0 ms
64 bytes from mad06s25-in-f13.1e100.net (216.58.201.141): icmp_seq=3 ttl=56 time=20.4 ms
^C
--- accounts.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 19.070/20.468/21.914/1.173 ms

E stracing todos os arquivos abertos durante o comando:

$ strace -eopenat kubectl version
openat(AT_FDCWD, "/proc/sys/net/core/somaxconn", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/stat", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/sys/kernel/hostname", O_RDONLY|O_CLOEXEC) = 3
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
openat(AT_FDCWD, "/home/shakaran/.kube/config", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/home/shakaran/.config/gcloud/application_default_credentials.json", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/sys/kernel/hostname", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
The connection to the server 104.155.120.114 was refused - did you specify the right host or port?
+++ exited with 1 +++

Eu tento descobrir as conexões abertas:

$ systemd-resolve --status | cat
Global
         DNS Servers: 127.0.1.1
                      8.8.8.8
                      8.8.4.4
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 10 (vboxnet3)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 9 (vboxnet2)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 8 (vboxnet1)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 7 (vboxnet0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 6 (docker0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 5 (tun0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 3 (wlan0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
         DNS Servers: 8.8.8.8
                      8.8.4.4

Link 2 (eth0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Acabei de descobrir que tenho o openvpn com tun0 habilitado (bloqueando a conexão para accounts.google.com), depois de executar a desabilitação da interface:

sudo ifconfig tun0 down

Eu fico perfeitamente:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:52:34Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
So sorry for all the noise. But probably it is a good idea add this in FAQ's or so for warning the users about VPNs

Então, o problema foi principalmente uma conexão recusada. Pode ser útil o problema # 41975 no projeto kubernetes para depurar com o -v = 4 como :

$ kubectl version -v=4
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
I0224 11:32:36.914299   30751 helpers.go:221] Connection error: Get https://XXX.XXX.XXX.XXX/api: Post https://accounts.google.com/o/oauth2/token: dial tcp: lookup accounts.google.com on 127.0.1.1:53: read udp 127.0.0.1:46403->127.0.1.1:53: read: connection refused
F0224 11:32:36.914378   30751 helpers.go:116] The connection to the server XXX.XXX.XXX.XXX was refused - did you specify the right host or port?