Я унаследовал приложение, которое мне нужно развернуть внутри кластера как постоянный pod, чтобы иметь доступ к другим ресурсам, но которое запускается только по требованию, когда пользователь kubectl execвходит в pod. При инициализации мне не нужно, чтобы оно делало что-либо вообще, кроме как делало pod доступным для пользователя, чтобы он мог execвойти в него позже.
Это прекрасно работает на нашем старом кластере Jenkins-X 2, но новая версия Jenkinx-X 3 никуда не денется.
При развертывании статус, по-видимому, проходит через жизненный цикл
Running
Completed
CrashLoopBackOff
Однако kubectl logs -n <<namespace>> <<podname>> -pошибок не показывает, и в kubectl describe pod -n <<namespace>> <<podname>>разделе Containers/<<appname>>есть
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
Что выглядит непоследовательно — я не понимаю, как это могло произойти, CrashLoopBackoffесли последнее состояние — Terminatedbecause Completed, а второе Exit Code— 0. Насколько я понимаю, приложение не дает сбой, просто Kubernetes завершает работу модуля как завершенную, а не оставляет его запущенным, и затем он каким-то образом застревает в CrashLoopBackoff.
Я задавался вопросом, связано ли это с проверками готовности или жизнеспособности, которые убивают его из-за того, что не находят постоянно работающий процесс для обслуживания запроса, но их удаление или возврат к более старым версиям, похоже, не дает никакого результата.
Вероятно, что-то пошло не так в графиках между старой и новой версиями, но у меня заканчиваются идеи, где искать. Есть ли что-то, что люди могут предложить, что может быть причиной этого?