Dashboard Kubernetes - Errore del server sconosciuto dopo il login

Ho implementato con successo Kubernetes tramite Kubespray e tutto sembra funzionare bene. Sono in grado di accedere al cluster tramite Kubectl ed elencare nodi, pod, servizi, segreti e così via. È anche possibile applicare nuove risorse e l'endpoint del dashboard mi dà la pagina di accesso al dashboard.

Ho effettuato l'accesso con token di diversi account di servizio (impostazione predefinita, kubernetes-dashboard, kubernetes-admin, ...) ... con ogni accesso ottengo gli stessi popup descritti nell'avviso del dashboard di kubespray, ad esempio i popup vietati .

Quindi ho applicato il clusterrolebinding per l'account del servizio predefinito come descritto. Quando accedo ora con il token dell'account predefinito, ottengo solo a

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

casella che mi reindirizza alla pagina di accesso in seguito. È lo stesso comportamento se mi collego a Dashboard tramite kubectl proxy. L'accesso è HTTPS su un IP cluster pubblico e anche HTTP su proxy

Sto usando Kubernetes 1.16.2 e l'ultimo master Kubespray commette 18d19d9e

EDIT: ho distrutto e riprovisionato il cluster per ottenere una nuova istanza fornita da Kubespray per rendere deterministici tutti i passaggi, aggiungendo ulteriori informazioni ...

kubectl -n kube-system logs --follow kubernetes-dashboard-556b9ff8f8-jbmgg -- durante un tentativo di accesso mi dà

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.

Ho trovato una strana soluzione per far funzionare il cruscotto , ma questo non è utilizzabile per noi in produzione, forse qualcuno può spiegarlo:

1. Prendo ad esempio il serviceaccount kube-system:default(Nota: questo NON è assegnato cluster-admina questo punto
2. Ottengo il suo token e accedo con quello
3. Dashboard ovviamente mi mostra i "popup proibiti"
4. Mentre sono ancora connesso, corro kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=kube-system:default
5. Aggiorna la scheda del browser che contiene la mia sessione del dashboard ... e voilà, tutto viene visualizzato correttamente.

Pertanto non sono in grado di disconnettermi e accedere di nuovo, devo sempre eliminare clusterrolebinding, accedere quindi e applicare nuovamente clusterrolebinding.

Questo sembra essere fortemente correlato ai cluster forniti di kubespray, quindi chiunque è in grado di riprodurlo con kubespray?

Se stai usando il certificato per connetterti, il certificato dovrebbe essere nel sistema: gruppo di master Quindi includi il "Subject: O = system: masters, CN ="

È inoltre possibile creare un token e quindi utilizzare il token anziché il certificato:

Potrebbe esserci la possibilità che il tuo ruolo del cluster sia associato a "Account di servizio" ma non al tuo gruppo. Dovresti controllare il tuo gruppo nel file yaml. Il tuo account di servizio ha un token di accesso, usalo per autenticare al posto del tuo certificato.

Usa questo per creare un token e usarlo.

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

gettone:

Aggiorna kubeconfig per autenticarti usando quel token, invece del certificato che stai attualmente usando, e dovresti essere autenticato con successo come quell'account del servizio di amministrazione del cluster.

Kubernetes RBAC - tentativo proibito di concedere privilegi extra

Bene, questo sembra essere un bug che viene emesso nel numero di repo # 5347 di Kubespray Github