Ответ
На моей предыдущей позиции DevOps-инженера произошёл инцидент во время планового обновления production-кластера Kubernetes. Я использовал kubectl apply с манифестом, содержащим ошибку в селекторе selector для Deployment, что привело к созданию нового ReplicaSet, который не мог найти поды по старой метке. В результате сервис стал недоступен.
Что пошло не так:
- Не было выполнено
kubectl diff -f deployment.yamlдля предварительной проверки изменений. - Пропущен этап rollout в staging-окружении с той же конфигурацией.
- Отсутствовал готовый и проверенный план отката (rollback).
Как исправили: Пришлось вручную откатываться, выполняя kubectl rollout undo deployment/<name>. Простой составил около 15 минут.
Выводы и внедрённые практики:
- Обязательный dry-run и diff: Теперь всегда выполняю
kubectl apply --dry-run=client -f file.yamlиkubectl diff. - Канареечные деплои и автоматические откаты: Настроили прогрессивные деплои (canary releases) через Istio и автоматический откат при превышении порога ошибок.
- Чек-лист для деплоя: Внедрили чек-лист, включающий проверку бэкапов (если задействованы StatefulSet), лимитов ресурсов и readiness-проб.
Пример скрипта предварительной проверки, который теперь используем:
#!/bin/bash
# Преддеплойная проверка
MANIFEST="deployment.yaml"
echo "[1/3] Running kubeval..."
kubeval $MANIFEST || exit 1
echo "[2/3] Running kubectl diff..."
kubectl diff -f $MANIFEST --context=staging
echo "[3/3] Dry-run apply..."
kubectl apply -f $MANIFEST --dry-run=client --context=staging || exit 1