Kubernetes Dashboard - Erreur de serveur inconnu après la connexion

Question

J'ai déployé avec succès Kubernetes via Kubespray et tout semble fonctionner correctement. Je peux accéder au cluster via kubectl et lister les nœuds, les pods, les services, les secrets, etc. Il est également possible d'appliquer de nouvelles ressources et le point de terminaison du tableau de bord me donne la page de connexion du tableau de bord.

Je me suis connecté avec les tokens de différents comptes de service (default, kubernetes-dashboard, kubernetes-admin, ...)... à chaque connexion, j'obtiens les mêmes popups que ceux décrits dans la rubrique kubespray dashboard warning forbidden popups par exemple.

J'ai donc appliqué le clusterrolebinding pour le compte de service par défaut comme décrit. Lorsque je me connecte maintenant avec le jeton du compte par défaut, je n'obtiens qu'un message de type

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

qui me redirige ensuite vers la page de connexion. C'est le même comportement si je me connecte au tableau de bord via kubectl proxy . L'accès est HTTPS sur une IP publique du cluster et également HTTP sur un proxy.

J'utilise Kubernetes 1.16.2 et le dernier commit master 18d19d9e de Kubespray.

EDITAR: J'ai détruit et reprovisionné le cluster pour obtenir une instance fraîche provisionnée par Kubespray afin de rendre toutes les étapes déterministes, en ajoutant plus d'info...

kubectl -n kube-system logs --follow kubernetes-dashboard-556b9ff8f8-jbmgg -- lors d'une tentative de connexion me donne

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.

J'ai trouvé une solution étrange pour faire fonctionner le tableau de bord. mais ce n'est pas utilisable pour nous en production, peut-être que quelqu'un peut l'expliquer :

1. Je prends par exemple le compte de service kube-system:default (Note : celle-ci n'est pas attribuée cluster-admin à ce stade
2. J'obtiens son jeton et je me connecte avec ce jeton
3. Le tableau de bord me montre évidemment les "forbidden-popups".
4. Tout en restant connecté, je lance kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=kube-system:default
5. Je rafraîchis l'onglet du navigateur qui contient ma session de tableau de bord... et voilà, tout s'affiche correctement.

Par conséquent, je ne peux pas me déconnecter et me reconnecter, je dois toujours supprimer le clusterrolebinding, me connecter puis appliquer à nouveau le clusterrolebinding.

Cela semble être fortement lié aux clusters provisionnés par kubespray, donc quelqu'un peut-il reproduire ce problème avec kubespray ?

Answer 1

Si vous utilisez un certificat pour vous connecter, celui-ci doit se trouver dans le groupe system:masters : O=system:masters, CN="

Vous pouvez également créer un jeton et l'utiliser à la place du certificat :

Il est possible que votre rôle de cluster soit lié à "Service Account" mais pas à votre groupe, vous devriez vérifier votre groupe dans le fichier yaml. Votre compte de service a un jeton d'accès, utilisez-le pour vous authentifier au lieu de votre certificat.

Utilisez-le pour créer un jeton et l'utiliser.

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

de l'argent :

Mettez à jour kubeconfig pour vous authentifier à l'aide de ce jeton, au lieu du certificat que vous utilisez actuellement, et vous devriez être authentifié avec succès en tant que compte de service cluster-admin.

Kubernetes RBAC - tentative interdite d'octroi de privilèges supplémentaires

Answer 2

D'accord, il semble que ce soit un bogue qui est publié dans le repo Github de Kubespray. numéro 5347