Подскажите, как запускать одноразовую команду, когда что-то меняется? Т.е. я

поменял что-то, создался pod и отработал. Смысл в том, чтобы изменения конфигурации применять.

Пока мысль такая - сделать deployment с restartPolicy: OnFailure. Если pod template меняется то создастся новый pod, который отработает. Правильный подход?

ничё не понятно

Есть настройки кейклока, при их изменении должна запуститься утилита keycloak-config-cli (в своем образе), которая один раз отработает, подключится к работающему кейклоку и применит эти изменения. Если я завтра эти настройки меняю, в кубернетесе конфигмап меняется и опять надо, чтобы запустилась эта утилита.

о, уже вырисовывается. То есть тебе надо при изменении configmap перезапустить pod, который монтирует его как файл?

примерно, только в поде команда одноразовая, то бишь она отработала и контейнер потушился

ну то есть у тебя это сделано через job?

собственно поэтому через деплоймент и подумал - там при изменении pod spec будет пересоздаваться pod и запустится заново. Ну а pod spec через kustomize изменится т.к. configmap поменяет своё название при изменении содержимого

Вообще это делает енрипоинт

через job лучше.

не очень понял, чтобы отработала эта утилита, кейклок уже должен быть запущен, я думал сделать два контейнера в поде кейклока, но чет странно это всё

Ты читал ентрипоинт клоаки в целом?

не особо, ты про то, что можно импортировать рилм? это я в курсе, но мне надо его менять если он поменялся, уже существующий он не поменяет, или я ошибаюсь?

так keycloak-config-cli через него и работает. Это configuration-as-json утилита

можно взять что-то и на основе этого сделать - https://github.com/jimmidyson/configmap-reload или shell-operator от флант ну или самому написать. Достаточно подписаться на события изминения configmap и запускать keycloak-config-cli

ок, спасибо, подумаем. а чем плох подход с деплойментом и соотв. restartPolicy?

а я не понял как это поможет. При изминении pod.template deployment в любом случае будет делать rolling update, restartPolicy на это не влияет

Ну старый под удалится, новый создастся. Отработает и будет висеть 0/1, никому не мешая.

при роллинг апдйетах старые поды просто удаляются. Видимо я не понимаю о чем речь

мне надо не кейклок рестартовать, а другую тулзу запускать (docker.io/adorsys/keycloak-config-cli), чтобы она один раз отработала успешно и завершилась. Кейклок тут просто при том, что он где-то есть, он может и не в кластере быть (хотя он в кластере).

Эта утилита должна запускаться где? Она с киклоак как работает? По апи ?

ну желательно в кубернетесе. Да, по хттп соединяется и через апи работает.

если у тебя configmap в том же kustomize что и джоб. То generateName да

этот подход плох тем, что в deployment нельзя менять restartPolicy, он принимает только always, ясно-понятно)

полагаю, можно через deployment в котором в init container-е сделать что надо, а в основном контейнере sleep infinity сделать, ну это уже изврат какой-то

а зачем в deployment менять restartPolicy я так и не понял

Ну у меня был план запускать через deployment, т.к. его можно менять, а job нельзя. Типа поменял deployment и он создал под, который отработал и всё, до следующего изменения. В итоге через джоб сделал, но его надо руками удалять перед каждым изменениям, неудобно, конечно.

а понял. Да, на этот случай придуман generateName, но ваще в kustomize и до этого были генераторы вроде для Job'ы (generateName - это фича куба, а генераторы имен kustomize на его уровне делаются)

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

версия куба какая?

1.25

покажи как делаешь Job с generateName

% cat kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: default resources: - job.yaml % cat job.yaml apiVersion: batch/v1 kind: Job metadata: generateName: test- spec: template: spec: containers: - name: test image: alpine command: ["echo", "Job's done1"] restartPolicy: Never % k apply -k . error: accumulating resources: accumulation err='accumulating resources from 'job.yaml': missing metadata.name in object {{batch/v1 Job} {{ } map[] map[]}}': must build at directory: 'test/job.yaml': file is not directory

надо через create

похоже тебе придется выделять на этапы k apply -k . k create -f path/to/job.yaml

Так можно, да. Хотелось просто, чтобы оно само запускалось, когда что-то меняется. Через фиксированное имя так и происходит (точней не происходит, но если что-то поменялось - выдаёт ошибку, что подсказывает, что старую job надо удалить).

flux/argo кстати норм схавают и задеплоят. argocd точно generateName умеет определять и вызывает kubectl create для таких Job

flux тоже умеет, читал в его доке

ну оно само. Просто вместо однго этапа нужно два если хочется в один этап, то в kustomize тебе придется генератор написать

по описанию похоже, будто это часть функционала от stakater/reloader. Это так? Если да - то зачем его рекомендовать, а не stakater/reloader?

stacker/reloader также был рекомендван. А почему посоветовал глянуть именно этот понятно из контекста треда (если интересно, вникай читай тред, если не интересно, то непонятно к чему доп. вопросы)

Читал, но не понял. Чел просил триггер "cm changed -> restart pod". По описанию предложенной утилиты похоже, что она только это и умеет, а stakater/reloader умеет ещё и много чего ещё, потому и вопрос про энтропию... ok, nvm

ну ваще чел просил cm changed => run keyclock cli который заливает конфигурацию в keycloack рестартовать keycloack он не хотел следовательно stacker/reloader не то что нужно > По описанию предложенной утилиты похоже, что она только это и умеет, нет, она не рестартит поды

ааа, она даже рестартить не умеет, только по http оповещать... Я не знаю зачем оно существует, если stakater/reloader уже изобретён

тебе нужно перекомпелировать свою stacker/reloader центричность и понять, что есть скоуп задач, когда не нужно перезапускать поды после имзинения конфига. Например так реализован релоад конфига прометеуса, в prometheus операторе Повторюсь, stacker/reloader был пропущен, поскольку рестартовать pod не нужно, нужно было залить новую конфигурацию в keycloack. Как пример такого контроллера было предложено глянуть на https://github.com/jimmidyson/configmap-reload

теперь понятно (упустил из виду, что stakater/reloader умеет только pod reload, но не умеет просто оповещать по http / сигналом процессу), спасибо

опять не много упустил смысл =) рубрика пересказываем треды в том сообщении было предложенно глянуть этот контроллер как концепт, ему не нужно было слать вебхук, ему нужно залить конфигурацию в keycoack. Посмотрев код контроллера, можно быстро своять свое решение, которое вместо хука запускает нужный тебе exec, ну или сразу в API keyclock заливает конфиг.