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

Question

Я использую Плагин Jenkins Kubernetes , который запускает стручки в кластере Kubernetes, которые служат агентами Jenkins. Пакеты содержат 3 контейнера для предоставления ведомой логики c, сокета Docker, а также инструмента командной строки gcloud.

Обычный рабочий процесс заключается в том, что ведомое устройство выполняет свою работу и уведомляет мастер, который он завершил. Затем мастер завершает стручок. Однако, если подчиненный контейнер выходит из строя из-за потерянного сетевого соединения, контейнер завершается с кодом ошибки 255, остальные два контейнера продолжают работать, как и модуль. Это проблема, потому что у модулей большие запросы к ЦП, и настройка дешева, когда подчиненное устройство работает только тогда, когда это необходимо, но наличие нескольких компьютеров, работающих в течение 24 часов или в выходные дни, является заметным финансовым ущербом.

I ' Я знаю, что запуск нескольких контейнеров в одном модуле не подходит для Kubernetes, однако хорошо, если я знаю, что делаю, и предполагаю, что делаю. Я уверен, что это трудно решить по-другому, учитывая то, как работает плагин Jenkins Kubernetes.

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

Answer 1

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

Может быть, вы можете запустить четвертый контейнер, который предоставляет одну простую конечную точку "живучести", он может работать ps -ef или любой другой способ связаться с 3 существующими контейнерами, просто чтобы убедиться, что они живы.

Эта конечная точка может возвращать «ОК», только если все контейнеры запущены, и «ОШИБКА», если хотя бы один из них был обнаружен как « crushed "

Тогда вы можете настроить датчик живучести kubernetes, чтобы он остановил модуль при ошибке, возвращенной из этого четвертого контейнера.

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