В CI/CD пайплайне деплой в Kubernetes часто занимает больше времени, чем ожидалось. Pod’ы создаются, но приложение не готово обслуживать трафик, и пользователи видят ошибки. Как вы будете искать и устранять проблему?
Проверю стратегию деплоя (например, RollingUpdate), наличие корректных readinessProbe и livenessProbe, а также настройки maxUnavailable и maxSurge. Проанализирую логи Pod’ов и события кластера. Для решения — настрою health-check’и, добавлю preStop hook для graceful shutdown и оптимизирую пайплайн так, чтобы трафик шёл только на готовые Pod’ы.
Библиотека собеса по DevOps
Библиотека собеса по DevOps
Какие стратегии деплоя поддерживает Kubernetes и когда ты применял каждую из них?
RollingUpdate — по умолчанию, постепенно заменяет поды без даунтайма (чаще всего применяю).
Recreate — останавливает все поды и потом поднимает новые (редко, если несовместимые изменения).
Blue/Green, Canary — через отдельные Deployment/Service или с помощью Istio/Argo Rollouts, использовал для тестирования новых фич с ограниченной аудиторией.
Библиотека собеса по DevOps
Recreate — останавливает все поды и потом поднимает новые (редко, если несовместимые изменения).
Blue/Green, Canary — через отдельные Deployment/Service или с помощью Istio/Argo Rollouts, использовал для тестирования новых фич с ограниченной аудиторией.
Библиотека собеса по DevOps
Что такое Immutable Infrastructure и какие преимущества она даёт?
Immutable Infrastructure — подход, при котором серверы/контейнеры не изменяются после деплоя: при апдейте создаётся новый инстанс, а старый удаляется.
Плюсы: предсказуемость окружений, отсутствие "дрейфа конфигурации", простота отката и высокая надёжность.
Библиотека собеса по DevOps
Плюсы: предсказуемость окружений, отсутствие "дрейфа конфигурации", простота отката и высокая надёжность.
Библиотека собеса по DevOps