Deployment — объект управления экземплярами и их историей. RollingUpdate — одна из его стратегий замены. Даже правильно рассчитанная стратегия не проверяет бизнес-операции приложения.
Практический смысл
Почему это важно
Deployment помогает заменить экземпляры, но не проверяет бизнес-операции за вас. До выпуска задайте готовность, ресурсы перехода, срок ожидания и условие остановки. Отдельно спланируйте изменения данных: возврат шаблона Pod не возвращает схему внешней базы.
Доказательная часть
Что подтверждено
Контроллер Deployment создаёт и масштабирует ReplicaSet, чтобы поддерживать требуемое число Pod и менять версии их шаблона.
Граница применимости: Управление нагрузкой через Deployment Kubernetes.
Завершённое обновление и доступные экземпляры подтверждают условия контроллера. Они не проверяют правильность пользовательской операции или совместимость новой версии с внешними данными.
Граница применимости: Состояние Deployment и границы проверок приложения.
Новая ревизия Deployment появляется при изменении шаблона Pod. Простое изменение числа экземпляров не создаёт новую ревизию шаблона.
Граница применимости: Триггер обновления и история ревизий Deployment Kubernetes.
Параметр minReadySeconds задаёт, сколько времени новый Pod должен оставаться готовым без сбоев контейнеров, чтобы считаться доступным. Мгновенный успех readiness ещё не доказывает выполнение этого условия.
Граница применимости: Учёт доступности новых Pod в Deployment Kubernetes.
Истечение progressDeadlineSeconds сообщает о недостаточном ходе обновления Deployment, но само по себе не запускает откат. Нужен отдельный порядок действий оператора или системы выпуска; ожидание контроллера не вернёт прежнюю версию автоматически.
Граница применимости: Условие ProgressDeadlineExceeded в Deployment Kubernetes; внешняя автоматизация не предполагается.
Штатный откат Deployment возвращает шаблон Pod к сохранённой ревизии. Он не восстанавливает внешнюю базу данных и не возвращает отдельно изменённую конфигурацию приложения.
Граница применимости: Граница операции отката Deployment Kubernetes.
История Deployment хранится в управляемых ReplicaSet. Параметр revisionHistoryLimit задаёт число сохраняемых старых ReplicaSet, а не срок в днях. Если нужная ревизия удалена при очистке истории, штатный откат к ней недоступен.
Граница применимости: История ревизий и revisionHistoryLimit Deployment Kubernetes.
Граница терминов
Не путать
Перед спецификацией
Что проверить
- Зафиксируйте дайджест образа и полный шаблон Pod принятого выпуска.
- Проверьте селектор и отсутствие пересечения с другими контроллерами нагрузки.
- Задайте число экземпляров, стратегию обновления и необходимый запас ресурсов.
- Проверьте readiness и время устойчивой готовности minReadySeconds.
- Укажите срок ожидания и действие при ProgressDeadlineExceeded.
- Настройте число сохраняемых ревизий с учётом частоты выпусков и сохраните нужные образы.
- Проверьте совместимость старого приложения с данными после изменения схемы.
- Принимайте выпуск по пользовательским операциям, а не только по статусу контроллера.
Открытые основания
Первоисточники
Deployments
Kubernetes · Kubernetes current documentation
Описывает управление ReplicaSet, стратегии обновления, параметры maxUnavailable и maxSurge, ход выпуска и историю для отката.
Открыть первоисточникLiveness, Readiness, and Startup Probes
Kubernetes · Kubernetes current documentation
Разделяет проверки готовности, работоспособности и запуска. Объясняет их действия и риск каскадного отказа при неверной настройке.
Открыть первоисточникConfigMaps
Kubernetes · документация Kubernetes v1.37, страница открыта 6 сентября 2026 года
Открыт редактором 6 сентября 2026 года, заголовок и версия документа сверены. Внешняя конфигурация; различия переменных окружения, томов и подключений subPath.
Открыть первоисточник