Укажите порядок планирования в Kubernetes DaemonSet - PullRequest
0 голосов
/ 20 мая 2018

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 20 мая 2018

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

0 голосов
/ 20 мая 2018

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

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

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

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

...