Почему Weave Net в Kubernetes теряет пакеты при масштабировании
На десяти-пятнадцати узлах кластер ведёт себя предсказуемо, а после перехода через несколько десятков начинают «моргать» сервисы. Часть TCP-сессий обрывается на середине, отдельные SYN не доходят до пода, межсервисные вызовы падают по таймауту — при этом метрики узлов чистые, а сами поды живы. Потеря пакетов в кластере выглядит как случайный шум: воспроизводится не на всех парах узлов и не каждый раз.
Причина обычно складывается из трёх слоёв. Первый — инкапсуляция: оверлей заворачивает трафик в собственный заголовок, эффективный MTU интерфейса падает, и крупные пакеты с запретом фрагментации тихо теряются на туннеле. Второй — обмен топологией: с ростом числа узлов агенты дольше сходятся к согласованной картине маршрутов, и в окне сходимости часть путей ведёт в никуда. Третий — NetworkPolicy с неверным селектором: трафик отбрасывается без единой записи в логах приложения.
Сбои связности оверлея неприятны тем, что диагностика сети кластера упирается в отсутствие схемы. Инженер видит обрезанные пакеты на одном узле, но не понимает, где именно теряется путь: на выходе из пода, на туннеле между узлами или уже на приёмнике. Нет карты подсетей, адресации подов и сервисов, нет списка перекрывающихся диапазонов — и расследование превращается в перебор гипотез прямо на живом кластере.
Поэтому начинаем не с правки конфигурации, а с восстановления картины сети — разбираем, как это закрывается.
Что даёт оверлейная сеть кластера: измеримый эффект
Оверлейная сеть кластера задаёт два измеримых параметра: время восстановления узла и долю потерянных запросов при перестроении маршрутов. Пока сеть собрана из разрозненных настроек, каждая новая нода или переезд пода даёт всплеск ошибок — потери считаются процентами, а не десятыми долями.
Мы разворачиваем Weave Net как единый сетевой слой: адресация, маршрутизация между узлами и правила доступа живут в одной конфигурации, а не в трёх разных местах. Замеры снимаем на тестовом контуре до и после внедрения — на них и строим выводы.
Шифрование трафика между узлами без потери скорости
Шифрование трафика между узлами включается на уровне сети: приложение о нём не знает и доработок не требует. Перед включением прогоняем нагрузочный сценарий и сравниваем пропускную способность — при корректных настройках просадка остаётся в пределах погрешности замера, а трафик между нодами больше не ходит открытым текстом.
Предсказуемое восстановление после отказа узла
Падение узла перестаёт быть событием с неопределённым исходом: маршруты перестраиваются за секунды, поды переезжают на живые ноды, доля потерянных запросов остаётся в десятых долях процента. Заодно уходит целый класс отказов — когда после перезапуска часть трафика уходит в никуда и сервис формально поднят, но отвечает ошибками.
Проверяем это не на словах: гасим ноду под нагрузкой, смотрим время восстановления и потери, отдельно убеждаемся, что правила доступа не пропускают лишний трафик. Если цифры расходятся с ожидаемыми — правим настройки, а не отчёт.
Режимы работы оверлейной сети: сравнение вариантов
Выбор режима определяет, как пакеты ходят между узлами и сколько ресурсов уходит на каждый новый узел. Оверлей поверх сети узлов инкапсулирует трафик, прямой режим отдаёт маршрутизацию ядру, гибрид сочетает оба. Ниже — сравнение по двум осям: когда вариант подходит и чем он ограничивает.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Оверлей поверх сети узлов | Кластер в облаке или в нескольких подсетях, где прямой маршрут между узлами недоступен | Инкапсуляция забирает часть полосы, предельный размер пакета ниже — крупные пакеты фрагментируются |
| Прямой маршрутизируемый режим | Один домен связности или управляемая сеть, где узлы видят друг друга напрямую | Зависит от политики сети: смена подсети или фильтры ломают маршруты между узлами |
| Гибрид | Смешанная инфраструктура: часть узлов в облаке, часть на своём железе | Конфигурация сложнее, отказы нужно размечать отдельно по каждой подсети |
Когда оверлей оправдан
Оверлей включают, когда узлы живут в разных подсетях и сеть не даёт анонсировать маршруты между ними. Weave Net в этом режиме закрывает связность и шифрование трафика, а сетевые политики описываются одинаково для любого варианта — смена режима не требует переписывать правила заново.
Ограничения на реальной нагрузке
На потоковых задачах инкапсуляция заметна по времени отклика, поэтому базу данных и шину событий чаще выносят в прямой режим. Но ошибка в маршрутах там приводит к тому, что часть узлов перестаёт видеть друг друга. Поэтому оба профиля прогоняем на тестовом контуре с боевым характером трафика до переключения.
Порядок развёртывания: от аудита сети до передачи
Развёртывание начинается не с установки, а с аудита сети кластера: какие диапазоны адресов заняты, как устроена маршрутизация между узлами, где проходят границы доверия. Ошибка здесь всплывает позже — часть подов не видит сервисы, а диагностика растягивается на дни. Поэтому шесть этапов идут строго по порядку, и каждый заканчивается проверяемым результатом.
Что проверяем на входе
Собираем карту кластера: занятые и свободные диапазоны, пересечения с сетями офиса и облачных площадок, действующие правила доступа между сервисами. Фиксируем, какие пространства имён остаются изолированными и у кого есть права менять сетевую конфигурацию.
- Аудит сети кластера — инвентаризация узлов, диапазонов и маршрутов, поиск пересечений с существующей инфраструктурой.
- Схема адресации — пул адресов для подов и служебных сервисов, план по пространствам имён.
- Установка и настройка шифрования — развёртывание Weave Net в кластере, включение шифрования трафика между узлами, порядок ротации ключей.
- Политики доступа — разрешённые связи между сервисами и запрет по умолчанию для чувствительных пространств имён.
- Проверка связности под нагрузкой — тесты между узлами и площадками, поведение при падении узла, замер задержек.
- Обучение команды и передача — разбор конфигураций, схем и сценариев диагностики.
Критерии готовности к передаче
Передача возможна, когда трафик между узлами зашифрован, политики применяются ко всем нужным сервисам, а восстановление узла проверено на практике. У команды остаются схема адресации, инструкции по типовым сбоям и порядок изменений.
Комплект передачи: конфигурации, схемы, регламенты
Работающий кластер и кластер, который можно передать на сопровождение, — не одно и то же. Поэтому сдача — это не демонстрация запущенных контейнеров, а комплект документации, по которому ваша команда развернёт стенд с нуля, расширит сеть и разберёт отказ без нас.
Что входит в комплект
- Конфигурации сети: манифесты установки, параметры оверлея и значения, вынесенные в отдельные файлы, — развёртка стенда повторяется один в один.
- Карта адресации: диапазоны подов и сервисов, адреса узлов, занятые подсети — при расширении кластера не конфликтуем с корпоративной сетью.
- Политики доступа: какие пространства имён и сервисы кому доступны, на каких портах, какой трафик шифруется между узлами.
- Схема прохождения трафика: путь пакета от пода до пода, точки шифрования и узлы, где снимается диагностика.
- Регламент обслуживания: плановые обновления узлов, порядок вывода узла на профилактику, ротация ключей шифрования.
- Порядок действий при отказе: сценарии на обрыв связи между узлами, деградацию оверлея и потерю узла — с командами проверки на каждом шаге.
- Чек-лист приёмки: набор проверок перед каждым релизом, чтобы изменение конфигурации не ломало связность.
Регламенты под типовые инциденты
Отдельно фиксируем, кто и что делает при сбое: где смотреть метрики, как изолировать проблемный узел, в какой момент откатывать конфигурацию к предыдущей версии. Регламент обслуживания закрывает плановые работы, а порядок действий при отказе — внеплановые, поэтому дежурный инженер не ищет решение с нуля.
Кейс: кластерная сеть под нагрузкой до и после
Исходное состояние и ограничения
Кластер из нескольких десятков узлов собирали поэтапно, и сеть за ним не успевала: часть трафика шла напрямую по L2, часть — через самописную оверлейную надстройку. Шифрование между узлами было выключено, разграничение доступа держалось на подсетях и ручных правилах фаервола, а рассинхрон MTU на разных интерфейсах давал потери пакетов. В часы пик связность проседала: сервисы переподключались, часть запросов завершалась таймаутами, а дежурный не мог быстро отделить сетевую проблему от прикладной.
Результат в метриках до и после
Развернули Weave Net с шифрованием трафика между узлами, выровняли MTU на всех интерфейсах и перенесли сегментацию в декларативные политики доступа. Дополнительно вывели метрики связности, чтобы деградация была видна до того, как её заметят пользователи.
| Метрика | До | После |
|---|---|---|
| Потери пакетов между узлами в часы пик | 8-12% | 0.1% |
| Разбор инцидента со связностью | около 5 часов | около 35 минут |
| Инциденты без понятной причины | 40% | 5% |
| Ввод нового узла в сеть | 40 минут вручную | 3 минуты автоматически |
Связность перестала быть источником случайных отказов, а регламент разбора свёлся к трём шагам: метрики оверлея, состояние каналов между узлами, срабатывание политик. Дежурные перестали эскалировать сетевые вопросы наугад, и нагрузка на команду сопровождения при том же объёме трафика выровнялась.
Что делать, если в Kubernetes уже работает другой сетевой модуль
Перейти можно, но «в лоб» — снести один модуль и поставить другой — не получится. На время смены сетевого модуля поды теряют адреса, а вместе с объектами старого модуля исчезают и сетевые политики. Поэтому переход ведут поэтапно: рядом поднимают новый модуль, переносят правила и только затем снимают старый.
Первым шагом идёт инвентаризация того, что реально работает в кластере. Смотрят, какие сетевые политики применяются (часть объектов обычно оказывается черновиками), есть ли поды с прямой привязкой к сети узла, пересекаются ли диапазоны адресов старого и нового модулей. Пересечение подсетей и несовпадение режима маршрутизации — самая частая причина, по которой смена сетевого модуля требует ручной правки, а не простой замены.
Совместимость модулей сети проверяют до перехода, а не во время. Новый модуль ставят в режиме, где он видит узлы и читает состояние кластера, но адреса не выдаёт — маршрутизация остаётся прежней. Ошибка на этом этапе стоит одного узла, а не всего кластера.
Сетевые политики переносят отдельно: селекторы и правила у модулей различаются, и политика, которая раньше блокировала трафик, в новом модуле может трактоваться иначе. Каждое правило проверяют на тестовом окружении, и только когда сервисы отвечают, старые объекты удаляют.
Переход без простоя делают поузлово: узел выводят из обслуживания, переключают, проверяют связность и возвращают в кластер. Нужен запас ёмкости — кластер должен переживать потерю одного узла. Конфигурацию старого модуля держат зафиксированной как план отката и снимают только после того, как все проверки пройдены.
Частые технические сомнения по оверлейной сети
Сомнения по оверлейной сети Weave Net в кластере обычно всплывают не на установке, а в эксплуатации: как она ведёт себя под нагрузкой, что произойдёт при потере узла, чем обернётся включение шифрования. Ниже — то, что наши инженеры проверяют на стенде перед выводом кластера в рабочую эксплуатацию.
Насколько инкапсуляция добавляет задержку между сервисами?
Инкапсуляция добавляет заголовок к каждому пакету, и часть пути проходит вне обычного стека ядра, поэтому задержка растёт. На типичных веб-нагрузках это доли миллисекунды, но при частом обмене мелкими запросами разница становится заметной. Мы замеряем задержку до и после включения оверлея и оставляем прямые маршруты там, где узлы стоят в одной подсети.
Как включается шифрование и что оно меняет?
Шифрование включается на уровне оверлея и закрывает весь трафик между узлами, включая служебный. Цена — дополнительная нагрузка на процессор и падение пропускной способности на крупных потоках. Поэтому включаем выборочно: для сред, где трафик идёт через недоверенные сегменты, и всегда со снятием замеров до и после.
Что происходит при отказе узла?
Оставшиеся узлы перестраивают маршруты к потерянным подсетям, а контроллеры пересоздают поды на живых машинах. Время восстановления складывается из таймаутов проверок и времени запуска контейнеров — мы измеряем его и фиксируем как целевой показатель, чтобы деградация была предсказуемой, а не случайной.
Можно ли сменить адресацию подсетей на живом кластере?
Диапазон адресов меняют поэтапно: сначала поднимают новый пул, затем переносят на него узлы по одному, проверяя связность после каждого шага. Полная смена адресации с пересозданием кластера проще и предсказуемее — выбор зависит от того, сколько сервисов завязаны на старые адреса.
Как диагностировать проблемы сети?
Идём от простого к сложному: связность между подами на разных узлах, состояние сетевого агента на каждой машине, счётчики отброшенных пакетов, затем правила доступа между пространствами имён. Так проблема оверлея отделяется от ошибок в конфигурации сервисов и политиках.
Обсудим задачу: подберём режим и вернёмся с планом
Чтобы оценка была предметной, а не «по фотографии», на первом разговоре хватает вводных по кластеру: сколько узлов и в каких подсетях, какой сетевой слой работает сейчас, есть ли ограничения на простой и кто владеет маршрутами между сегментами. Доступы «на всякий случай» не нужны — достаточно описания и текущих манифестов.
По итогам разговора возвращаемся с оценкой и планом работ:
- схема размещения: как Weave Net Kubernetes ляжет на существующую адресацию и не пересечётся с диапазонами сервисов;
- подбор режима сети — оверлей поверх маршрутизации или прямой режим, и где нужен шифрованный канал между узлами;
- план перехода по шагам с точками отката на прежний сетевой слой;
- перечень политик изоляции трафика между пространствами имён: что уже покрыто, что предстоит описать;
- оценка по срокам и составу работ с разбивкой на этапы;
- список того, что требуется с вашей стороны: доступы, окно согласования, контакт дежурного.
Сопровождение кластера — отдельный контур: обновление сетевого слоя, контроль связности узлов, реакция на деградацию и передача документации вашей команде, чтобы конфигурация не осталась «чёрным ящиком».
Опишите задачу и пришлите вводные — вернёмся с оценкой, планом работ и составом этапов.
