kubectl: в соединении с сервером XXX.XXX.XXXXXX было отказано

Я пытаюсь подключиться к мастеру (кластеру) кубернетов в Google Cloud Engine.

Ошибка, которую я всегда получаю, когда kubectl попытаться получить доступ к мастеру кубернетов:

В соединении с сервером XXX.XXX.XXX.XXX было отказано - вы указали правильный хост или порт?

Например:

$ 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?

Насколько я понимаю, клиент использует ту же версию, что и сервер (версия 1.5.2). Но по какой-то странной причине он отказывается подключаться.

$ 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

В главном кластере kubernetes (серверная версия) я получаю следующую ошибку:

# 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?

Я выполняю следующие шаги для создания мастера кластера 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

Я получаю и отлично устанавливаю учетные данные:

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

Описание хорошее:

gcloud container clusters describe $APP_NAME

Конфигурация Google тоже:

gcloud config list

Контекст также кажется законным в:

kubectl config get-contexts

Даже я могу использовать ssh для главного кластера kubernetes, но только SSH, без HTTP или HTTPS или, например, правильно запустить kubectl.

Я тоже читал в Документы Kubernetes:

Google Container Engine использует туннели SSH для защиты каналов связи Master -> Cluster. В этой конфигурации apiserver инициирует SSH-туннель к каждому узлу в кластере (подключается к ssh-серверу, прослушивающему порт 22) и передает весь трафик, предназначенный для кублета, узла, модуля или службы, через туннель. Этот туннель гарантирует, что трафик не будет открыт за пределами частной сети GCE, в которой работает кластер.

Поэтому я не знаю, как открыть порт 8000 в мастере Kubernetes Cluster, чтобы разрешить соединение (и открытие всех портов в брандмауэре в Google Cloud Engine тоже не работает).

У меня нет идей, и я в основном ищу все записи, связанные с Google. Поэтому я не знаю, как решить, чтобы подключиться к серверу, или что я делаю не так в процессе. Любая помощь очень ценится!

РЕДАКТИРОВАТЬ:

После проверки »Уведомления об устаревании реестра контейнеров"местоположение контейнера было обновлено до eu.gcr.io вместо b.gcr.io в соответствии с:

28 февраля 2017 г. использование реестров «принеси свою корзину», таких как b.gcr.io и bucket.gcr.io, считается устаревшим. После этой даты Реестр контейнеров больше не будет обслуживать образы контейнеров, которые были у вас в этих корзинах.

Но проблема все еще сохраняется.

Разрешая свой собственный ответ. Похоже, что настоящая проблема заключалась в доступе и подключении к account.google.com через DNS. После проверки наличия пинга:

$ 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

И отслеживаем все открытые файлы во время команды:

$ 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 +++

Пытаюсь разобраться в открытых соединениях:

$ 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

Я просто обнаружил, что у меня есть openvpn с включенным tun0 (блокирование подключения к accounts.google.com), после того, как я запустил отключение интерфейса:

sudo ifconfig tun0 down

У меня отлично получается:

$ 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

Таким образом, проблема заключалась в отказе в подключении. Это может быть полезно # 41975 в проекте кубернетес для отладки с -v = 4, например:

$ 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?