Kubernetes Dashboard - невідома помилка сервера після входу

Я успішно розгорнув Kubernetes через Kubespray, і все, здається, працює нормально. Я можу отримати доступ до кластеру через kubectl та перелічити вузли, стручки, служби, секрети тощо. Можливо також застосувати нові ресурси, а кінцева точка панелі інструментів отримує мені сторінку входу на інформаційну панель.

Я входив з жетонами різних облікових записів (за замовчуванням, kubernetes-панель інструментів, kubernetes-admin, ...) ... при кожному вході я отримую ті самі спливаючі вікна, як описано, наприклад, на попередній панелі інформаційної панелі kubespray .

Тому я застосував кластерне зв'язування для облікового запису служби за замовчуванням, як описано. Коли я зараз входжу в систему за допомогою маркера за замовчуванням, я отримую лише

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

вікно, яке потім перенаправляє мене на сторінку входу. Це та ж поведінка, якщо я підключаюся до панелі керування через kubectl proxy. Доступ - HTTPS через IP публічного кластера, а також HTTP через проксі

Я використовую Kubernetes 1.16.2 і найновіший майстер Kubespray віддаю 18d19d9e

EDIT: Я знищив і переглянув кластер, щоб отримати свіжий екземпляр, що підтримується Kubespray, щоб зробити всі кроки детермінованими, додавши більше інформації ...

kubectl -n kube-system logs --follow kubernetes-dashboard-556b9ff8f8-jbmgg -- під час спроби входу мене дає

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.

Я знайшов дивне вирішення, щоб приладна панель працювала , але це не є корисним для нас у виробництві, можливо, хтось може це пояснити:

1. Я беру для прикладу serviceaccount kube-system:default(Примітка: ця cluster-adminв даний момент НЕ призначена
2. Я отримую його маркер і входжу з цим
3. Інформаційна панель очевидно показує мені "заборонені спливаючі вікна"
4. Поки ще увійшов, я бігаю kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=kube-system:default
5. Я оновлюю вкладку веб-переглядача, яка вміщує мою сесію інформаційної панелі ... і т.д., все відображається правильно.

Тому я не в змозі знову вийти з системи та увійти, мені завжди потрібно видалити кластерне зв'язування, потім увійти та після цього знову застосувати кластерне зв'язування.

Це, здається, сильно пов'язане з кластерами, передбаченими кубеспреєм, так що хтось здатний відтворити це за допомогою кубеспрею?

Якщо ви використовуєте сертифікат для підключення, сертифікат повинен бути в системі: master групи. Тому включіть "Subject: O = система: master, CN ="

Ви також можете створити маркер, а потім використовувати маркер замість сертифіката:

Можливо, можливо, ваша роль кластера прив’язана до "Облікового запису", але не до вашої групи. Ви повинні перевірити свою групу у файлі yaml. У вашому обліковому записі служби є маркер доступу, використовуйте його для автентифікації замість вашого сертифіката.

Використовуйте це, щоб створити маркер і використовувати його.

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

маркер:

Оновіть kubeconfig, щоб автентифікувати себе за допомогою цього маркера замість сертифіката, який ви зараз використовуєте, і вам слід успішно пройти автентифікацію як обліковий запис служби кластера-адміністратора.

Kubernetes RBAC - заборонена спроба надання додаткових пільг

Гаразд, це, здається, помилка, яка видана у репортажі Kubespray Github № 5347