LINUX.ORG.RU
решено ФорумAdmin

dkron в кубиках

 dkron, ,


0

1

Коллеги,рассматриваем софт опенсорсный для распределенного cron ,однако:

В текущей версии Dkron работает как консул образца 17-18 годов: https://github.com/hashicorp/consul/issues/1580 Dkron для имплементации raft протокола использует IP-шники, что в целом неприемлемо для сред типа k8s, где ip меняется регулярно.

И тут проблема при деплое в k8s: она заключается в том, что при рестарте/смерти несколько подов (> чем число подов, необходимых для консенсуса) кластер разваливается и не может пересобраться, потому что в нодах сохранены старый айпишники при рестарте несколько подов (< чем число подов, необходимых для консенсуса) кластер продолжит работать без ошибок.

Для воспроизведения: Так как нода переходит в healthy до момента, когда она присоединяется к кластеру, соответственно, при рестарте statefulset’следующая нода убивается до того, как предыдущая войдет в кластер и начнет работать (aka нода будет знать лидера)

Посоветуйте как решить ?

★★★★★

Dkron для имплементации raft протокола использует IP-шники

Пропатчить не предлагать?

А так

  1. PodDisruptionBudget
  2. Обернуть каждый Pod в отдельный Service и использовать айпишники Service’ов (+поколдовать с сетью/роутингом, чтобы трафик шёл сразу куда надо, а не куда придётся через kube-proxy)
intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от pinachet

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

Но думаю вам надо детальнее задачу раскрыть, поскольку «распределенный cron» - сильно редкая задача, если вы только не из подвалов какого-нибудь Яндекса пишете.

Но и кстати нет, у Яндекса (судя по слитым исходникам которые я разумеется не видел) нет вообще такой штуки - централизованного cron, вместо этого у них сама задача cron (как выполнение чего-то в фоне по расписанию) решается в разных сервисах как часть бизнес-логики каждого сервиса.

alex0x08 ★★★
()
Последнее исправление: alex0x08 (всего исправлений: 1)

Так как нода переходит в healthy до момента, когда она присоединяется к кластеру, соответственно, при рестарте statefulset’следующая нода убивается до того, как предыдущая войдет в кластер и начнет работать

Напишите lifecycle.postStart скрипт, который будет ожидать реального присоединения ноды к кластеру.

vinvlad ★★
()

Чтобы уж немного закрыть тему «рассинхронизации» k8s-реальности и представлений о ней…

Различные контроллеры сервисов и балансировщики «узнают» о смене статуса Pod-ов не мгновенно - всегда есть вероятность (вполне реальная), что в Pod, перешедший в состояние TERMINATING (т. е. получивший TERM-сигнал) могут прилететь входящие соединения от «соседей». Приложение, уже получившее TERM-сигнал, может просто сбрасывать такие соединения, что не есть хорошо для общей картинки «гладкой» перегрузки Pod-ов - например, при деплое новых версий приложений или смены их конфигурации. Поэтому лучше обеспечивать разумный лаг между переходом Pod-а в состояние TERMINATING и реальной отправкой TERM-сигнала посредством preStop-хука:

containers:
- name NNNN
  ...
  lifecycle:
    preStop:
      exec:
        command: [ "/bin/sh", "-c", "/bin/sleep 5" ]

В чем-то аналогичная ситуация возникает и при переходе Pod-а в состояние RUNNING, если не позаботиться о предварительной проверке реально «боевого» состояния приложения в контейнере, на что и напоролся TC. Для таких проверок предусмотрен postStart-хук. Этот хук можно использовать также для предварительного «разогрева» приложения в контейнере.

Более подробно:

vinvlad ★★
()