Укажите порядок планирования Kubernetes DaemonSet

У меня есть Consul, работающий в моем кластере, и каждый узел запускает consul-agent как DaemonSet. У меня также есть другие наборы DaemonSet, которые взаимодействуют с Consul и поэтому требуют, чтобы был запущен consul-agent для связи с серверами Consul.

Моя проблема в том, что если мой DaemonSet запускается до consul-agent, приложение выдает ошибку, так как не может подключиться к Consul и впоследствии перезапустится.

Я также заметил ту же проблему с другими наборами DaemonSet, например, Weave, поскольку для этого требуется kube-proxy и кубе-днс. Если Weave запускается первым, он будет постоянно перезапускаться, пока службы kube не будут готовы.

Я знаю, что могу добавить логику повтора в свое приложение, но мне было интересно, можно ли указать порядок, в котором запланированы DaemonSets?


kubernetes daemonset scheduler
person syscll    schedule 20.05.2018    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Сам Kubernetes не предоставляет способ установления конкретных зависимостей между модулями / развертываниями / службами (например, «запускать модуль A, только если служба B доступна» или «запускать модуль A после модуля B»).

Текущий подход (основанный на том, что я обнаружил во время исследования), похоже, представляет собой логику повторных попыток или контейнер инициализации. Чтобы процитировать документы:

Они выполняются до завершения до запуска любых контейнеров приложений, тогда как контейнеры приложений работают параллельно, поэтому контейнеры инициализации предоставляют простой способ заблокировать или отложить запуск контейнеров приложений до тех пор, пока не будет выполнен некоторый набор предварительных условий.

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

person embik    schedule 20.05.2018

arrow_upward
2
arrow_downward

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

person Jordan Liggitt    schedule 20.05.2018