k
поддерживается апстримом, но я так понял что шапка была там крупнейшим юзером - а после движения на операторы там всё затухло
Оказалось не всё, kyma-project.io активно использует OSBA, даже Helm Broker завезли.
Size: a a a
2020 June 27
k
Kyma выглядит достаточно интересно, в понедельник поковыряю его ещё
ST
Есть способ вытянуть набор _meta лейблов для подов и их значений? Не работает relabel, думаю может _meta не собирается
ST
слабо разобрался пока в вопросе, насколько я понял собираются с аннотациями prometheus.io/scrape
PK
в проме в таргетах на наведи мышой на любое значение в колонке labels
ST
а, ок, значит собирается все, можешь подсказать почему не работает релейбл?
endpoints:
- port: "metrics"
path: "/metrics"
relabelings:
- action: replace
sourceLabels:
- __meta_kubernetes_endpoint_node_name
targetLabel: node_name
DS
Привет.
А есть в K8S возможность напилить свою dashboard, или сделать extend существующей? Чтобы это было красиво
и "по правилам" как делают операторы? Есть идея для ПО, у которого свой UI, который обращается на бек-енд, который обращается в API K8S за какой-то информацией (ну, список подов). Хочется именно чтобы это в K8S интегрировалось как операторы. Подскажите, пожалуйста.
А есть в K8S возможность напилить свою dashboard, или сделать extend существующей? Чтобы это было красиво
и "по правилам" как делают операторы? Есть идея для ПО, у которого свой UI, который обращается на бек-енд, который обращается в API K8S за какой-то информацией (ну, список подов). Хочется именно чтобы это в K8S интегрировалось как операторы. Подскажите, пожалуйста.
i
Пиши что хочешь, дашборд - таки гуевая обёртка над api
ST
Привет.
А есть в K8S возможность напилить свою dashboard, или сделать extend существующей? Чтобы это было красиво
и "по правилам" как делают операторы? Есть идея для ПО, у которого свой UI, который обращается на бек-енд, который обращается в API K8S за какой-то информацией (ну, список подов). Хочется именно чтобы это в K8S интегрировалось как операторы. Подскажите, пожалуйста.
А есть в K8S возможность напилить свою dashboard, или сделать extend существующей? Чтобы это было красиво
и "по правилам" как делают операторы? Есть идея для ПО, у которого свой UI, который обращается на бек-енд, который обращается в API K8S за какой-то информацией (ну, список подов). Хочется именно чтобы это в K8S интегрировалось как операторы. Подскажите, пожалуйста.
Чтобы это было красиво
и "по правилам" как делают операторы?
> ???
и "по правилам" как делают операторы?
> ???
DS
Пиши что хочешь, дашборд - таки гуевая обёртка над api
Просто хотел меньше забод для клиентов. Типа если я напишу что отдельное, то клиенту придется
самому заботиться за какое-то Service, Ingress, etc. Может, нет.
самому заботиться за какое-то Service, Ingress, etc. Может, нет.
DS
Чтобы это было красиво
и "по правилам" как делают операторы?
> ???
и "по правилам" как делают операторы?
> ???
Операторы это как "единый путь" расширить функционал K8S.
DS
Ну, типа нет, но признанный.
ST
Операторы это как "единый путь" расширить функционал K8S.
а с дашбордом это как связано
DS
а с дашбордом это как связано
Никак. Просто хочется такой же "единый путь", признаный, как расширить dashboard.
DS
Или свое ПО с UI впилить в K8S.
ST
лучше графаны имхо ничего нет и каждый дашборд делается под задачу
ST
нет правил "рисуй вот так и никак иначе"
ST
точно такой же конструктор отображения метрик
i
Просто хотел меньше забод для клиентов. Типа если я напишу что отдельное, то клиенту придется
самому заботиться за какое-то Service, Ingress, etc. Может, нет.
самому заботиться за какое-то Service, Ingress, etc. Может, нет.
Вообще дашборд вещь сомнительной полезности. Вся забота о service, ingress и подобном производится в коде
i
Все события и логи - в твоем логировании