Под у Kubernetes у статусі CrashLoopBackOff — з чого почати діагностику?

Question

Задеплоїв новий сервіс на FastAPI в кластер, kubectl get pods показує:

NAME                        READY   STATUS             RESTARTS      AGE
orders-api-6c9d8f7b4-k2x9q  0/1     CrashLoopBackOff   6 (40s ago)   7m

Локально в Docker той самий образ працює. kubectl logs показує порожнечу або обрізаний рядок. Куди дивитися?

Максим Ткаченко · Accepted Answer

CrashLoopBackOff — це не причина, а симптом: контейнер запускається, завершується, і Kubernetes перезапускає його з зростаючою паузою. Порядок дій:

1. Логи попереднього запуску — поточний контейнер міг ще нічого не встигнути написати:

kubectl logs orders-api-6c9d8f7b4-k2x9q --previous

2. Події й код завершення:

kubectl describe pod orders-api-6c9d8f7b4-k2x9q

Дивіться розділ Last State і Events:

Що бачите	Імовірна причина
`Reason: OOMKilled`, `Exit Code: 137`	Не вистачає memory limit
`Exit Code: 1`	Застосунок упав сам — дивіться логи
`Exit Code: 127` / `exec format error`	Немає команди в образі або образ зібрано під іншу архітектуру (arm64 vs amd64)
`Liveness probe failed`	Проба перезапускає контейнер: неправильний шлях/порт або занадто короткий час на старт
`CreateContainerConfigError`	Немає Secret або ConfigMap, на який посилається под

3. Типові відмінності від локального запуску:

немає змінної середовища, яка локально береться з .env;
застосунок слухає 127.0.0.1 замість 0.0.0.0 — проби не можуть достукатись;
немає доступу до бази з кластера (NetworkPolicy, неправильний хост);
файлова система readOnlyRootFilesystem: true, а застосунок пише в /tmp без змонтованого emptyDir.

4. Запустити под без перезапусків і подивитися зсередини:

kubectl debug orders-api-6c9d8f7b4-k2x9q -it --copy-to=debug-orders --container=api -- sh

Якщо в образі немає shell (distroless) — додайте ефемерний контейнер з інструментами: kubectl debug -it <pod> --image=busybox --target=api.

Юрій Савчук · Answer

Ще один частий випадок саме з FastAPI/uvicorn: startupProbe немає, а livenessProbe починається через 5 секунд. Поки застосунок прогріває моделі чи пул з'єднань, проба падає — і Kubernetes вбиває контейнер раніше, ніж він встигає стартувати. У логах при цьому чисто.

Додайте startupProbe з запасом часу на старт — і liveness почне працювати лише після успішного старту.

Под у Kubernetes у статусі CrashLoopBackOff — з чого почати діагностику?

2 відповіді

Знаєте відповідь?