Kubernetes Dashboard - Unbekannter Serverfehler nach der Anmeldung

Ich habe Kubernetes erfolgreich über Kubespray bereitgestellt und alles scheint gut zu funktionieren. Ich kann über kubectl auf den Cluster zugreifen und Knoten, Pods, Dienste, Geheimnisse usw. auflisten. Es ist auch möglich, neue Ressourcen anzuwenden, und der Dashboard-Endpunkt bringt mir die Dashboard-Anmeldeseite.

Ich habe mich mit Token verschiedener Servicekonten (Standard, Kubernetes-Dashboard, Kubernetes-Admin, ...) angemeldet. Bei jeder Anmeldung erhalte ich dieselben Popups wie in Kubespray-Dashboard beschrieben, um beispielsweise verbotene Popups zu warnen .

Daher habe ich die Clusterrollenbindung für das Standarddienstkonto wie beschrieben angewendet. Wenn ich mich jetzt mit dem Standardkontotoken anmelde, erhalte ich nur eine

Unknown Server Error (404)
the server could not find the requested resource
Redirecting to previous state in 3 seconds...

Feld, das mich anschließend zur Anmeldeseite weiterleitet. Es ist das gleiche Verhalten, wenn ich über eine Verbindung zum Dashboard herstelle kubectl proxy. Der Zugriff erfolgt über HTTPS über eine öffentliche Cluster-IP sowie über HTTP über einen Proxy

Ich verwende Kubernetes 1.16.2 und das neueste Kubespray-Master-Commit 18d19d9e

BEARBEITEN: Ich habe den Cluster zerstört und erneut bereitgestellt, um eine neue, von Kubespray bereitgestellte Instanz zu erhalten, die alle Schritte deterministisch macht und weitere Informationen hinzufügt ...

kubectl -n kube-system logs --follow kubernetes-dashboard-556b9ff8f8-jbmgg -- während eines Login-Versuchs gibt mir

2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/csrftoken/login request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 POST /api/v1/login request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/login/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/csrftoken/token request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 POST /api/v1/token/refresh request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/login/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/csrftoken/token request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 POST /api/v1/token/refresh request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/overview/default?filterBy=&itemsPerPage=10&name=&page=1&sortBy=d,creationTimestamp request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 Getting config category
2019/12/16 12:35:03 Getting discovery and load balancing category
2019/12/16 12:35:03 Getting lists of all workloads
2019/12/16 12:35:03 the server could not find the requested resource
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 404 status code
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 Getting pod metrics
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Incoming HTTP/2.0 GET /api/v1/systembanner request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Incoming HTTP/2.0 GET /api/v1/login/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Incoming HTTP/2.0 GET /api/v1/rbac/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:12 Metric client health check failed: the server could not find the requested resource (get services heapster). Retrying in 30 seconds.
2019/12/16 12:35:42 Metric client health check failed: the server could not find the requested resource (get services heapster). Retrying in 30 seconds.

Ich habe eine seltsame Problemumgehung gefunden, um das Dashboard zum Laufen zu bringen , aber dies ist für uns in der Produktion nicht verwendbar. Vielleicht kann jemand dies erklären:

1. Ich nehme zum Beispiel das Servicekonto kube-system:default(Hinweis: Dieses ist cluster-adminzu diesem Zeitpunkt NICHT zugewiesen
2. Ich bekomme sein Token und logge mich damit ein
3. Das Dashboard zeigt mir offensichtlich die "Verbotenen Popups"
4. Während ich noch angemeldet bin, renne ich kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=kube-system:default
5. Ich aktualisiere die Browser-Registerkarte, auf der sich meine Dashboard-Sitzung befindet ... et voila, alles wird korrekt angezeigt.

Daher kann ich mich nicht abmelden und erneut anmelden. Ich muss immer die Clusterrollenbindung löschen, mich dann anmelden und anschließend die Clusterrollenbindung erneut anwenden.

Dies scheint stark mit von Kubespray bereitgestellten Clustern verbunden zu sein. Kann jemand dies mit Kubespray reproduzieren?

Wenn Sie ein Zertifikat verwenden, um eine Verbindung herzustellen, sollte sich Ihr Zertifikat in der Gruppe system: masters befinden. Geben Sie daher "Subject: O = system: masters, CN =" an.

Sie können auch ein Token erstellen und dann das Token anstelle des Zertifikats verwenden:

Möglicherweise ist Ihre Clusterrolle an "Dienstkonto" gebunden, nicht jedoch an Ihre Gruppe. Sie sollten Ihre Gruppe in der yaml-Datei überprüfen. Ihr Dienstkonto verfügt über ein Zugriffstoken. Verwenden Sie dieses zur Authentifizierung anstelle Ihres Zertifikats.

Verwenden Sie diese Option, um ein Token zu erstellen und es zu verwenden.

kubectl describe secret $(kubectl get secret | grep cluster-admin | awk '{print $1}')

Zeichen:

Aktualisieren Sie kubeconfig, um sich mit diesem Token anstelle des aktuell verwendeten Zertifikats zu authentifizieren. Sie sollten erfolgreich als Cluster-Administrator-Dienstkonto authentifiziert werden.

Kubernetes RBAC - verbotener Versuch, zusätzliche Berechtigungen zu gewähren

Okay, dies scheint ein Fehler zu sein, der in der Kubespray Github Repo Ausgabe Nr. 5347 ausgegeben wird