Чому 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 зараз, що змінювали вручну поверх конфігурації, де зберігаються маніфести та політики.
- Зовнішній периметр: чи є міжмережевий екран на межі та чи потрібно синхронізувати його правила з мережевими політиками кластера.
- Обмеження: регламентні вікна змін, чи допустимий перезапуск подів, вимоги до відкату та збереження трафіку під час робіт.
- Спостережуваність: чим збираєте метрики та логи, куди їх виводите, за якими ознаками зрозумієте, що маршрутизація та політики працюють штатно.
- Пріоритети: що важливіше на першому етапі — сегментація, стійкість маршрутизації чи пропускна здатність.
Опишіть задачу в тому обсязі, в якому вона зараз є, — уточнювальні питання поставимо самі. На виході отримаєте порядок робіт, склад змін і точки, де знадобиться узгодження з вашого боку.
