Я унаследовал приложение, которое мне нужно развернуть внутри кластера в качестве постоянного модуля, чтобы иметь доступ к другим ресурсам, но которое запускается только по требованию, когда пользователь kubectl execs в стручок. При инициализации мне не нужно ничего делать, кроме как сделать модуль доступным для пользователя. исполнитель в более поздний срок.
Это прекрасно работает на нашем старом кластере Jenkins-X 2, но новая версия Jenkinx-X 3 никуда не годится.
Когда он развернут, статус проходит через жизненный цикл
Бег
Завершенный
CrashLoopBackOff
Однако журналы kubectl -n <<namespace>> <<podname>> -p не показывает ошибок, а в kubectl описать pod -n <<namespace>> <<podname>> в Контейнеры/<<имя_приложения>> раздел включает
Состояние: Ожидание
Причина: CrashLoopBackOff
Последнее состояние: прекращено
Причина: Завершено
Код выхода: 0
Что выглядит непоследовательно - я не понимаю, как это попало в CrashLoopBackoff с последним состоянием Прекращено так как Завершенный и Код выхода из 0 — приложение, насколько я вижу, не дает сбоев, просто Kubernetes закрывает модуль как завершенный, а не оставляет его работающим, а затем каким-то образом застревает в CrashLoopBackoff.
Я задавался вопросом, было ли это как-то связано с проверками готовности или живучести, убивающими его из-за того, что не было найдено постоянно работающий процесс для обслуживания запроса, но их удаление или возврат к более старым версиям, похоже, не имеет никакого значения.
Предположительно что-то пошло не так в диаграммах между старой и новой версиями, но у меня заканчиваются идеи, где искать. Есть ли что-нибудь, что люди могут предположить, что может быть причиной этого?
