Flannel CNI в Kubernetes: чому рветься overlay-мережа
Flannel як CNI-плагін Kubernetes вирішує одне завдання: видати кожному робочому вузлу власну підмережу та зв'язати ці підмережі поверх фізичної мережі, щоб модулі на різних вузлах спілкувалися напряму.
Поки карти маршрутів і сусідів на всіх вузлах узгоджені, overlay-мережа кластера поводиться передбачувано. Збої починаються там, де стан розходиться: один вузол уже оновив карту підмереж, інший ще тримає попередню.
Перший типовий збій — втрата зв'язку між вузлами: кожен вузол бачить лише свої модулі, а міжмодульний трафік іде в нікуди.
Причини дві: застаріла оренда підмережі після перестворення вузла та збій маршрутизації модулів, коли правила в ланцюжках CNI затерті іншим інструментом або скинуті під час перезапуску рантайму.
Другий клас відмов проявляється нестабільністю: адреси модулів змінюються після перезапуску. Звільнена адреса повертається в пул із затримкою, новий модуль отримує іншу, а сусідні вузли ще тримають старий запис — частина з'єднань іде неіснуючим маршрутом. Ззовні це виглядає як «іноді працює».
Третій і найдорожчий випадок — з'єднання зависають без явних помилок у застосунку. Коли розмір пакета перевищує допустимий для тунелю, а фрагментація заборонена, великі запити тихо губляться: метрики сервісу чисті, користувач чекає відповіді до таймауту.
Такі відмови не видно за логами застосунку. Нижче розбираємо, як ми знаходимо джерело і закриваємо його.
Що змінюється після грамотного налаштування overlay-мережі
Overlay-мережа не «вмикається» один раз — це набір параметрів, від яких залежить поведінка кластера під навантаженням: режим інкапсуляції, розмір підмережі на вузол, узгодженість MTU на всіх інтерфейсах.
Flannel закриває це передбачувано, якщо параметри задані усвідомлено, а не залишені за замовчуванням.
Час підключення нового вузла
Свіжий вузол отримує підмережу зі спільного пулу і має встигнути синхронізувати таблиці маршрутизації до того, як планувальник віддасть на нього робочі навантаження.
За нормально підібраного пулу та перевірки зв'язності до введення в експлуатацію це займає секунди замість хвилин, а вузол не простоює в неробочому стані через гонку під час ініціалізації мережевого шару.
Втрати пакетів і повторювані відмови
Головне джерело втрат в оверлеї — неузгоджений MTU: пакет іде, фрагментується або мовчки відкидається, а застосунок бачить обрив на довгих запитах.
Після вирівнювання MTU та налаштування правил маршрутизації частка втрат падає до часток відсотка, а міжсервісні виклики перестають «плавати» за часом відгуку.
Окремо зникає клас відмов, який найдорожчий: вузол формально живий, але частина маршрутів до інших вузлів розходиться, і трафік іде в нікуди.
Діагностика мережі стає вимірюваною — стан інтерфейсів, лічильники відкинутих пакетів, перевірка досяжності по кожній парі вузлів замість ручного перебору.
Варіанти організації overlay-мережі: порівняння режимів
Режим оверлею визначає, як пакет іде з одного вузла й приходить на інший, і саме від нього залежать оверхед, вимоги до топології та обсяг ручної роботи під час додавання сервера. Нижче — варіанти, між якими реально обирають під час розгортання Flannel у кластері.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| VXLAN | Вузли в різних підмережах і за маршрутизаторами, хмарні мережі без спільної L2 | Інкапсуляція з'їдає частину корисного навантаження: MTU зменшують, інакше великі пакети мовчки губляться |
| host-gw | Усі вузли в одній L2-мережі, у пріоритеті пропускна здатність | Маршрути будуються на кожному вузлі; сегментація L2 або проміжна маршрутизація ламають схему |
| IPIP | Потрібна інкапсуляція з меншим оверхедом, ніж у VXLAN | Лише IPv4, частина NAT-пристроїв такий протокол не пропускає |
| WireGuard | Потрібно шифрувати трафік між вузлами в недовіреному середовищі | Ключі та модуль ядра на кожному вузлі, ротація, додаткове навантаження на процесор |
Як вибрати під свою топологію
Якщо L2 спільна — пряма маршрутизація дає максимум за мінімуму накладних витрат; якщо вузли рознесені — оверлей, а шифрування накладається окремим режимом.
Гібридний варіант сам перемикається на пряму маршрутизацію для сусідів у спільній підмережі й переходить в інкапсуляцію для решти, але налагоджувати його складніше: частина шляхів іде одним способом, частина — іншим.
Порядок налаштування мережі в Kubernetes: шість кроків
Порядок робіт тут не випадковий: мережа — єдиний шар, який не можна перезапустити «на живу». Помилка в схемі адресації проявляється не під час встановлення, а через тижні, коли зростуть кількість вузлів і обсяг трафіку між сервісами.
Тому налаштування Flannel CNI ведемо фіксованою послідовністю — від інвентаризації до передачі в експлуатацію, з перевіркою на кожному переході.
- Аудит конфігурації. Збираємо стан вузлів, зайняті діапазони адрес і правила маршрутизації, щоб overlay-мережа не перетнулася з офісними та хмарними підмережами.
- Схема адресації. Обираємо діапазон pod-мережі та розмір підмережі на вузол — від нього залежить гранична кількість контейнерів і запас на зростання кластера; адреси сервісів плануємо окремим діапазоном.
- Розгортання Flannel. Ставимо CNI керованим компонентом, задаємо режим роботи мережі та параметри адресації декларативно — конфігурацію можна відтворити на чистому кластері.
- Перевірка зв'язності. Проганяємо сценарії вузол-вузол і контейнер-контейнер між різними зонами, окремо переконуємося, що мережеві політики не пропускають зайвий трафік.
- Перевірка під навантаженням. Подаємо зростаючий трафік між сервісами, дивимося затримки, втрати пакетів і поведінку при відмові одного вузла, фіксуємо межу, після якої мережа деградує.
- Передача в експлуатацію. Віддаємо схему адресації, конфігурації, порядок підключення нового вузла та набір перевірок для чергової зміни.
Такий порядок дає головне: кластер масштабується додаванням вузла, а збій локалізується на конкретному шарі, а не шукається по всьому стеку.
Конфігурації, схеми мережі та регламенти експлуатації
Після здачі мережа не повинна триматися на пам'яті одного інженера. Ми передаємо комплект артефактів, за яким кластер піднімається з нуля, перевіряється під навантаженням і передається іншій команді без втрати контексту.
- Робочі конфігурації. Маніфести та параметри мережевого плагіна (Flannel) для площини управління й агентів на кожному вузлі: режим інкапсуляції, розмір пакета, інтервали оновлення стану. Застосовуються ідемпотентно — повторний запуск не ламає працюючий кластер.
- Схема адресації. Діапазони адрес подів і сервісів, їхній розподіл за вузлами й зонами, резерв під майбутні середовища. Окремо позначені діапазони, зайняті поза кластером, щоб нові з ними не перетиналися.
- Схема зв'язності. Як вузли знаходять один одного, де трафік іде напряму, а де через проміжні маршрути, де вихід у зовнішню мережу — з позначкою ділянок, які впруться в пропускну здатність першими.
- Правила доступу. Мережеві політики: хто з ким і за якими портами спілкується, що ізольовано за замовчуванням. Новий сервіс підключається за описаною схемою, а не «як у сусіда».
- Регламент діагностики. Покроковий порядок при втраті зв'язності: що дивитися на вузлі, що в площині управління, які метрики та логи розбирати першими і за якими ознаками локалізується причина.
- Регламент змін. У якому порядку правляться параметри та оновлюються вузли, щоб не ронити трафік, і як повернутися до попереднього набору конфігурацій.
- Інструкція з відновлення. Порядок підняття мережі на чистому кластері та після заміни вузла, з перевірками, які підтверджують зв'язність, а не просто запуск подів.
Кейс: нестабільна мережа кластера — що було і що стало
Початкова картина
Кластер на кілька десятків вузлів обслуговував десятки сервісів, але зв'язок між подами на різних вузлах періодично пропадав: застосунки йшли в повторні спроби, частина запитів не доходила, алерти йшли хвилями.
Частка неуспішних міжсервісних викликів трималася на рівні кількох відсотків, а після перепланування подів мережа відновлювалася до півгодини і лише вручну. Для замовника це виглядало як «плаваючі» короткочасні простої без зрозумілої причини в логах.
Причини склалися в стек: перетинання діапазонів адрес підмереж вузлів, ручна правка маршрутів під час введення нової машини, відсутність контролю розміру пакета під час інкапсуляції трафіку та нульова спостережуваність за тунелями.
Flannel у кластері стояв, але був налаштований частково — звідси «блимаюча» мережа замість передбачуваного каналу.
Що зробили і що отримали
Адресацію перезібрали: кожному вузлу — свій неперетинний діапазон зі спільного пулу, маршрути формує сам CNI-плагін під час появи та зникнення вузла.
Інкапсуляцію налаштували з перевіркою розміру пакета, щоб великі службові відповіді не фрагментувалися й не губилися в дорозі, а поверх додали втрати та повторні передачі на тунелях з алертом на їхнє зростання.
Частка неуспішних викликів упала з кількох відсотків до часток відсотка, відновлення після перепланування відбувається автоматично й укладається в хвилину.
Простій сервісів під час планового обслуговування вузлів скоротився з годин до хвилин, а клас відмов «зв'язок між подами на різних вузлах пропав» перестав повторюватися.
Чим режим прямої маршрутизації відрізняється від інкапсуляції?
Пряма маршрутизація та інкапсуляція вирішують одне завдання — зв'язати модулі на різних вузлах — але платять за це різну ціну.
За прямої маршрутизації вузол прописує маршрути до підмереж сусідів і віддає пакет як є: заголовки не переписуються, зайвий рівень розбору не з'являється. За інкапсуляції кадр модуля пакується в зовнішній пакет, доставляється до вузла призначення і там розпаковується.
Звідси різниця в продуктивності: прямий режим економить такти процесора на упакуванні й не віддає частину пакета під службовий заголовок — пропускна здатність і затримка кращі.
Ціна — вимоги до топології: вузли мають бути в одному сегменті другого рівня або мати маршрутизацію між собою, інакше маршрути доведеться вести вручну і на вузлах, і на мережевому обладнанні.
Інкапсуляція, яку Flannel реалізує через VXLAN, працює поверх звичайної IP-зв'язності: вузли можуть стояти в різних підмережах, у різних провайдерів, у різних хмарах. Це її перевага і джерело накладних витрат — додатковий заголовок, менший MTU, більше роботи з таблицею з'єднань.
Вибір диктує топологія, а не вподобання. Один сегмент L2 і сервіси, чутливі до затримки, — прямий режим; рознесені майданчики та гібридна хмара — інкапсуляція, бо підтримувати маршрутизацію між ними довше й крихкіше.
Зміна режиму без простою можлива, але режим задається в конфігурації кластерної мережі й має збігатися на всіх вузлах — змішування ламає зв'язність.
Вузли переводять по одному: виводять з балансування, змінюють конфігурацію, повертають і перевіряють зв'язність модулів на різних вузлах, перш ніж рухатися далі.
Часті технічні сумніви перед налаштуванням мережі
Перед зміною мережевого шару інженери задають одні й ті самі питання: що робити з уже розгорнутою надбудовою, чи доведеться зупиняти сервіси, чи витримає мережа зростання кластера і чи не впремось у обмеження доступу. Нижче — короткі відповіді, щоб ви звірили їх зі своєю конфігурацією до початку робіт.
Зауважимо відразу: режим роботи та адресні пули вибираються за вашою топологією, а не за замовчуванням плагіна. Тому спочатку знімаємо карту поточної мережі, потім пропонуємо схему перемикання.
У нас уже розгорнута своя мережева надбудова — її доведеться зносити?
Не обов'язково. Достатньо розмежувати діапазони адрес подів: частина вузлів залишається на попередній надбудові, частина переходить на Flannel. Змінюємо хвилями — спочатку тестовий пул і вузли без збереженого стану.
Чи доведеться зупиняти сервіси на час перемикання?
Не на всьому кластері. Вузол виводиться з балансування, на ньому оновлюється мережевий шар, поди переїжджають, вузол повертається. Простій зачіпає лише навантаження без реплік.
Що з розширенням кластера та політиками доступу?
Пул адрес плануємо із запасом на кілька хвиль зростання, щоб нові вузли входили без переналаштування. Мережеві політики та правила доступу переносимо разом із навантаженнями й перевіряємо на тестовому стенді.
Обговоримо задачу: як ми оцінюємо обсяг робіт
Оцінка робіт із мережі кластера починається з обговорення задачі: нам потрібен короткий технічний зріз, зазвичай це одна розмова й доступ до опису поточного стану. Далі обсяг рахуємо ми — з боку замовника не потрібно готувати технічне завдання.
Для розрахунку достатньо:
- топологія: кількість вузлів, зони, керований кластер чи власний;
- як роздається мережа зараз і що саме не влаштовує — збої зв'язності, ручна правка конфігурацій, нестача адрес;
- вимоги до ізоляції між просторами імен і до зовнішнього доступу;
- чи допустима зупинка сервісів або потрібен перехід без простою;
- обмеження: хмарний провайдер, політики безпеки, порядок видачі доступів.
У відповідь повертаємося планом впровадження, а не орієнтовним діапазоном: порядок робіт за етапами, що робиться на кожному, де потрібні вікна обслуговування і якими перевірками підтверджуємо результат — зв'язність модулів між вузлами, збереження маршрутів під час перезапуску вузла, відсутність втрат на накладеній мережі.
Умови фіксуємо до старту: межі робіт, відповідальність сторін, доступи, порядок відкату до попередньої конфігурації та точку приймання. Тоді обсяг не зростає під час проєкту, а ви заздалегідь бачите, у який момент кластер на Flannel можна передавати в експлуатацію.
