Новая бета-функция RangeStream в связке с etcd 3.7 делает работу с большими коллекциями предсказуемой и экономит гигабайты оперативки.
Есть вещи, которые администраторы Kubernetes обсуждают вполголоса на ночных дежурствах — например, почему API-сервер после рестарта внезапно съедает полтораста гигабайт оперативки и падает с OOM. Причина часто прячется в старом добром механизме чтения данных из etcd: он умел буферизировать весь ответ целиком, прежде чем отправить хотя бы байт. В версии 1.37 разработчики наконец-то переписали этот сценарий, внедрив потоковую загрузку RangeStream. Вместе с новым etcd 3.7 это обещает сделать пиковое потребление памяти константным, а кластеры — заметно стабильнее. Рассказываем, как работает чудо-инженерная мысль и что нужно проверить, чтобы апгрейд не обернулся головной болью.
Крупные кластеры под контролем: что принесла бета-функция EtcdRangeStream
В крупных Kubernetes-кластерах голод API-сервера по оперативной памяти давно стал головной болью для всех, кто управляет тысячами подов. 26 августа 2026 года вышла версия 1.37, и с ней в бету перешла функциональность EtcdRangeStream. Включена она по умолчанию — и это, наконец, реальный шаг к тому, чтобы утихомирить прожорливого зверя, который раньше мог сожрать всю память при попытке просто прочитать список объектов.
Бета, которая лечит OOM
Раньше в экосистеме Kubernetes любая операция LIST в etcd превращалась в бомбу замедленного действия. API-сервер запрашивал у хранилища весь набор данных целиком, и тот честно буферизировал ответ, прежде чем отправить хотя бы байт. В кластере с десятками тысяч подов это означало, что один неосторожный запрос мог вызвать пиковое потребление памяти, которое валило сервер с ошибкой Out-Of-Memory. Инженерные команды просыпались по ночам от пейджеров — критический сбой контрольной плоскости, и всё из-за того, что кто-то запустил мониторинг с большим запросом.
Особенно остро проблема проявлялась при рестартах kube-apiserver, когда инициализация WatchCache выполняла пагинированные LIST-запросы по 10 тысяч объектов за раз. В известном тикете Kubernetes #115206 задокументирован случай, когда для запуска кластера требовалось до 150 гигабайт оперативной памяти. Не просто много — целый дата-центр ОЗУ уходил только на то, чтобы поднять control plane. С приходом EtcdRangeStream в Kubernetes v1.37 этот кошмар остаётся в прошлом. Функция заменяет унарный RPC-вызов на серверный стриминг, и API-сервер начинает получать данные порциями, не дожидаясь, пока etcd соберёт всё в одну кучу.
Попутный апгрейд для WatchCache
Но этим релиз не ограничивается. Вместе с EtcdRangeStream разработчики окончательно стабилизировали и заблокировали механизм ResilientWatchCacheInitialization. Эта штука, которая по умолчанию работала ещё с v1.36, теперь залочена намертво. Она предотвращает лавину запросов к etcd во время прогрева кэша после рестарта или восстановления API-сервера. Вместо того чтобы позволить дорогим list и watch-запросам перегрузить etcd или исчерпать ёмкость API Priority and Fairness, kube-apiserver теперь корректно обрабатывает ограниченные запросы, а остальные отклоняет с HTTP-кодом 429. Никаких всплесков трафика, никакого накапливания очередей — только спокойная, предсказуемая инициализация, даже на кластерах с гигантским количеством ресурсов.
Для администраторов, которые держат в руках оркестрацию на уровне enterprise, это значит, что теперь можно спать спокойнее. Не придётся пересматривать лимиты памяти для control plane каждую неделю и гадать, выдержит ли кластер очередное обновление. Новая бета-функция — это та самая «сантехника», без которой любой масштабный проект становится хрупким, но с которой Kubernetes окончательно утверждается в статусе промышленного стандарта.
Как потоковая загрузка из etcd снижает пиковое потребление памяти
Чтобы понять магию снижения памяти, нужно сначала заглянуть в то, как etcd работал раньше. До версии 3.7 любой запрос Range заставлял хранилище собирать весь ответ в оперативке, словно упаковывая гигантский чемодан, прежде чем отправить его получателю. Представьте: вы заказываете список из десяти тысяч подов, а etcd послушно складывает каждый объект в общую кучу, сериализует и только потом начинает передачу. Клиент тем временем ждёт — и память сервера плавно, но неуклонно заполняется до критической отметки.
От унитарного монолита к потоковому ручейку
Новшество Kubernetes в лице EtcdRangeStream — по сути, замена старого унитарного RPC-вызова на серверный стриминг. Сервер теперь не ждёт, пока соберётся всё множество, а режет ответ на чанки с адаптивным размером, подстраиваясь под величину значений. Каждый кусочек отправляется сразу, как только сформирован. Механизм при этом закреплён за одной ревизией MVCC — это гарантирует консистентность снапшота на протяжении всей передачи, независимо от того, сколько чанков будет отправлено.
Вместо того чтобы выполнять отдельный дорогостоящий обход B-tree для подсчёта общего числа объектов (а это ещё одна операция, жрущая ресурсы), система теперь ведёт накопительный счётчик прямо во время стриминга. Итоговое количество выводится из текущего подсчёта, без лишней нагрузки на индекс. Итог: пиковое потребление памяти перестаёт зависеть от размера результата. Оно становится константным и предсказуемым — как говорят разработчики, memory overhead becomes constant. Клиент получает первые данные мгновенно, а не после томительного ожидания, пока буфер заполнится доверху. Если раньше на кластере с 10 000 подов один LIST-запрос удерживал в RAM весь сериализованный ответ, то теперь в любой момент времени в памяти болтается только текущий чанк.
Бонус для тех, кто любит только ключи
Но и это не всё. etcd v3.7, на котором базируется улучшение, припасла дополнительный сюрприз для операторов. Запросы, которым нужны только ключи без значений (например, для проверок здоровья, поиска по индексу или инструментов инвентаризации), теперь читаются исключительно из индексной памяти in-memory, полностью минуя bbolt-бэкенд. Это означает, что даже до обращения к диску дело не доходит — существенный выигрыш для сценариев, где частенько прогоняют сканирование ключей. Вот вам, кстати, ответ на вопрос, что такое Kubernetes в контексте реальной оптимизации: это не просто оркестратор, а экосистема, где каждый новый релиз методично отпиливает острые углы, мешающие жить крупным кластерам.
Что нужно проверить администраторам при обновлении до etcd v3.7 и Kubernetes v1.37
Радость от новой потоковой загрузки может быстро померкнуть, если вы попытаетесь просто воткнуть etcd v3.7 в старый кластер. Релиз вышел 8 июля 2026 года, и он не прощает легкомыслия. Прежде чем обновлять свой кластер Etcd, вооружитесь списком критических изменений — иначе контрольная плоскость просто откажется стартовать.
Прощайте, экспериментальные флаги и v2
Первое, что ударит по глазам — полная чистка всех флагов с префиксом --experimental-*. etcd теперь живёт по правилам feature gate в стиле Kubernetes: альфа, бета, стабильно — и никаких самодеятельных экспериментальных опций. Если в ваших стартовых скриптах завалялся хоть один такой аргумент, процесс после апгрейда молча умрёт. Проверяйте конфиги немедленно.
Второй удар — окончательное прощание с v2 API. Поддержка v2 discovery, v2-запросов и v2-клиентов выпилена полностью. Вместе с ней удалена и легендарная v2store — та самая, что тащилась с самых первых дней третьей версии. Загрузка теперь идёт напрямую через v3store, и годы технического долга наконец-то списаны в утиль. Если в вашем инструментарии остались скрипты или кастомные тулы, говорящие на старом протоколе, — они сломаются с гарантией.
И не забудьте про образы. Теги вида etcd:v3.7.0-linux-amd64 больше не существуют. Переходите на мультиархитектурные manifest-образы — рантайм сам подберёт нужную архитектуру.
Адаптивная настройка и мониторинг
Даже после успешного обновления не стоит расслабляться. Для кластеров с гигантским количеством ресурсов (и особенно с крупными значениями объектов) может потребоваться дополнительная ручная настройка размеров чанков или пристальный мониторинг производительности. RangeStream адаптивен, но у всего есть пределы. Следите за метриками — и вовремя подкручивайте параметры.
В целом релиз Kubernetes v1.37, получивший имя Garhwal в честь гималайского региона, принёс 67 улучшений. Из них 23 перешли в бета-статус, включая долгожданный EtcdRangeStream. Это не просто цифры — они подтверждают, что экосистема взрослеет и целенаправленно решает реальные эксплуатационные муки крупных организаций. Так что готовьтесь к обновлению, но делайте это с холодной головой и горячим желанием перепроверить каждую строчку конфигов.
Когда в очередном релизе улучшают «сантехнику», это редко вызывает восторг у широкой публики. Но для тех, кто держит на своих плечах сотни узлов и тысячи подов, подобные изменения стоят на вес золота. EtcdRangeStream — как раз такой случай: он не добавляет новых фич, а убирает боль, которая годами копилась в крупных инсталляциях. Обновляйтесь, тестируйте, и пусть ваши API-серверы больше не просыпаются от голода.