У меня есть Consul, работающий в моем кластере, и каждый узел запускает consul-agent как DaemonSet. У меня также есть другие DaemonSet, которые взаимодействуют с Consul и, следовательно, требуют, чтобы был запущен consul-agent для связи с серверами Consul.
Моя проблема в том, что если мой DaemonSet запускается до consul-agent, приложение выдает ошибку, так как не может подключиться к Consul и впоследствии перезапустится.
Я также заметил ту же проблему с другими наборами DaemonSet, например Ткать, поскольку для этого требуются kube-proxy и kube-dns. Если Weave запускается первым, он будет постоянно перезапускаться, пока службы kube не будут готовы.
Я знаю, что могу добавить логику повтора в свое приложение, но мне было интересно, можно ли указать порядок, в котором запланированы DaemonSets?

Сам Kubernetes не предоставляет способ установления определенных зависимостей между модулями / развертываниями / службами (например, «запускать модуль A, только если служба B доступна» или «запускать модуль A после модуля B»).
Текущий подход (основанный на том, что я обнаружил во время исследования), похоже, представляет собой логику повторных попыток или контейнер инициализации. Процитируем документы:
They run to completion before any app Containers start, whereas app Containers run in parallel, so Init Containers provide an easy way to block or delay the startup of app Containers until some set of preconditions are met.
Это означает, что вы можете либо добавить логику повтора в свое приложение (что я бы рекомендовал, поскольку это может помочь вам в различных ситуациях, таких как кратковременный сбой службы), либо вы можете использовать контейнер инициализации, который опрашивает конечную точку работоспособности через имя службы Kubernetes, пока она не получает удовлетворительный ответ.
Логика повторных попыток предпочтительнее упорядочения зависимостей при запуске, поскольку она обрабатывает как начальный случай запуска, так и восстановление после сбоев после запуска