Почему kubectl apply ещё не означает, что приложение заработало?
Во время деплоя часто запускают одну команду и считают её успешное завершение концом работы:
kubectl apply -f deployment.yaml
Но apply сообщает, что Kubernetes принял описание ресурса. Новые Pod могут ещё создаваться, скачивать образ, ждать readiness probe или падать при запуске.
После apply проверьте именно завершение обновления Deployment:
kubectl rollout status deployment/app --timeout=120s
Команда ждёт завершения rollout и возвращает ошибку, если не дождалась его за указанное время. Название app здесь должно совпадать с именем вашего Deployment.
В скрипте команды удобно поставить рядом:
set -e
kubectl apply -f deployment.yaml
kubectl rollout status deployment/app --timeout=120s
Теперь пайплайн не продолжит работу после неуспешного ожидания. Само по себе это всё ещё не заменяет проверку приложения снаружи кластера. Сервис, ingress и внешние зависимости могут ломаться отдельно.
Если обновление застряло, сначала посмотрите состояние ресурсов:
kubectl get deployment app
kubectl get pods -l app=app
Затем откройте события Deployment и причину проблемы у конкретного Pod:
kubectl describe deployment app
kubectl describe pod POD_NAME
Проблемой может оказаться неверный образ, недоступный секрет, ошибка readiness probe или нехватка ресурсов.
Предыдущую ревизию можно вернуть отдельно:
kubectl rollout undo deployment/app
После отката тоже проверьте rollout status.
➡️ DevOps Ready | #совет
Во время деплоя часто запускают одну команду и считают её успешное завершение концом работы:
kubectl apply -f deployment.yaml
Но apply сообщает, что Kubernetes принял описание ресурса. Новые Pod могут ещё создаваться, скачивать образ, ждать readiness probe или падать при запуске.
После apply проверьте именно завершение обновления Deployment:
kubectl rollout status deployment/app --timeout=120s
Команда ждёт завершения rollout и возвращает ошибку, если не дождалась его за указанное время. Название app здесь должно совпадать с именем вашего Deployment.
В скрипте команды удобно поставить рядом:
set -e
kubectl apply -f deployment.yaml
kubectl rollout status deployment/app --timeout=120s
Теперь пайплайн не продолжит работу после неуспешного ожидания. Само по себе это всё ещё не заменяет проверку приложения снаружи кластера. Сервис, ingress и внешние зависимости могут ломаться отдельно.
Если обновление застряло, сначала посмотрите состояние ресурсов:
kubectl get deployment app
kubectl get pods -l app=app
Затем откройте события Deployment и причину проблемы у конкретного Pod:
kubectl describe deployment app
kubectl describe pod POD_NAME
Проблемой может оказаться неверный образ, недоступный секрет, ошибка readiness probe или нехватка ресурсов.
Предыдущую ревизию можно вернуть отдельно:
kubectl rollout undo deployment/app
После отката тоже проверьте rollout status.
➡️ DevOps Ready | #совет