Amazon EKS разрешил откатывать Kubernetes на предыдущую минорную версию в течение 7 дней после обновления. Для команд, которые обновляют кластеры с длинными окнами наблюдения и запасным планом на случай сбоя, это редкая страховка: обновление управляющей плоскости перестает быть дорогой только вперед.
AWS объявила о функции 1 июля 2026 года. Откат доступен без доплаты во всех коммерческих регионах AWS, где работает EKS, и запускается через консоль, CLI или SDK.
Откат работает только в четких границах
EKS возвращает кластер только на предыдущую минорную версию Kubernetes и только если после обновления прошло не больше семи дней. Если кластер уже успели обновить еще раз, вернуться на две версии назад не получится. Еще одно ограничение: откат не сработает для кластера, который изначально создали на текущей версии, и для части сценариев с extended support.
Речь идет прежде всего об управляющей плоскости: AWS откатывает API-сервер и связанные компоненты, сохраняя данные в etcd, рабочие нагрузки и постоянные тома. Для EKS Auto Mode сервис перед этим сам возвращает рабочие узлы с учетом PodDisruptionBudget. В обычных кластерах группы узлов, дополнения и сторонние контроллеры остаются зоной ответственности клиента.
AWS добавила проверки перед возвратом
Перед откатом EKS запускает проверки готовности к откату: сервис оценивает совместимость API, расхождение версий kubelet и kube-proxy, состояние дополнений и общее здоровье кластера. Если находит блокирующую проблему, операция останавливается. Обойти эти проверки можно через параметр --force, но жесткие ограничения он не снимает: окно в 7 дней и другие базовые условия остаются.
Здесь есть важная оговорка, которую легко потерять в заголовках. Если команда уже успела развернуть ресурсы, завязанные на новые API или поведение новой версии Kubernetes, сам откат не гарантирует, что приложение сразу вернется в стабильное состояние. AWS прямо пишет: совместимость приложений, конфигураций и зависимостей остается на стороне пользователя.
Почему это важно для платформенных команд
Kubernetes выпускает три минорные версии в год, а откладывать обновления бесконечно нельзя: старые ветки уходят из стандартной поддержки, а дальше начинаются либо ручные компромиссы, либо доплата за extended support. До сих пор у многих команд обновление EKS было операцией с высоким штрафом за ошибку. Отсюда длинные волны обновления, лишние согласования и любовь к миграциям через новый кластер даже там, где это больше про страх, чем про архитектуру.
Для русскоязычной аудитории новость практичная. Появляется еще один аргумент обновлять Kubernetes по графику, а не в последний момент перед окончанием поддержки. Для стартапов это экономия времени платформенной команды. Для крупных компаний это шанс сократить число ручных проверок и быстрее раскатывать версии без отдельного кластера «на всякий случай».
Источники и контекст
Первоисточник: AWS What's New. Технические детали: документация Amazon EKS и AWS News Blog.
Если другие managed Kubernetes-сервисы быстро подтянут такую же страховку, конкуренция сместится с самого факта «у нас есть Kubernetes» к качеству его повседневной эксплуатации.