Модуль 4.4: Cloud-Native мережі та топології VPC
Складність: [COMPLEX] | Час на виконання: 3.5 год | Передумови: Модуль 4.1 (Керований vs Власний Kubernetes), Модуль 4.2 (Мультикластер)
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»У вересні 2022 року логістична компанія, що керувала 14 кластерами Kubernetes в AWS, отримала сповіщення о 2:15 ночі: “Поди застрягли у стані ContainerCreating”. Інженер перевірив: 18 подів чекали на запуск, і кожен видавав помилку: failed to assign an IP address to the pod. Проблема була не в браку CPU чи пам’яті — у підмережах просто закінчилися вільні IP-адреси.
Вони використовували підмережі /24 (251 IP-адреса). Кожен потужний вузол m5.2xlarge споживав до 60 IP-адрес для своїх подів. Лише 4 такі вузли — і підмережа порожня. Кластер помирав не від навантаження, а від “задухи” через брак адрес. Виправлення зайняло 11 годин: довелося створювати нові підмережі та переносити туди всі сервери в розпал робочого дня.
Мережа в хмарі — це не просто “дроти”. Це архітектурний фундамент. Якщо ви помилитеся в плануванні IP-адрес, виборі типу мережі (Underlay vs Overlay) або налаштуванні NAT-шлюзів — ваша система або захлинеться при масштабуванні, або виставить вам рахунок на тисячі доларів за зайвий трафік.
У цьому модулі ви навчитеся проєктувати мережі для Kubernetes правильно з першого дня. Ми розберемо моделі споживання IP, навчимося будувати економні схеми виходу в інтернет та з’єднувати десятки кластерів без конфліктів адрес.
Планування IP: Скільки адрес потрібно Kubernetes?
Розділ «Планування IP: Скільки адрес потрібно Kubernetes?»Головна відмінність Kubernetes від віртуальних машин: кожен под споживає окрему IP-адресу з вашої мережі VPC (якщо ви використовуєте стандартний VPC CNI).
- Традиційно: 10 серверів = 10 IP. Підмережі /24 (251 IP) вистачає на роки.
- У Kubernetes: 10 серверів по 30 подів = 310 IP. Підмережа /24 закінчується ще до того, як ви запустите 10 вузлів.
Золоте правило: Завжди робіть підмережі для Kubernetes мінімум у 2-4 рази більшими, ніж ваші поточні потреби. IP-адреси у внутрішній мережі безкоштовні, а їх зміна в продакшні — надзвичайно болюча.
Underlay (VPC-Native) vs Overlay
Розділ «Underlay (VPC-Native) vs Overlay»Це фундаментальне рішення для архітектури мережі.
1. Underlay (напр. AWS VPC CNI)
Розділ «1. Underlay (напр. AWS VPC CNI)»Поди отримують “справжні” IP-адреси з вашої хмари.
- Плюс: Максимальна швидкість (line speed), глибока інтеграція з хмарними балансувальниками.
- Мінус: Дуже швидко закінчуються IP-адреси.
2. Overlay (напр. Calico VXLAN, Cilium)
Розділ «2. Overlay (напр. Calico VXLAN, Cilium)»Поди отримують адреси з віртуальної мережі, яку хмара “не бачить”. Трафік запаковується в тунелі між серверами.
- Плюс: Вам не треба багато IP-адрес у VPC.
- Мінус: Накладні витрати на CPU (5-15%) та складність відлагодження.
Рекомендація: Для однієї хмари використовуйте Underlay (VPC-native) — це стандарт індустрії.
Економія на трафіку: NAT Gateways та Endpoints
Розділ «Економія на трафіку: NAT Gateways та Endpoints»NAT Gateway — це найдорожчий “сюрприз” у рахунках AWS/Azure. Кожен гігабайт, що проходить через NAT (напр. завантаження Docker-образів із реєстру), коштує грошей.
Як заощадити 60-80% на мережі: Використовуйте VPC Endpoints (PrivateLink). Це “короткий шлях” до сервісів (S3, ECR, CloudWatch) всередині мережі хмари. Трафік через них іде безкоштовно або значно дешевше, ніж через NAT Gateway.
Transit Gateway: Хаб для ваших мереж
Розділ «Transit Gateway: Хаб для ваших мереж»Коли у вас 2-3 мережі, ви можете з’єднати їх через Peering. Коли їх 10 — вам потрібен Transit Gateway. Це віртуальний роутер, який дозволяє керувати всіма зв’язками в одному місці. Ви можете легко заборонити мережі “Dev” бачити мережу “Prod”, не торкаючись кожного окремого сервера.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це стається | Як виправити |
|---|---|---|
| Підмережі /24 для кластера | Звичка зі світу віртуалок | Ставте /20 або /19 для продуктових підмереж подів |
| Відсутність VPC Endpoints | ”NAT і так працює” | Налаштуйте Endpoints для S3 та ECR у першу чергу |
| Накладання IP (overlapping CIDRs) | “Всі використовують 10.0.0.0/16” | Плануйте глобальну схему IP для всієї компанії (Dev: 10.1, Staging: 10.2, Prod: 10.3) |
| Один NAT Gateway на весь регіон | Економія на старті | Розгортайте по одному NAT на кожну зону (AZ). Якщо одна зона “впаде” — інші працюватимуть далі |
Тест
Розділ «Тест»1. Чому при використанні VPC CNI важливо увімкнути 'Prefix Delegation'?
Це дозволяє кожному мережевому інтерфейсу сервера отримувати не окремі IP, а цілі блоки (префікси /28). Це радикально збільшує кількість подів, які можна запустити на одному сервері, і зменшує кількість звернень до API хмари за новими адресами.
2. У чому небезпека однакових IP-діапазонів у різних VPC?
Ви не зможете з’єднати ці мережі між собою (через Peering чи VPN). Якщо вашому серверу в Dev (10.0.1.5) треба буде спитати щось у сервера в Prod (теж 10.0.1.5) — роутер не знатиме, куди слати пакет.
Практична вправа: Дизайн мережі
Розділ «Практична вправа: Дизайн мережі»- Розрахуйте, скільки IP-адрес вам потрібно для кластера на 100 вузлів, де на кожному працює по 30 подів. Оберіть відповідний розмір підмережі.
- Намалюйте схему виходу в інтернет: які сервіси мають йти через NAT Gateway, а які — через VPC Endpoints.
- Визначте, як розділити IP-адреси між трьома зонами доступності (us-east-1a, b, c) для одного кластера.
Вітаємо!
Розділ «Вітаємо!»Ви завершили серію Архітектурних патернів хмар. Тепер ви знаєте, як будувати Kubernetes-деплої, що легко керуються, виживають при катастрофах, захищені на рівні ідентифікації та правильно налаштовані на рівні мережі.
Ці знання — це різниця між “адміном, який просто ставить K8s”, та “хмарним архітектором”, який будує надійні платформи.
Що далі? Дослідіть трек Платформної інженерії, щоб дізнатися, як ці хмарні блоки стають частиною єдиної внутрішньої платформи для розробників.