Триаж: исчерпание пространства Pod-адресов в GKE
Исчерпание IP-адресов для подов (pod IP exhaustion) в GKE — один из немногих сценариев отказа, который не предупреждает вас перед тем, как ситуация становится критической. Недавно мне пришлось войти в «военную комнату», где основная группа масштабирования клиента полностью остановилась: рабочие нагрузки заблокированы (cordoned), развёртывания застряли в состоянии Pending, а предполагаемые потери от простоя приближались к $15 000 в час в виде недополученных транзакций. Виновником оказался не трафик. Это была подсеть /20, которая тихо исчерпала своё адресное пространство, — а дефолтные настройки выделения адресов в GKE никто не поставил под сомнение на этапе проектирования.
Математика «скрытого убийцы»
Именно здесь Облачная стратегия обычно рассыпается: неправильное проектирование VPC. GKE резервирует статический диапазон alias IP для подов на каждом узле. По умолчанию система рассчитана на 110 подов на узел. Чтобы удовлетворить этот запрос без фрагментации, GKE выделяет /24 (256 IP-адресов) каждому отдельному узлу — вне зависимости от того, запущено на нём 100 подов или всего один.
Вот почему /20 испарилась:
| Тип потерь | IP на узел (по умолчанию) | Ёмкость /20 (4096 IP) | Реальная картина |
|---|---|---|---|
Резервирование под поды |
256 (/24) |
Максимум 16 узлов |
Жёсткий потолок для всего VPC. |
Сервисы (ClusterIP) |
50 (статически) |
2–3% от общего числа |
Резервируются заранее. |
Буфер / фрагментация |
~100 |
Н/Д |
«Невидимые» издержки бин-пакинга. |
16 узлов. Это жёсткий предел.
В современной среде Modern Infra & IaC достигнуть 16 узлов во время пикового трафика — дело нескольких минут. Как только запрашивается 17-й узел, GKE не может подготовить для него инстанс Compute Engine: вторичный диапазон alias в VPC-native-режиме пуст.
Таксономия потерь
Большинство инженеров запускают kubectl top nodes, видят 40% загрузки CPU и считают, что запас ещё есть. Его нет. В облачных сетях адресное пространство — это жёсткое ограничение, точно так же как IOPS или тепловой предел.
Избыточное выделение ресурсов (Overprovisioning): клиент держал 3 пустых узла для «быстрого масштабирования». Итоговая цена: 768 IP-адресов заморожены и не делают абсолютно ничего. (Именно этот «налог на простой» является одной из главных причин создания нашего фреймворка K8s Exit Strategy.)
Фрагментация CIDR: из-за того, что вторичные диапазоны не были рассчитаны на несмежный рост, мы не могли просто добавить новый диапазон к существующей подсети.
«Теневые» узлы: заброшенные пулы узлов, которые не были полностью удалены, по-прежнему удерживали аренду своих блоков /24.
Последствия инцидента
Результатом стал не просто «запрет на новые поды» — произошёл каскадный сбой:
-
HPA (горизонтальный автомасштабировщик подов) запускал события увеличения масштаба, которые немедленно завершались ошибкой.
-
Критические патчи не могли быть развёрнуты, потому что для скользящих обновлений не было «резервного» пространства.
-
Нестабильность сервисов: стандартные Kubernetes-сервисы начали «флапать», поскольку
kube-proxyиспытывал затруднения с неполными наборами конечных точек (endpoint sets).
«Ядерный вариант» против настоящей инженерии
Стандартный сценарий устранения исчерпания IP-адресов подов в GKE предполагает полное пересоздание VPC: снести всё, подготовить /16 и перенести данные. Это гарантирует решение проблемы, но является грубой силой, которая несёт колоссальные риски: проблемы с распространением DNS, простой и недели тестирования.
Мы не пересоздавали VPC и не сносили проект. Мы использовали пространство Class E (240.0.0.0/4) — «зарезервированный» и в основном забытый угол карты IPv4, который большинство вендоров делают вид, что не существует. Мы разблокировали миллионы IP-адресов, не переводя ни одну рабочую нагрузку в офлайн.
Документация по точным командам gcloud и корректировкам маршрутизации, которые мы использовали, готовится к публикации.
Часть 2: Руководство по спасению с помощью Class E
Вердикт архитектора
Исчерпание IP-адресов подов в GKE — это не сетевой сбой. Это сбой планирования ёмкости, который диагностируется как сетевой сбой в самый неподходящий момент. Дефолтная подсеть /20 кажется щедрой — ровно до тех пор, пока не понимаешь, что GKE резервирует /24 на каждый узел вне зависимости от плотности подов. А это значит: 16 узлов и жёсткий потолок, а не просто подсеть.
Применённое решение оказалось нестандартным. Пространство Class E — не то, за чем большинство архитекторов тянутся в стрессовой ситуации, и оно поддерживается не всеми инструментами и вендорами. Но альтернативой было пересоздание VPC прямо в ходе инцидента, что несёт больше рисков, чем устраняет. Главный урок здесь — не в Class E как таковом. Он в том, что адресное пространство необходимо моделировать на этапе проектирования точно так же, как моделируются IOPS или пропускная способность. Это жёсткое ограничение, а не мягкое. К тому моменту, когда HPA начинает запускать события масштабирования в пустой диапазон, архитектурное решение, ставшее причиной этого, было принято недели или месяцы назад.