Настройка Kubernetes CNI Plugin (Flannel) для overlay-сети

Flannel CNI в Kubernetes: почему рвётся overlay-сеть

Flannel как CNI-плагин Kubernetes решает одну задачу: выдать каждому рабочему узлу собственную подсеть и связать эти подсети поверх физической сети, чтобы модули на разных узлах общались напрямую. Пока карты маршрутов и соседей на всех узлах согласованы, overlay-сеть кластера ведёт себя предсказуемо. Сбои начинаются там, где состояние расходится: один узел уже обновил карту подсетей, другой ещё держит прежнюю.

Первый типовой сбой — потеря связи между узлами: каждый узел видит только свои модули, а межмодульный трафик уходит в никуда. Причины две: устаревшая аренда подсети после пересоздания узла и сбой маршрутизации модулей, когда правила в цепочках CNI затёрты другим инструментом или сброшены при перезапуске рантайма.

Второй класс отказов проявляется нестабильностью: адреса модулей меняются после перезапуска. Освободившийся адрес возвращается в пул с задержкой, новый модуль получает другой, а соседние узлы ещё держат старую запись — часть соединений уходит по несуществующему маршруту. Снаружи это выглядит как «иногда работает».

Третий и самый дорогой случай — соединения зависают без явных ошибок в приложении. Когда размер пакета превышает допустимый для туннеля, а фрагментация запрещена, крупные запросы тихо теряются: метрики сервиса чистые, пользователь ждёт ответа до таймаута. Такие отказы не видны по логам приложения. Ниже разбираем, как мы находим источник и закрываем его.

Что меняется после грамотной настройки overlay-сети

Overlay-сеть не «включается» один раз — это набор параметров, от которых зависит поведение кластера под нагрузкой: режим инкапсуляции, размер подсети на узел, согласованность MTU на всех интерфейсах. Flannel закрывает это предсказуемо, если параметры заданы осознанно, а не оставлены по умолчанию.

Время подключения нового узла

Свежий узел получает подсеть из общего пула и должен успеть синхронизировать таблицы маршрутизации до того, как планировщик отдаст на него рабочие нагрузки. При нормально подобранном пуле и проверке связности до ввода в строй это занимает секунды вместо минут, а узел не простаивает в нерабочем состоянии из-за гонки при инициализации сетевого слоя.

Потери пакетов и повторяющиеся отказы

Главный источник потерь в оверлее — рассогласованный MTU: пакет уходит, фрагментируется или молча отбрасывается, а приложение видит обрыв на длинных запросах. После выравнивания MTU и настройки правил маршрутизации доля потерь падает до долей процента, а межсервисные вызовы перестают «плавать» по времени отклика.

Отдельно уходит класс отказов, который дороже всего: узел формально жив, но часть маршрутов к другим узлам расходится, и трафик уходит в никуда. Диагностика сети становится измеримой — состояние интерфейсов, счётчики отброшенных пакетов, проверка достижимости по каждой паре узлов вместо ручного перебора.

Варианты организации overlay-сети: сравнение режимов

Режим оверлея определяет, как пакет уходит с одного узла и приходит на другой, и именно от него зависят оверхед, требования к топологии и объём ручной работы при добавлении сервера. Ниже — варианты, между которыми реально выбирают при развёртывании Flannel в кластере.

Как выбрать под свою топологию

Если L2 общая — прямая маршрутизация даёт максимум при минимуме накладных расходов; если узлы разнесены — оверлей, а шифрование накладывается отдельным режимом. Гибридный вариант сам переключается на прямую маршрутизацию для соседей в общей подсети и уходит в инкапсуляцию для остальных, но отлаживать его сложнее: часть путей идёт одним способом, часть — другим.

Порядок настройки сети в Kubernetes: шесть шагов

Порядок работ здесь не случаен: сеть — единственный слой, который нельзя перезапустить «на живую». Ошибка в схеме адресации проявляется не при установке, а через недели, когда вырастут число узлов и объём трафика между сервисами. Поэтому настройку Flannel CNI ведём фиксированной последовательностью — от инвентаризации до передачи в эксплуатацию, с проверкой на каждом переходе.

