Почему Calico CNI даёт сбои при росте кластера
Calico CNI обычно ставят на кластер из десятка узлов — и до поры он работает незаметно. Проблемы начинаются, когда узлов становится больше, а топология перестаёт быть статичной: добавляются пулы адресов, меняются зоны, включается автомасштабирование. Именно тогда связность между узлами превращается в отдельную задачу эксплуатации.
Маршруты подсетей Calico строит поверх BGP: каждый узел анонсирует свой блок адресов и узнаёт блоки соседей. Если сессия с соседом переустановилась, а таблица маршрутизации не пересчиталась, часть трафика между узлами просто не доходит. Снаружи это выглядит странно: сервис отвечает с одной ноды и молчит с другой, а логи приложения при этом чистые.
При масштабировании сети новая нода получает свой блок адресов, но остальные узлы узнают об этом не всегда вовремя. Симметричная картина — при смене топологии: переезд между зонами, замена пула, вывод узла из эксплуатации. Накопленные правила и устаревшие маршруты дают взаимную недоступность сервисов, которую легко списать на ошибку в приложении.
Цена отказов сети кластера выше, чем кажется: деградация выглядит как плавающая ошибка, а не как авария, поэтому диагностика растягивается на часы. Инженер ищет причину в коде, тогда как проблема — в рассогласованных маршрутах и неполной таблице соседей.
Ниже разбираем, как это закрывается: предсказуемое масштабирование сети, контроль состояния BGP-сессий, пересчёт маршрутов подсетей и мониторинг связности между узлами — до того, как отказ проявится на рабочем контуре.
Управляемая сеть кластера: что меняется на практике
Сетевые политики как единая точка контроля
Раньше доступ между сервисами регулировали правками в манифестах и настройках хостов, и на вопрос «какие связи разрешены сейчас» не отвечал никто. Сетевые политики Calico описывают эти связи декларативно и применяются ко всему кластеру: набор разрешений живёт в репозитории, проходит ревью и откатывается вместе с релизом.
Проверка перед выкатом ловит попытку открыть лишний порт, а расхождение между заявленным и фактическим состоянием сети видно в диффе, а не в разборе инцидента. Один источник правды снимает целый класс отказов — доступ, который когда-то открыли «на время» и забыли закрыть.
Изоляция сред и сокращение радиуса отказа
Среды разделяем политиками и непересекающимися адресными пространствами: тестовая нагрузка не достучится до боевой базы, стенд разработчика — до чужого контура. Отказ узла или сервиса остаётся внутри своего сегмента и не тянет за собой соседей по общей сети: маршруты пересобираются автоматически, время восстановления измеряется минутами, а не временем поиска виновника.
Управляемая сеть даёт предсказуемость изменений: новую связь добавляют явным правилом, а не ослаблением контроля, и она не всплывает побочным эффектом в другом контуре.
Режимы Calico CNI: инкапсуляция против прямой маршрутизации
Режим работы сети в Calico выбирают по топологии: где стоят узлы и кто управляет маршрутизацией между ними. От этого зависит накладной расход на каждый пакет и то, сколько сил уйдёт на диагностику инцидентов.
Когда выбирают инкапсуляцию трафика
Инкапсуляция заворачивает пакет пода в дополнительный заголовок, и для сети он выглядит как обычный трафик между узлами. Берут её, когда узлы живут в разных подсетях или зонах, а менять маршрутизацию нельзя: связность появляется сразу, без согласований с сетевыми инженерами. Цена — заголовок съедает полезный размер пакета, поэтому MTU на узлах и в Calico согласуют вручную: иначе крупные ответы фрагментируются, и приложение «то работает, то висит» на больших файлах.
Прямая маршрутизация и анонсы подсетей между узлами
Здесь узлы сами анонсируют свои подсети маршрутизаторам, и трафик до пода идёт без обёртки — полный MTU и меньше задержек на том же железе. Ограничений два: нужен управляемый сегмент с поддержкой BGP и запас по числу маршрутов на коммутаторах. Ошибка в анонсах роняет связность сразу, поэтому конфигурацию проверяют до выката.
| Вариант работы сети | Когда подходит | Ограничения |
|---|---|---|
| Инкапсуляция (IP-in-IP, VXLAN) | узлы в разных подсетях и зонах, маршрутизацию менять нельзя | накладной заголовок, ручное согласование MTU, ниже производительность сети |
| Прямая маршрутизация с анонсами BGP | управляемый сегмент, есть BGP до маршрутизаторов | нужен доступ к настройке сети, лимит маршрутов, выше сложность эксплуатации |
| Смешанный режим по зонам | часть узлов в управляемой сети, часть — нет | две модели сразу, сложнее диагностика и документация |
Этапы внедрения: от разбора топологии до передачи регламентов
Работы идут от инвентаризации до передачи документации: фиксируем то, что есть, проектируем целевую схему, меняем на живом контуре и после проверок отдаём регламенты. Каждый этап заканчивается артефактом, который можно проверить, а не формулировкой «всё настроили».
Схема адресации и план перехода без простоя
- Аудит сети. Инвентаризация подсетей узлов, пулов адресов подов и сервисов, маршрутов и выходов во внешние сети. Результат — карта пересечений и список адресных конфликтов, которые иначе всплывают при масштабировании.
- Схема адресации. Блоки закрепляем за зонами и ролями узлов, оставляем запас под рост. Согласуем с сетевой командой до изменений, чтобы не переделывать на живой нагрузке.
- Настройка. Поднимаем Calico, переводим сетевые политики в режим запрета по умолчанию и описываем разрешения по сервисам. Сессии BGP поднимаем к вышестоящим маршрутизаторам.
- Переход без простоя. Узлы переводим волнами: тестовый контур, затем по одному узел на группу, с проверкой доступности сервисов после каждой волны. Откат возможен на любом шаге.
Проверка политик и сценарии деградации
- Проверка политик. Прогоняем трафик между всеми парами сервисов: лишнее закрыто, нужное проходит. Отдельно смотрим обновление правил и недоступность узла.
- Сценарии деградации. Моделируем отказ узла, потерю маршрута и разрыв сессии — политики не должны блокировать восстановление. По итогам уточняем порядок действий дежурного.
- Передача регламентов. Отдаём схему адресации, конфигурации, описание политик и инструкции по типовым изменениям. Дальше команда заказчика правит правила сама.
Что остаётся у команды заказчика после завершения работ
После сдачи работ у команды заказчика остаётся не набор файлов, а рабочая система управления сетью. Политики, топология и доступы описаны так, что новый инженер входит в контур без устных пояснений и не рвёт связи между сервисами при первом же изменении.
Конфигурации и описания топологии
- Манифесты сетевых политик Calico CNI в системе контроля версий, разложенные по средам и пространствам имён, с единым правилом именования.
- Схема топологии: пулы адресов, маршрутные сессии, узлы и точки выхода трафика наружу — с указанием, какой участок за что отвечает.
- Карта сервисных связей: какие приложения и в какую сторону обмениваются трафиком, где включён запрет по умолчанию.
- Инструкция по диагностике: как отличить блокировку политикой от потери маршрута и что смотреть в состоянии сетевых агентов.
Регламент изменений и матрица доступов
- Матрица доступов: кто из команд и сервисов куда обращается, кто вправе менять правила и в каком порядке.
- Регламент изменений: правка через ветку и проверку на стенде, обязательный план отката, окно применения.
- Журнал решений: почему выбрана именно такая модель изоляции и какие компромиссы приняты.
- Чек-лист подключения нового сервиса: минимальный набор правил, без которых он не попадёт в сеть.
- Порядок ротации доступов при уходе инженера или смене подрядчика.
Каждый артефакт проверен на живом контуре: перед сдачей мы прогоняем типовые изменения по документации вместе с вашим инженером. Опишите задачу — вернёмся с оценкой и планом.
Кейс: как сеть кластера перестала быть узким местом
Кластер вырос до нескольких десятков узлов и трёх сред, а сеть всё ещё жила на ручных маршрутах: инженер добавлял статические записи между подсетями и правил списки доступа в разных местах. Подключение новой команды или разворот среды превращались в ночную работу с риском задеть соседний контур, а сами правила постепенно расходились между стендами.
Что было до: ручные маршруты и расходящиеся правила доступа
Не было единого описания того, какие сервисы кому доступны, поэтому проверка перед изменением занимала часы, а откат делался «по памяти». Выгрузка из системы мониторинга и журналов событий за квартал до внедрения: восстановление после сетевого отказа — около 40 минут, доля потерянных пакетов при выкатке новой версии приложения — до 1,8%, сетевые инциденты с ручным вмешательством — 3–4 раза в месяц.
Метрики после: время восстановления и доля потерянных пакетов
После перевода сети на Calico доступы и маршрутизация описываются декларативно: политики лежат рядом с кодом сервиса, маршруты между узлами разносятся автоматически. По той же выгрузке за следующий квартал: восстановление — 4–6 минут, доля потерянных пакетов на выкатке — ниже 0,05%, сетевых отказов, потребовавших ручного вмешательства, — ноль. Расхождение правил между средами стало невозможным: стенды собираются из одного набора описаний.
Что делать, если в кластере уже развёрнут другой сетевой модуль
Переключить сетевой модуль в работающем кластере одной командой нельзя: каждый CNI владеет IPAM, маршрутами на нодах и цепочками правил в ядре. Смена «на живую» рвёт связность подов за секунды, поэтому есть только два рабочих пути — плановое пересоздание нод или управляемое сосуществование решений.
Сосуществование возможно, но только при разделении зон ответственности: один модуль держит адресацию и маршруты, второй — например, Calico CNI — подключается в режиме только сетевых политик и не трогает IPAM. Тогда новый пул получает отдельный сегмент, а нагрузки переезжают на него группами, без общего окна простоя.
Поэтапный перенос правил доступа начинается с инвентаризации: собираем манифесты политик и сопоставляем семантику — default-deny, разрешения, egress, отбор по меткам и подсетям. Дальше пилот на одном пространстве имён или группе нод: правила задублированы, фактический трафик сверяем по журналам отказов. Сервисы переносим группами, сохраняя откат до момента, когда статистика по обеим сторонам совпала.
Критерий выбора простой. Если нужен обмен маршрутами по BGP с оборудованием за пределами кластера, единый источник политик и предсказуемое поведение при росте — модуль меняем. Если задача сводится к сегментации внутри кластера и штатных сетевых политик хватает, дешевле оставить текущий CNI, чем сопровождать два контроллера. Отдельно проверяем совместимость: нужная ветка Kubernetes, облачный балансировщик, взаимодействие с режимом замены kube-proxy.
Технические сомнения: совместимость, откат, диагностика
Сетевые политики и маршрутизация — та часть кластера, где ошибка видна не сборкой, а тишиной: часть соединений просто перестаёт проходить, и найти виновника по логам приложения невозможно. Поэтому любые правки у нас идут через заранее подготовленный откат, а не «поправим на живом».
Ниже — вопросы, которые задают инженеры до старта работ, и наши ответы по существу.
Как откатить изменения, если политики перекрыли трафик?
Конфигурация Calico декларативна: она хранится в системе контроля версий, а состояние до правки фиксируется дампом правил и маршрутов. Откат — это применение предыдущей ревизии, состояние приводится к исходному за секунды, без пересоздания подов и потери соединений.
Как диагностировать потери трафика?
Идём по пути пакета: маршруты на узлах, счётчики отброшенных пакетов по каждому правилу, журнал отклонённых соединений, метрики задержки и доли успешных ответов. Каждый отказ получает конкретное правило-виновника, а не версию «сеть шумит».
Совместимо ли это с текущим кластером?
Смотрим способ распределения адресов, режим передачи маршрутов и наличие других сетевых слоёв. Перевод делаем пошагово — по узлам и пространствам имён, с проверкой связности после каждого шага, поэтому рабочие сервисы не простаивают.
Как сохранить предсказуемость изменений?
Правки проходят одинаковый путь: план, применение на тестовом контуре, затем на проде с наблюдением графиков отброшенных пакетов и задержек. Если метрики выходят за базовую линию — откат и разбор причин.
Обсудим задачу: что нужно от вас для точной оценки
Чем меньше вводных, тем больше допущений в оценке — поэтому мы начинаем с короткого разбора вашей инфраструктуры. Пришлите то, что есть под рукой, даже в черновом виде: по этим данным мы вернёмся с оценкой работ и планом внедрения по этапам, без «вилки на глаз».
- Топология: сколько кластеров и где они живут, какие подсети узлов и подов, пересекается ли адресация с корпоративной сетью.
- Схема маршрутизации: работаете через наложенную сеть или напрямую, нужен ли BGP, есть ли вышестоящие маршрутизаторы и согласованные автономные номера.
- Требования к изоляции: какие пространства имён и сервисы закрываем, какие связи между ними обязаны остаться, нужен ли доступ из внешних сетей.
- Текущее состояние: как настроен Calico сейчас, что меняли вручную поверх конфигурации, где хранятся манифесты и политики.
- Внешний периметр: есть ли межсетевой экран на границе и нужно ли синхронизировать его правила с сетевыми политиками кластера.
- Ограничения: регламентные окна изменений, допустим ли перезапуск подов, требования к откату и к сохранению трафика во время работ.
- Наблюдаемость: чем собираете метрики и логи, куда их выводите, по каким признакам поймёте, что маршрутизация и политики работают штатно.
- Приоритеты: что важнее на первом этапе — сегментация, устойчивость маршрутизации или пропускная способность.
Опишите задачу в том объёме, в каком она сейчас есть, — уточняющие вопросы зададим сами. На выходе получите порядок работ, состав изменений и точки, где понадобится согласование с вашей стороны.
