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

Question

Я пытался запустить базовый кластер Kubernetes в соответствии со следующим учебником https://kubernetes.io/docs/setup/independent/install-kubeadm/

Я начал с современной системы Ubuntu 16.04 и установил Docker.

wget -qO- https://get.docker.com/ | sed 's/docker-ce/docker-ce=18.06.3~ce~3-0~ubuntu/' | sh

После этого я установил модули kubelet / Kubeadm и kubectl

apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

Убедился, что своп и т. Д. Отключен sudo swapoff -a

Выполнил инициализацию с помощью sudo kubeadm init

[init] Using Kubernetes version: v1.13.3
...
To start using your cluster
...
mkdir ...
You can now join any ...
...

Я создаю папку .kube и конфигурацию

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubectl cluster-info, затем показывает

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server 10.117.xxx.xxx:6443 was refused - did you specify the right host or port?

После нескольких попыток я один разполучил:

sudo kubectl cluster-info
Kubernetes master is running at https://10.117.xxx.xxx:6443
KubeDNS is running at https://10.117.xxx.xxx:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Но через секунду его обратно к разрешению отказано

sudo kubectl cluster-info
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server 10.117.xxx.xxx:6443 was refused - did you specify the right host or port?

Я пытался с и без sudo ... и sudo kubectl get nodes также отказался работать.

The connection to the server 10.117.xxx.xxx:6443 was refused - did you specify the right host or port?

Чего мне не хватает, чтобы он не подключался?

ping 10.117.xxx.xxx работает нормально, и даже ssh по этому адресу работает и является тем же сервером.

Редактировать

sudo systemctl restart kubelet.service показывает, что кластер подключен к сети, но по какой-то причине отключается через несколько минут.

kubectl cluster-info
Kubernetes master is running at https://10.117.0.47:6443
KubeDNS is running at https://10.117.0.47:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
...
kubectl cluster-info

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server 10.117.0.47:6443 was refused - did you specify the right host or port?

edit2

После полного сброса и использования следующей инициализации ...

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 

Затем следует

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml

Позволил мне установить сетевой модуль pod, но был недолгим.

clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created

kubectl cluster-info
Kubernetes master is running at https://10.117.xxx.xxx:6443
KubeDNS is running at https://10.117.xxx.xxx:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

➜  ~ kubectl cluster-info

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server 10.117.xxx.xxx:6443 was refused - did you specify the right host or port?

edit3

Удаление всех образов докеров, контейнеров и т. Д.... и затем выполнить перезапуск с помощью sudo systemctl restart kubelet.service, кажется, делает свое дело в течение нескольких минут, но затем все контейнеры-докеры уничтожаются и удаляются без какого-либо сигнала.Как я могу заглянуть в журналы этих контейнеров, чтобы узнать, почему они уничтожены?

https://pastebin.com/wWSWXM31 файл журнала

Answer 1

Возможно, контейнер kube-apiserver на узле управления либо не запущен, либо докер не запущен.Вы можете имитировать соединение 6443, которое было отклонено, выполнив это:

- из управляющего узла:

sudo systemctl stop docker

kubectl get pods

-- ответ:

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

Не удается найти API, расположенный на порту 6443… Хммм… Таким образом, это демонстрирует, что эта конкретная ошибка связана с API и док-контейнером, на котором он работает.Поэтому, если docker не работает или что-либо, блокирующее мой доступ к Docker, прервано, оно выдаст ошибку такого типа.

Давайте вернем его обратно:

sudo systemctl start docker

• дайте ему несколько минут для запуска всех системных контейнеров kubernetes, помните, у вас нет никаких контейнеров приложений на управляющем узле, обычно это только содержимое системы kube.

• это не повлияет на ваши рабочие узлы или контейнеры на них, для них это как отключение от API и ничего более, они будут работать как обычно, если им не нужно что-то критическое из API.

kubectl get pods

- ответ:

NAME READY STATUS RESTARTS ВОЗРАСТ ВОЗРАСТА busybox 1/1 Запуск 0 42h

Answer 2

Я не знаю специфики "Kubernetes", но я могу объяснить, что вы видите.

Отказ в соединении не является отказом в разрешении.Это означает: «Я связался с сервером по этому IP-адресу и порту, и ни один сервер не работал на этом порту».

Итак ... вам придется перейти к удаленной системе (той, которую вы хранитевызов 10.117.xxx.xxx) и перепроверьте, работает ли сервер.И на каком порту.

Например, инструмент «netstat -a» выведет список всех открытых портов и соединений.Вы должны видеть прослушивающие серверы как

tcp        0      0 0.0.0.0:9090            0.0.0.0:*               LISTEN     

здесь, в моем случае, это прослушивание через порт 9090. Вы ищете запись с 6443. Вероятно, ее там не будет, потому что это то, что «отказано в соединении»уже говорит тебе.Вам нужно запустить серверный процесс, который должен предоставлять эту услугу, и следить за ошибками.Проверьте наличие ошибок в / var / log / syslog, если вы не видите их на своем терминале.