1. Аудит конфигурации. Собираем состояние узлов, занятые диапазоны адресов и правила маршрутизации, чтобы overlay-сеть не пересеклась с офисными и облачными подсетями.
2. Схема адресации. Выбираем диапазон pod-сети и размер подсети на узел — от него зависит предельное число контейнеров и запас на рост кластера; адреса сервисов планируем отдельным диапазоном.
3. Развёртывание Flannel. Ставим CNI управляемым компонентом, задаём режим работы сети и параметры адресации декларативно — конфигурацию можно воспроизвести на чистом кластере.
4. Проверка связности. Прогоняем сценарии узел-узел и контейнер-контейнер между разными зонами, отдельно убеждаемся, что сетевые политики не пропускают лишний трафик.
5. Проверка под нагрузкой. Подаём растущий трафик между сервисами, смотрим задержки, потери пакетов и поведение при отказе одного узла, фиксируем предел, после которого сеть деградирует.
6. Передача в эксплуатацию. Отдаём схему адресации, конфигурации, порядок подключения нового узла и набор проверок для дежурной смены.

Такой порядок даёт главное: кластер масштабируется добавлением узла, а сбой локализуется на конкретном слое, а не ищется по всему стеку.

Конфигурации, схемы сети и регламенты эксплуатации

После сдачи сеть не должна держаться на памяти одного инженера. Мы передаём комплект артефактов, по которому кластер поднимается с нуля, проверяется под нагрузкой и передаётся другой команде без потери контекста.

• Рабочие конфигурации. Манифесты и параметры сетевого плагина (Flannel) для плоскости управления и агентов на каждом узле: режим инкапсуляции, размер пакета, интервалы обновления состояния. Применяются идемпотентно — повторный запуск не ломает работающий кластер.
• Схема адресации. Диапазоны адресов подов и сервисов, их разбиение по узлам и зонам, резерв под будущие окружения. Отдельно помечены диапазоны, занятые вне кластера, чтобы новые с ними не пересекались.
• Схема связности. Как узлы находят друг друга, где трафик идёт напрямую, а где через промежуточные маршруты, где выход во внешнюю сеть — с пометкой участков, которые упрутся в пропускную способность первыми.
• Правила доступа. Сетевые политики: кто с кем и по каким портам общается, что изолировано по умолчанию. Новый сервис подключается по описанной схеме, а не «как у соседа».
• Регламент диагностики. Пошаговый порядок при потере связности: что смотреть на узле, что в плоскости управления, какие метрики и логи разбирать первыми и по каким признакам локализуется причина.
• Регламент изменений. В каком порядке правятся параметры и обновляются узлы, чтобы не ронять трафик, и как вернуться к предыдущему набору конфигураций.
• Инструкция по восстановлению. Порядок поднятия сети на чистом кластере и после замены узла, с проверками, которые подтверждают связность, а не просто запуск подов.

Кейс: нестабильная сеть кластера — что было и что стало

Исходная картина

Кластер на несколько десятков узлов обслуживал десятки сервисов, но связь между подами на разных узлах периодически пропадала: приложения уходили в повторные попытки, часть запросов не доходила, алерты шли волнами. Доля неуспешных межсервисных вызовов держалась на уровне нескольких процентов, а после перепланирования подов сеть восстанавливалась до получаса и только руками. Для заказчика это выглядело как «плавающие» кратковременные простои без внятной причины в логах.

Причины сложились в стек: пересекающиеся диапазоны адресов подсетей узлов, ручная правка маршрутов при вводе новой машины, отсутствие контроля размера пакета при инкапсуляции трафика и нулевая наблюдаемость по туннелям. Flannel в кластере стоял, но был настроен частично — отсюда «мигающая» сеть вместо предсказуемого канала.

Что сделали и что получили

Адресацию пересобрали: каждому узлу — свой непересекающийся диапазон из общего пула, маршруты формирует сам CNI-плагин при появлении и уходе узла. Инкапсуляцию настроили с проверкой размера пакета, чтобы крупные служебные ответы не фрагментировались и не терялись по пути, а поверх добавили потери и повторные передачи на туннелях с алертом на их рост.

