Не совсем по теме чата. Кто нибудь делал в prometheus scrape_interval больше чем на 5 минут и при этом не получать рваные графики?

помогите разобраться) есть ingress для прома. но трудность в том, чтобы пром жил не на домене/поддомене, а по пути domain.org/prometheus в спеках указал path: /prometheus, но при попытке зайти получаю 404. может быть проблема в том, что у прома свой урл-оверрайд, который к урлу добавляет /graph сразу?

помогите разобраться) есть ingress для прома. но трудность в том, чтобы пром жил не на домене/поддомене, а по пути domain.org/prometheus в спеках указал path: /prometheus, но при попытке зайти получаю 404. может быть проблема в том, что у прома свой урл-оверрайд, который к урлу добавляет /graph сразу?

прому желательно параметр передавать однако, что-то типа uriPrefix

Я импортировал, вроде работало

В гуй

В гуй

а вот с таким сообщением от ранчера не сталкивался ? Host must be a URL or a host:port pair: "https://"

у ранчера протухли сертификаты. причем все. как в кластере который он админит, так и его внутренние. и серты по которым он к админке кластера ходил. обновили ранчер с 2.0.8 до 2.0.15 - и теперь статус у кластера Updatting и ниже вот эта запись [state] Fetching cluster state from Kubernetes Host must be a URL or a host:port pair: "https://"

у ранчера протухли сертификаты. причем все. как в кластере который он админит, так и его внутренние. и серты по которым он к админке кластера ходил. обновили ранчер с 2.0.8 до 2.0.15 - и теперь статус у кластера Updatting и ниже вот эта запись [state] Fetching cluster state from Kubernetes Host must be a URL or a host:port pair: "https://"

да вот как бы не хочется в шедулер вмешиваться. Мне все равно что и где крутиться будет, пусть хоть на разных хостах.

ну тогда пиши подробно. что ты понимаешь под словами "прицепить"

мерси!

хм. Сейчас гляну. В принципе этого будет достаточно.

но вообще хотелка странная, стремная и ненужная. сервис тебе все запросы равномерно распределит

все верно. клиенты, которые приходят извне (кастомеры) будут размазаны равномерно по всем нодам. А бекенд, который эти запросы принимает и обрабатывает должен быть у каждой ноды кролика свой. Ибо входные очереди не HA за ненадобностью. И делать их HA вредно для производительности.

дурацкий вопрос - а имена подов резолвятся так же как сервисы в кубере?

а что будет если один под умрет ? вся очередь пропадет же

дурацкий вопрос - а имена подов резолвятся так же как сервисы в кубере?

мордокнига говно

Для тех кто не любит мордокнига. Я в гостях у подлодки. https://soundcloud.com/podlodka/podlodka-120-kubernetes

сорри, но про "взлёт кубернетеса" чушь наговорена

разгадка одна - стабильное АПИ

define стабильное

apiVersion: v1 kind: Pod

если я правильно помню, то некоторые пути менялись при апдейте версий

+ сообщество, которое они нормально менеджили - у докера и dc/os ничего и близко нет

да, про сообщество я забыл

всем привет, столкнулся с проблемой - не могу удалить secret, нет никакой реакции из морды ранчера, при удалении через kubectl просто не отпускает консоль. это как-то лечится? версия 2.2.3

чота после 20ой минуты вообще мрак пошел :/

смотри в finalizers секрета

Давай более детально. А то мне еще писаться, надо исправлять свои косяки.

clusterscoped.controller.cattle.io/secretsController_local только мне не ясно что с этим делать)

я стараюсь там в комменты саундклауда писать, хз читают их или нет. Дослушал дальше - ты правильно про pet vs. cattle сказал. Про особые ноды есть device plugins

clusterscoped.controller.cattle.io/secretsController_local только мне не ясно что с этим делать)

rke releasesecret <название секрета>

clusterscoped.controller.cattle.io/secretsController_local только мне не ясно что с этим делать)

Кто знает: можно ли в CustomResourceDefinition кастомные verbs добавлять? Чтобы делать kubectl dosomething myresource?

Я вот просто думаю как было бы правильно обрабатывать такого рода операции: к примеру я могу добавить .spec.requestedState к ресурсу, и при вызове cli обновлять его в on / off

у нас обычно "spec.managed: true", но отдельного верба для этого нет, просто делаешь kubectl patch

чтобы переключать true/false ?

думаю что кастомные вербы было бы круто, надо посмотреть kep'ы

cat kubectl-manage #!/bin/sh kubectl patch --type=merge -p '{"spec": {"managed": true}}' "$@"вполне юзабельно: kubectl manage mycr test mycr.example.org/test patched kubectl unmanage mycr test mycr.example.org/test patched

а, ну да, вообще тогда неплохо бы написать kubectl plugin для такого

О том и речь, я хочу физические ноды манаджить таким образом, а там будет не только on/off, но и reboot, console, ssh и т.п.

не знаю есть ли плагин для kubectl