AWS сформулировала набор практик для Amazon EKS, опираясь на эксплуатацию Kubernetes в масштабе миллионов кластеров. Главный вывод звучит неприятно, но честно: сбой зоны доступности редко ломает систему сам по себе, чаще бизнес подводит неподготовленная архитектура, где кластер вроде бы растянут на несколько AZ, но реально не готов потерять ни одну из них.
Об этом сообщает The New Stack. В центре внимания механизм ARC zonal shift для EKS: при деградации одной Availability Zone AWS может временно увести трафик из проблемной зоны, а в режиме zonal autoshift сделать это автоматически. Для русскоязычной аудитории здесь важен не столько сам сервис AWS, сколько практический урок для любой Kubernetes-инфраструктуры: multi-AZ без запаса по емкости, разнесения реплик и адекватного DNS — это не отказоустойчивость, а дорогая иллюзия.
Технически схема выглядит довольно приземленно, без магии. Во время zonal shift узлы в проблемной зоне переводятся в состояние cordon, чтобы Kubernetes Scheduler не ставил туда новые Pod. Если используются Managed Node Groups, AWS приостанавливает перебалансировку по зонам доступности и настраивает Auto Scaling так, чтобы новые data plane-узлы запускались только в здоровых AZ. При этом сами узлы в сбойной зоне не уничтожаются, а Pod с них не выселяются. Логика простая: когда проблема уйдет или shift отменят, трафик можно будет вернуть без лишней пересборки среды.
Самый важный момент происходит на сетевом уровне. Контроллер EndpointSlice находит endpoint’ы Pod в проблемной зоне и убирает их из соответствующих EndpointSlice. Для восточно-западного трафика внутри кластера это означает, что kube-proxy перестает направлять запросы к этим Pod. Если в кластере есть внешние точки входа через ALB или NLB, ingress-трафик тоже начинает идти только в здоровые зоны. И вот здесь хорошо видно, чему AWS научилась на большом масштабе: формально живые ноды и Pod еще не означают, что к ним нужно продолжать слать запросы. Иногда правильнее признать зону временно «не для работы» и быстро сузить маршрут.
Но сама AWS довольно недвусмысленно говорит: handling не спасет, если кластер был собран без запаса прочности. В рекомендациях для EKS перечислены базовые вещи, которые многие команды знают, но не всегда делают. Во-первых, worker nodes должны быть распределены по нескольким AZ. Во-вторых, в кластере нужно держать достаточно вычислительной емкости, чтобы пережить потерю одной зоны без судорожного дозапуска инфраструктуры. Если все узлы загружены под потолок, то после выпадения AZ вы теряете не только часть ресурсов, но и время на то, чтобы срочно нарастить capacity в оставшихся зонах. Для пользовательского сервиса это как раз тот случай, когда отказ вроде бы локальный, а деградация ощущается везде.
Отдельный акцент AWS делает на репликах и распределении Pod. Для рабочих нагрузок советуют заранее запускать несколько реплик и размазывать их по зонам через topology spread constraints. В документации EKS приводится пример Deployment с девятью репликами и правилом maxSkew: 1 по ключу topology.kubernetes.io/zone. Идея не новая, но на практике многие команды до сих пор надеются на «авось scheduler сам разберется». Не разберется так, как нужно бизнесу в момент аварии. Если реплики уже сидят в здоровых AZ, всплеск нагрузки после отключения одной зоны переживается заметно спокойнее.
Еще один недооцененный кусок — DNS. AWS отдельно подчеркивает, что CoreDNS тоже нужно масштабировать и распределять по зонам, иначе сбой зоны доступности быстро превращается в историю не только про compute, но и про service discovery. Для CoreDNS EKS предлагает настройки по умолчанию, которые стараются разнести Pod по AZ, если узлы действительно есть в нескольких зонах. При установке через Helm AWS рекомендует явно выставлять число реплик и topology spread constraints, а при необходимости подключать autoscaling. Это важное уточнение для всех, кто любит считать отказоустойчивость только по приложению, игнорируя системные компоненты кластера. Когда DNS становится узким горлом, красивый multi-AZ-дизайн заканчивается очень быстро.
Есть и более тонкий слой — размещение связанных сервисов. Если один набор Pod аккуратно распределен между AZ, а второй критически важный сервис целиком живет в одной зоне, end-to-end процесс все равно развалится. Поэтому AWS советует совмещать spread constraints с pod affinity, чтобы зависимые приложения не только были размазаны по отказовым доменам, но и оставались логично скоординированы между собой. Это уже разговор не про «галочку за высокую доступность», а про внятную карту зависимостей внутри микросервисной системы. Для продактов и техдиректоров смысл понятен: отказоустойчивость стоит оценивать не по отдельным Deployment, а по способности бизнес-сценария пережить потерю зоны целиком.
Для рынка это еще один сигнал, что эпоха наивного multi-cloud и multi-AZ-маркетинга заканчивается. Клиентам все чаще нужны не абстрактные обещания аптайма, а понятные механизмы управляемого отказа: как быстро исключается проблемная зона, что происходит с трафиком, кто отвечает за DNS, сколько запаса мощности реально заложено. В этом смысле опыт AWS интересен не только пользователям EKS. Любая команда, которая гоняет Kubernetes в проде, рано или поздно упрется в тот же вопрос: готова ли ее платформа к тому, что одна зона исчезнет не на бумаге, а посреди рабочего дня. И чем раньше на этот вопрос появится инженерный, а не маркетинговый ответ, тем меньше будет сюрпризов в следующем инциденте.