Доля неуспешных вызовов упала с нескольких процентов до долей процента, восстановление после перепланирования идёт автоматически и укладывается в минуту. Простой сервисов при плановом обслуживании узлов сократился с часов до минут, а класс отказов «связь между подами на разных узлах пропала» перестал повторяться.

Чем режим прямой маршрутизации отличается от инкапсуляции?

Прямая маршрутизация и инкапсуляция решают одну задачу — связать модули на разных узлах — но платят за это разной ценой. При прямой маршрутизации узел прописывает маршруты к подсетям соседей и отдаёт пакет как есть: заголовки не переписываются, лишний уровень разбора не появляется. При инкапсуляции кадр модуля упаковывается во внешний пакет, доставляется до узла назначения и там распаковывается.

Отсюда разница в производительности: прямой режим экономит такты процессора на упаковке и не отдаёт часть пакета под служебный заголовок — пропускная способность и задержка лучше. Цена — требования к топологии: узлы должны быть в одном сегменте второго уровня или иметь маршрутизацию между собой, иначе маршруты придётся вести вручную и на узлах, и на сетевом оборудовании.

Инкапсуляция, которую Flannel реализует через VXLAN, работает поверх обычной IP-связности: узлы могут стоять в разных подсетях, у разных провайдеров, в разных облаках. Это её достоинство и источник накладных расходов — дополнительный заголовок, меньший MTU, больше работы с таблицей соединений.

Выбор диктует топология, а не предпочтения. Один сегмент L2 и сервисы, чувствительные к задержке, — прямой режим; разнесённые площадки и гибридное облако — инкапсуляция, потому что поддерживать маршрутизацию между ними дольше и хрупче. Смена режима без простоя возможна, но режим задаётся в конфигурации кластерной сети и должен совпадать на всех узлах — смешение ломает связность. Узлы переводят по одному: выводят из балансировки, меняют конфигурацию, возвращают и проверяют связность модулей на разных узлах, прежде чем двигаться дальше.

Частые технические сомнения перед настройкой сети

Перед изменением сетевого слоя инженеры задают одни и те же вопросы: что делать с уже развёрнутой надстройкой, придётся ли останавливать сервисы, выдержит ли сеть рост кластера и не упрёмся ли в ограничения доступа. Ниже — короткие ответы, чтобы вы сверили их со своей конфигурацией до начала работ.

Оговорим сразу: режим работы и адресные пулы выбираются по вашей топологии, а не по умолчанию плагина. Поэтому сначала снимаем карту текущей сети, потом предлагаем схему переключения.

Придётся ли останавливать сервисы на время переключения?

Не на всём кластере. Узел выводится из балансировки, на нём обновляется сетевой слой, поды переезжают, узел возвращается. Простой затрагивает только нагрузки без реплик.

Что с расширением кластера и политиками доступа?

Пул адресов планируем с запасом на несколько волн роста, чтобы новые узлы входили без перенастройки. Сетевые политики и правила доступа переносим вместе с нагрузками и проверяем на тестовом стенде.

Обсудим задачу: как мы оцениваем объём работ

Оценка работ по сети кластера начинается с обсуждения задачи: нам нужен короткий технический срез, обычно это один разговор и доступ к описанию текущего состояния. Дальше объём считаем мы — со стороны заказчика не требуется готовить техническое задание.

Для расчёта достаточно:

• топология: число узлов, зоны, управляемый кластер или собственный;
• как раздаётся сеть сейчас и что именно не устраивает — сбои связности, ручная правка конфигураций, нехватка адресов;
• требования к изоляции между пространствами имён и к внешнему доступу;
• допустим ли останов сервисов или нужен перевод без простоя;
• ограничения: облачный провайдер, политики безопасности, порядок выдачи доступов.

В ответ возвращаемся планом внедрения, а не примерной вилкой: порядок работ по этапам, что делается на каждом, где нужны окна обслуживания и какими проверками подтверждаем результат — связность модулей между узлами, сохранение маршрутов при перезапуске узла, отсутствие потерь на наложенной сети.

Условия фиксируем до старта: границы работ, ответственность сторон, доступы, порядок отката к прежней конфигурации и точку приёмки. Тогда объём не растёт по ходу проекта, а вы заранее видите, в какой момент кластер на Flannel можно передавать в эксплуатацию.