Проблема API/панели Kubernetes

Я также разместил это на serverfault, но, надеюсь, здесь будет больше просмотров/отзывов:

Попытка заставить пользовательский интерфейс Dashboard работать в кластере kubeadm, используя kubectl proxy для удаленного доступа. Получающий

Error: 'dial tcp 192.168.2.3:8443: connect: connection refused'
Trying to reach: 'https://192.168.2.3:8443/'

при доступе к http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ через удаленный браузер.

Глядя на журналы API, я вижу, что получаю следующие ошибки:

I1215 20:18:46.601151       1 log.go:172] http: TLS handshake error from 10.21.72.28:50268: remote error: tls: unknown certificate authority
I1215 20:19:15.444580       1 log.go:172] http: TLS handshake error from 10.21.72.28:50271: remote error: tls: unknown certificate authority
I1215 20:19:31.850501       1 log.go:172] http: TLS handshake error from 10.21.72.28:50275: remote error: tls: unknown certificate authority
I1215 20:55:55.574729       1 log.go:172] http: TLS handshake error from 10.21.72.28:50860: remote error: tls: unknown certificate authority
E1215 21:19:47.246642       1 watch.go:233] unable to encode watch object *v1.WatchEvent: write tcp 134.84.53.162:6443->134.84.53.163:38894: write: connection timed out (&streaming.encoder{writer:(*metrics.fancyResponseWriterDelegator)(0xc42d6fecb0), encoder:(*versioning.codec)(0xc429276990), buf:(*bytes.Buffer)(0xc42cae68c0)})

Я предполагаю, что это связано с невозможностью заставить панель инструментов работать, и если да, то мне интересно, в чем проблема с сервером API. Все остальное в кластере работает.

NB, у меня локально работает admin.conf, и я без проблем могу получить доступ к кластеру через kubectl.

Также следует отметить, что это работало, когда я впервые поднял кластер. Однако у меня были проблемы с сетью, и мне пришлось применить это, чтобы заставить CoreDNS работать «>Служба Coredns не работает, но конечная точка в порядке, другие SVC работают нормально, только кроме dns, поэтому мне интересно, не сломало ли это прокси-службу?

* ИЗМЕНИТЬ *

Вот вывод для модуля панели инструментов:

[gms@thalia0 ~]$ kubectl describe pod kubernetes-dashboard-77fd78f978-tjzxt --namespace=kube-system
Name:               kubernetes-dashboard-77fd78f978-tjzxt
Namespace:          kube-system
Priority:           0
PriorityClassName:  <none>
Node:               thalia2.hostdoman/hostip<redacted>
Start Time:         Sat, 15 Dec 2018 15:17:57 -0600
Labels:             k8s-app=kubernetes-dashboard
                    pod-template-hash=77fd78f978
Annotations:        cni.projectcalico.org/podIP: 192.168.2.3/32
Status:             Running
IP:                 192.168.2.3
Controlled By:      ReplicaSet/kubernetes-dashboard-77fd78f978
Containers:
  kubernetes-dashboard:
    Container ID:  docker://ed5ff580fb7d7b649d2bd1734e5fd80f97c80dec5c8e3b2808d33b8f92e7b472
    Image:         k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.0
    Image ID:      docker-pullable://k8s.gcr.io/kubernetes-dashboard-amd64@sha256:1d2e1229a918f4bc38b5a3f9f5f11302b3e71f8397b492afac7f273a0008776a
    Port:          8443/TCP
    Host Port:     0/TCP
    Args:
      --auto-generate-certificates
    State:          Running
      Started:      Sat, 15 Dec 2018 15:18:04 -0600
    Ready:          True
    Restart Count:  0
    Liveness:       http-get https://:8443/ delay=30s timeout=30s period=10s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /certs from kubernetes-dashboard-certs (rw)
      /tmp from tmp-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kubernetes-dashboard-token-mrd9k (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  kubernetes-dashboard-certs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  kubernetes-dashboard-certs
    Optional:    false
  tmp-volume:
    Type:    EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
  kubernetes-dashboard-token-mrd9k:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  kubernetes-dashboard-token-mrd9k
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node-role.kubernetes.io/master:NoSchedule
                 node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

Я проверил сервис:

[gms@thalia0 ~]$ kubectl -n kube-system get service kubernetes-dashboard
NAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes-dashboard   ClusterIP   10.103.93.93   <none>        443/TCP   4d23h

Также следует отметить, что если я curl http://localhost:8001/api с главного узла, я получаю действительный ответ.

Итак, в общем, я не уверен, какая из этих ошибок является причиной невозможности доступа к панели инструментов.

Я только что обновил свой кластер до 1.13.1, в надежде, что эта проблема будет решена, но увы, нет.


person horcle_buzz    schedule 21.12.2018    source источник


Ответы (2)


Когда вы делаете kubectl proxy , порт по умолчанию 8001 доступен только с локального хоста. Если вы подключаетесь по ssh к машине, на которой установлен kubernetes, вы должны сопоставить этот порт с вашим ноутбуком или любым устройством, используемым для ssh.

Вы можете использовать ssh для мастер-узла и сопоставить порт 8001 с вашим локальным ящиком:

ssh -L 8001:localhost:8001 hostname@master_node_IP
person Majid Rajabi    schedule 22.12.2018
comment
Да, я делаю это. У меня есть решение, и я опубликую его в свое время. Сейчас я имею дело с более серьезной проблемой. Спасибо! - person horcle_buzz; 22.12.2018

Я обновил все узлы в кластере до версии 1.13.1 и вуаля, панель инструментов теперь работает, И до сих пор мне не приходилось применять исправление CoreDNS, указанное выше.

person horcle_buzz    schedule 22.12.2018