не, не из heapster или metrics-server точно, там прям в прометей идет

Но вообще могли бы сделать через metrics api конечно

угу
https://github.com/openshift/console/blob/3459ca47b9ce76523cde18c2e6cc440db4b7fcd1/frontend/packages/dev-console/src/components/monitoring/queries.ts#L27
осталось понять, где он берет адрес prometheus

RTFS - лучшая документация)

Вот тут не хватает ролевой модели. Чтобы каждый разраб видел в консоли то, на что прав хватает.

Ох, не стоит, не стоит запускать дашборд от ранчера

Да, ты был прав. Rancher в режиме "просто дашборда вместо kubectl" работать вряд-ли умеет.
Запустил под SA с правами edit на один ns. Рендерил их дефолтный helm шаблон.

Пытается писать в директории: /var/lib/rancher, /.rancher, /var/log, /tmp. Если хоть куда-то нет прав - падает.
Сам по себе пораждает 4 процесса: tini, rancher, etcd, k3s. С etcd и k3s вообще не понял, зачем он это делает?
В api куба пытается зарегать кучу ресурсов своих, и кучу всякой дичи видимо, ошибок немерено.
Не понимаю зачем поднимать свои etcd и k3s внутри контейнера с дашбордом, когда у них дефолтный метод деплоя через rke, и сам дашборд деплоется в уже поднятный кластер. Как-то странно.

Но в итоге дашборд так и не поднялся, ready проба не проходит. А в логи постоянно пишет: Waiting for k3s to start.

Вобшем этот дашборд, точно мне не подходит. Пытается засрать мой кластер, да еще и свой миникластер зачем-то внутри себя поднимает 🤦

есть такая штука https://github.com/argoproj/argo

@nv30over просил сообщить, если найду даш, который понравится.

Поробовал openshift-console (https://github.com/openshift/console). Довольно неплох.
quay.io/openshift/origin-console:latest не завелся (4.6.0 и v3.11.0 нормально работали)
Интерфейс понравился больше чем у octant, k8dash.

Удобен в настройке, так как понимает что запущен внутри куба, и идет по дефолтным путям за секретами. Ему достаточно указать нужный serviceAccountName в поде и разрешить automountServiceAccountToken(он как правило разрешен по дефолту) и все. Тот же octant ищет kubeconfig, и ему нужен секрет именно в таком формате, с другой стороны octant предназначен для локального использования, а не для запуска в кластере.

С ограниченными правами работает по лучше чем k8dash, единственный нюанс, нужно догадаться перейти на /search/ns/нужный-ns. По умолчанию он тебя кидает на default ns, права на которые ты можешь не иметь. Также есть странность, что он некоторую инфу не может отобразить о кластере, даже с полными правами (cluster-admin): http://dl4.joxi.net/drive/2020/03/13/0030/2608/1985072/72/0fdf573211.jpg

Интерфейс выглядит так: http://dl4.joxi.net/drive/2020/03/13/0030/2608/1985072/72/6d53512a73.jpg

Всякие штуки для дебага в нем делать достаточно удобно. Как замена kubectl для прогеров думаю сойдет.
То что он из проекта openshift, и в кластере нативного куба наверное могут быть какие-то баги, но в целом все работает. Видно, что некоторые запросы возвращают 404 ошибку. Но вроде он умный и просто не показывает меню, для объектов, которые не смог вытащить из куба или на них нету прав. Например под ограниченной учеткой нет меню со списком нод.

На ранчер я конечно посмотрю, но пока openshift-console мой выбор

Для проверки/отображения прав есть какой-то плагин (названия не помню). Пользуетесь им?

Старые версии, конечно, засирают кластер, но к3с не ставят.

Кто-нить решал успешно в кубе задачу запуска друг за другом сервисных задач? У меня такая ситуация: есть отдельная реплика для построения всяких отчетов и т.п. Сейчас у меня есть несколько кронджоб (в разных неймспейсах), которым время запуска назначено руками, т.к. каждая кронджоба грузит эту реплику БД на пару часов. Хотелось бы какой-то инструмент, который бы запускал следующую джобу просто сразу после предыдущей, чтоб оно там всё вместе максимально без простоев выполнялось друг за другом

Есть вариант отказаться от кронджоба кубернетес для таких случаев , сделать образ суперкроник с расписанием (он не стартует следующую джобу пока не закончил старую)