Панель мониторинга Kubernetes в CrashLoopbackOff: ошибка при инициализации подключения к серверу Kubernetes - PullRequest
0 голосов
/ 10 июня 2018

У меня новая установка kubernetes в кластере из 3 узлов (ubuntu 16.04, VirtualBox) с использованием kubadm:

  kubeadm version: &version.Info{Major:"1", Minor:"10",      GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:05:37Z",  GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Я установил панель управления kubernetes, используя стандартное определение yaml:

  kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

Однако я вижу, что модуль продолжает падать:

 kube-proxy-6bzmx                        1/1       Running            2          1d
 kube-proxy-9jp98                        1/1       Running            2          1d
 kube-proxy-bppbp                        1/1       Running            0          1d
 kube-scheduler-kubemaster               1/1       Running            2          1d 
 kubernetes-dashboard-7d5dcdb6d9-9snln   0/1       CrashLoopBackOff   1          1m

Я изменил строку apiserver-url следующим образом:

--apiserver-host=https://127.0.0.1:6443

Я могу свернуть ответ от APIURL-адрес сервера:

root@kubemaster:~/dashboard# curl -k https://192.168.99.20:6443/version
{
 "major": "1",
"minor": "10",
"gitVersion": "v1.10.3",
"gitCommit": "2bba0127d85d5a46ab4b778548be28623b32d0b0",
 "gitTreeState": "clean",
"buildDate": "2018-05-21T09:05:37Z",
 "goVersion": "go1.9.3",
"compiler": "gc",
"platform": "linux/amd64"
}

И:

 root@kubemaster:~/dashboard# curl -k  https://127.0.0.1:6443/version
 {
 "major": "1",
 "minor": "10",
 "gitVersion": "v1.10.3",
 "gitCommit": "2bba0127d85d5a46ab4b778548be28623b32d0b0",
 "gitTreeState": "clean",
 "buildDate": "2018-05-21T09:05:37Z",
 "goVersion": "go1.9.3",
 "compiler": "gc",
 "platform": "linux/amd64"
}

Это работает даже внутри контейнера, запущенного через докер на главном сервере:

 root@79e42d97e37d:/# curl -k https://192.168.99.20:6443/version
 {
 "major": "1",
  "minor": "10",
  "gitVersion": "v1.10.3",
  "gitCommit": "2bba0127d85d5a46ab4b778548be28623b32d0b0",
  "gitTreeState": "clean",
  "buildDate": "2018-05-21T09:05:37Z",
  "goVersion": "go1.9.3",
  "compiler": "gc",
  "platform": "linux/amd64" 

, а такжес одного из подчиненных узлов:

 root@kubenode1:~#  curl -k https://192.168.99.20:6443/version
 { 
  "major": "1",
  "minor": "10",
  "gitVersion": "v1.10.3",
  "gitCommit": "2bba0127d85d5a46ab4b778548be28623b32d0b0",
  "gitTreeState": "clean",
 "buildDate": "2018-05-21T09:05:37Z",
 "goVersion": "go1.9.3",
 "compiler": "gc",
 "platform": "linux/amd64"
 }

Однако повторное развертывание приводит к тому, что модуль заканчивается в CrashloopBackup с той же ошибкой:

Остановка узлов для принудительного развертывания панели мониторинга на главном сервере.просто приводит к тому, что модуль остается в состоянии ожидания навсегда:

Every 2.0s: kubectl get po -n kube-system                                                                                                Tue Jun  5 05:04:56 2018

NAME                                    READY     STATUS    RESTARTS   AGE 
etcd-kubemaster                         1/1       Running   8          1d
kube-apiserver-kubemaster               1/1       Running   9          1d
kube-controller-manager-kubemaster      1/1       Running   8          1d
kube-dns-86f4d74b45-kf8mr               3/3       Running   21         1d
kube-flannel-ds-5cl8l                   1/1       Running   5          1d
kube-flannel-ds-8fgk6                   1/1       Running   1          1d
kube-flannel-ds-hmzdb                   1/1       Running   9          1d
kube-proxy-6bzmx                        1/1       Running   8          1d
kube-proxy-9jp98                        1/1       Running   3          1d
kube-proxy-bppbp                        1/1       Running   1          1d
kube-scheduler-kubemaster               1/1       Running   9          1d
kubernetes-dashboard-7f86dc5d9c-sdtb5   0/1       Pending   0          4m

Однако, как я вижу из журналов kube-proxy, kube-proxy также не может достичь API ("dial tcp 192.168.99.20:6443: getsockopt: соединение отказано "):

E0609 20:49:25.816749       1 reflector.go:205] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:86: Failed to list *core.Service: Get https://192.168.99.20:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 192.168.99.20:6443: getsockopt: connection refused

Вещи, которые я до сих пор пробовал:

1) отключить ipv6 на master-устройстве linux 2) остановить все узлы и убедиться, что панель мониторинга развертывается только на master-сервере 3) изменить URL-адрес API с http на https

Это известная проблема?Кроме того, как я могу получить работающую панель инструментов: -)

Заранее спасибо за любую помощь!

1 Ответ

0 голосов
/ 24 июня 2018

Панель управления kubernetes должна работать на главном узле.

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

Лучшим решением было бы просто добавить ограничение, ограничивающее развертывание панели мониторинга на главном узле.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...