Kubernetes вже багато років використовує Docker overlay network як механізм за замовчуванням для з’єднання подів у кластері. Хоча це рішення просте у налаштуванні, у виробничих середовищах воно виявляє низку обмежень продуктивності та архітектурних. У цій статті ми розглянемо внутрішні механізми Docker overlay, проведемо короткі тести latency та throughput і представимо найчастіші підводні камені, з якими стикаються інженери DevOps. На кінець ви знайдете практичний чек‑лист та рекомендації, коли варто обирати overlay, а коли переходити на інший мережевий модель.
Як працює Docker overlay network у Kubernetes
Overlay — це віртуальний шар, побудований поверх існуючої фізичної мережі (наприклад, Ethernet). Кожен pod отримує власну IP‑адресу з діапазону 10.244.0.0/16 (за замовчуванням), а Docker використовує libnetwork та iptables для інкапсуляції трафіку в тунелях VXLAN. Пакет, що виходить з pod, спочатку передається у віртуальний інтерфейс cbr0, потім інкапсулюється у заголовку VXLAN і надсилається через фізичний інтерфейс хоста.
Ключові елементи:
- VXLAN (Virtual Extensible LAN) – забезпечує 24‑бітовий ідентифікатор сегмента (VNI), що дозволяє ізолювати багато кластерів в одній мережі.
- iptables NAT – перекладає адреси pod‑ів на адреси хоста, що дозволяє спілкування поза кластером.
- IPVS / kube-proxy – обробляє load‑balancing сервісів, але в режимі
iptablesдодає додатковий ланцюжок NAT, збільшуючи кількість правил.
Чому це важливо? Кожен додатковий перехід (VXLAN → iptables → IPVS) вводить часові наклади та підвищує використання CPU, що у великих кластерах може стати вузьким місцем.
Порівняння Docker bridge і overlay – що обрати?
Docker bridge — це простий L2‑мост, що працює на рівні окремого хоста. Пакети не інкапсулюються, що усуває наклад VXLAN, але вимагає ручного налаштування маршрутизації між хостами. Overlay, навпаки, працює «з коробки» і автоматично з’єднує всі вузли, але за рахунок додаткової обробки.
На практиці:
- Bridge забезпечує нижчу latency (< 0,2 ms) і вищий throughput (до 10 Gbps) у малих однопоточних середовищах.
- Overlay додає 0,5‑1 ms latency і обмежує throughput до 2‑3 Gbps при повному використанні CPU.
Вибір залежить від вимог: якщо потрібне просте, високопродуктивне з’єднання у закритому тестовому середовищі – bridge. У багатовузловому кластері, де автоматична топологія є ключовою – overlay.
Тести продуктивності – що вимірювати?
Для вимірювання продуктивності overlay найчастіше використовують iperf3 та ping між двома pod‑ами, розташованими на різних вузлах. Нижче приклад набору команд:
# запустити сервер iperf на вузлі A
kubectl run iperf-server --image=networkstatic/iperf3 --restart=Never -- -s
# запустити клієнт iperf на вузлі B
kubectl run iperf-client --image=networkstatic/iperf3 --restart=Never -- -c iperf-server -t 30
# вимір latency
kubectl exec -it iperf-client -- ping -c 10 iperf-serverУ типічному 5‑вузловому кластері (AWS m5.large) отримано середній throughput ~2,4 Gbps і latency 0,8 ms при використанні overlay. Для порівняння, при bridge latency знизилася до 0,3 ms, а throughput піднявся до 7,8 Gbps.
Коли використовувати overlay, а коли ні?
Коли використовувати:
- Багатовузлові середовища з динамічним масштабуванням pod‑ів.
- Потрібна ізоляція мережі між різними командами або середовищами (наприклад, dev vs prod).
- Необхідна проста мережна модель без ручного налаштування маршрутизації.
Коли не використовувати:
- Критично важлива максимальна пропускна здатність і мінімальна latency (наприклад, бази даних, високопродуктивні HPC).
- У вас є контроль над інфраструктурою і ви можете керувати маршрутизацією L2/L3 вручну.
- У кластері з дуже великою кількістю pod‑ів (>10 000) правила iptables стають неуправляваними.
Типові підводні камені у продакшені та їх усунення
1. Переповнення таблиці iptables – при великій кількості сервісів kube‑proxy генерує тисячі правил, що подовжує час обробки пакетів. Рішення: переключити kube‑proxy у режим IPVS, який використовує хеш‑таблиці і значно швидший.
2. Фрагментація VXLAN – неправильне MTU (за замовчуванням 1500) викликає фрагментацію, збільшуючи latency. Рекомендація: встановити MTU 1450 для інтерфейсу cbr0 і підлаштувати MTU у підмережі.
3. Відсутність моніторингу CNI – проблеми з latency часто виникають через неправильну конфігурацію CNI (наприклад, Flannel vs Calico). Використовуйте Prometheus + cAdvisor + kube‑network‑policy для збору метрик container_network_receive_bytes_total та container_network_transmit_errors_total.
«Overlay — це зручність, а не магія — без свідомої оптимізації він стає вузьким місцем будь‑якої програми, що вимагає низької затримки.»
Практичний приклад — чек‑лист впровадження
Нижче готовий список кроків, які мають бути в кожному playbook‑і, що готує кластер Kubernetes до продакшну з Docker overlay network:
- Перевірте версію Docker та kube‑proxy (мінімум 1.20/1.21) — новіші версії містять виправлення в підтримці VXLAN.
- Встановіть MTU 1450 на інтерфейсі
cbr0і переконайтеся у відсутності фрагментації (ping -M do -s 1400). - Переключіть kube‑proxy на
IPVS(kubectl edit cm kube-proxy -n kube-system). - Увімкніть моніторинг CNI (Prometheus + node‑exporter) і налаштуйте алерти на
network_latency_seconds> 1. - Розгляньте альтернативні CNI (Calico, Cilium) у випадку високих вимог до безпеки чи продуктивності.
Після виконання вищезазначених кроків більшість типових проблем із затримкою та пропускною здатністю буде усунуто, і кластер буде готовий до обробки продакшн‑навантажень.
Підсумок і запрошення до співпраці
Docker overlay network у Kubernetes — потужний інструмент, який спрощує створення мереж у великих кластерах, але вимагає свідомої оптимізації з точки зору продуктивності. Розуміння механізмів VXLAN, iptables та IPVS дозволяє уникнути найпоширеніших підводних каменів, а застосування практичного чек‑ліста забезпечує стабільність у продакшн‑середовищах. Якщо вам потрібна допомога з аудитом мережі, міграцією до більш продуктивного CNI або впровадженням розширеного моніторингу, команда Coderia.it готова підтримати ваш проєкт — зв’яжіться з нами вже сьогодні.
