Гайди

Як працює Kubernetes: візуальний посібник з налаштування мереж

Продовжуємо знайомство з Kubernetes — платформою з відкритим вихідним кодом для управління контейнерами та супутніми службами. Ми вже розказували у матеріалі для початківців, що таке Kubernetes, його основні компоненти і як його встановити, а також показували, як створювати поди. Сьогодні розкажемо, як налаштовувати мережу в Kubernetes.

Це чимось схоже на налаштування фізичної мережі, адже тут діють ті самі принципи. Проте у Kubernetes є різні специфікації та способи реалізувати налаштування. Також він має свої правила, знаючи які ви зрозумієте, як ця мережа працює. Про все це і піде мова.

Тож зосередьтеся та читайте наш гайд уважно. Додали схеми для того, щоб краще зрозуміти ці зв’язки.

Для чого потрібні мережі в Kubernetes

Мережа Kubernetes дозволяє різним типам об’єктів оркестратора спілкуватися між собою. За замовчуванням схема інфраструктури K8s має багато відокремлень. Простори імен, контейнери та поди відрізняють компоненти один від одного, тому і необхідний чіткий і структурований алгоритм зв’язку між ними.

Що варто знати й пам’ятати про мережеву модель Kubernetes:

У кожного пода є власна IP-адреса: вам не треба окремо створювати зв’язки між подами, а також не потрібно зіставляти порти контейнера з портами хоста.
NAT не обов’язковий: поди на ноді можуть зв’язуватися з усіма модулями на всіх нодах без перетворення мережевих адрес (NAT).
Агенти отримують повний доступ: агенти на ноді, такі як системні демони та Kubelet можуть спілкуватися з усіма подами цієї ноди.
Спільні простори імен: Контейнери всередині пода спільно використовують простір імен мережі (IP та MAC-адресу), щоб вони могли спілкуватися один з одним за допомогою зворотної адреси.

Тепер розглянемо як налаштовувати різні типи зв’язків.

Мережа контейнер-контейнер

Коротко: Зв’язок між контейнерами відбувається через локального хоста (localhost). На схемі його позначено зеленою лінією.

Як це працює: У кожного пода є власний мережевий простір імен, через який цей зв’язок і відбувається. Цей простір імен дозволяє мати окремі мережеві інтерфейси та таблиці маршрутизації, що ізольовані від решти системи та працюють незалежно. А контейнери всередині цього пода мають однакову IP-адресу та порти. Localhost забезпечує зв’язок між контейнерами, адже всі вони є частинами одного простору імен.

Мережа под-под

Коротко: Поди спілкуються один з одним через простір імен мережі пода та простір імен кореневої мережі — між ними повинен проходити трафік.

Як це працює: У кожної ноди в Kubernetes для подів є визначений діапазон IP-адрес безкласової маршрутизації (CIDR). Так поди отримують унікальні IP-адреси, які видно іншим подам у кластері. Кожний новий отримуватиме таку IP-адресу, яка не повторюватиме ту, що належить іншому поду.

У мережі под-под зв’язок відбувається за допомогою реальних IP-адрес, незалежно від того, розгортаєте ви под на тій самій ноді чи на іншій ноді в кластері.

Між простором імен мережі пода та простором імен кореневої мережі трафік проходить завдяки їх з’єднанню за допомогою віртуального пристрою Ethernet або пари veth. На схемі це veth0 до простору імен пода 1 і veth1 до простору імен пода 2. Ці віртуальні інтерфейси з’єднує віртуальний мережевий міст, дозволяючи передавати трафік між ними за допомогою протоколу розпізнавання адрес (ARP).

Дані з пода 1 до пода 2 проходять так:

Трафік пода 1 проходить через eth0 до віртуального інтерфейсу veth0 простору імен кореневої мережі;
Потім трафік проходить через veth0 до віртуального мосту, який під’єднано до veth1;
Трафік проходить через віртуальний міст до veth1;
Та досягає інтерфейсу eth0 пода 2 через veth1.

Мережа под-сервіс

Коротко: зв’язок відбувається за допомогою функції Service. На схемі нижче потік пакетів від пода 1 до пода 3 через Service до іншої ноди позначено червоним.

Як це працює: Поди дуже динамічні. Їх можна масштабувати відповідно до потреб — збільшувати або зменшувати. В разі збою програми чи ноди, поди можна створити знову. Такі моменти змінюють IP-адресу пода, що ускладнює підключення до мережі.

Схему зробив Nived Velayudhan, Associate Solution Architect у Red Hat

Kubernetes розв’язує цю проблему за допомогою функції Service. Принцип її роботи такий:

Функція призначає статичну віртуальну IP-адресу в інтерфейсі, щоб під’єднати серверні поди, пов’язані із сервісом;
Балансує навантаження будь-якого трафіку, що передається цій віртуальній IP-адресі, до набору серверних подів;
Відстежує IP-адресу пода. Навіть якщо вона зміниться, жодних проблем з підключенням до пода у клієнтів не буде, оскільки вони напряму підключаються лише до статичної віртуальної IP-адреси самого сервісу.

Балансування навантаження в кластері відбувається двома способами:

Через IPTABLES — утиліту командного рядка, стандартний інтерфейс керування роботою міжмережевого екрана Netfilter.

В цьому режимі kube-proxy стежить за змінами на сервері API. Для кожного нового сервісу він встановлює правила iptables, які перехоплюють трафік до IP-адреси та порту кластера. Потім трафік перенаправляється на серверний под сервісу. При цьому под обирається випадковим чином. Цей режим надійний і має менші системні витрати, оскільки Linux Netfilter обробляє трафік без необхідності перемикатися між простором користувача та простором ядра.

Через IPVS — віртуальний сервер IP, побудований на основі Netfilter. Він реалізує балансування навантаження на транспортному рівні.

IPVS використовує функцію підключення Netfilter, використовуючи хеш-таблицю як базову структуру даних, і працює в просторі ядра. Це означає, що kube-proxy у режимі IPVS перенаправляє трафік із меншою затримкою, вищою пропускною здатністю та кращою продуктивністю, ніж kube-proxy у режимі iptables.

Тепер розглянемо потік пакетів від поду 1 до поду 3. Пакет з поду 1, який переміщається до віртуального мосту, має використовувати маршрут за замовчуванням (eth0), оскільки протокол визначення адрес ARP, що працює на мосту, не розумів би сервіс. Пізніше пакети мають бути відфільтровані iptables, яка використовує правила, визначені у ноді kube-proxy. Це і зображено на схемі.

Мережа інтернет-сервіс

Тепер ви знаєте, як трафік маршрутизується в кластері. Але у мережі Kubernetes є ще один момент — надання зовнішній мережі доступу до програми.

Схему зробив Nived Velayudhan, Associate Solution Architect у Red Hat

Це можна зробити двома способами:

Вихід (Egress): підходить, якщо ви хочете спрямувати трафік з сервісу Kubernetes до Інтернету. У цьому випадку iptables виконує вихідний NAT, тому трафік надходить із ноди, а не з пода.
Вхід (Ingress): для випадку, коли трафік має надходити з інтернету до сервісів. Ingress також дозволяє або блокує певні зв’язки із сервісами за допомогою правил для з’єднань. Зазвичай, є два вхідних рішення, які працюють у різних областях мережевого стека: балансувальник навантаження служби та вхідний контролер.

Виявлення сервісів

Kubernetes виявляє сервіси двома способами:

Змінні середовища: Служба kubelet, що працює на ноді, де працює ваш под, відповідає за налаштування змінних середовища для кожного активного сервісу у форматі {SVCNAME}_SERVICE_HOST та {SVCNAME}_SERVICE_PORT.

Важливо: створити сервіс потрібно до того, як з’являться клієнтські поди. В іншому випадку змінні середовища цих клієнтських подів не будуть заповнені.

DNS: Служба DNS реалізована як служба Kubernetes, що зіставляється з одним або декількома подами DNS-серверів. Поди в кластері налаштовані на використання служби DNS. Для цього в них є список пошуку DNS, який включає власний простір імен пода та домен кластера за замовчуванням. DNS-сервер із підтримкою кластерів, наприклад CoreDNS, стежить за API Kubernetes для нових сервісів і створює набір записів DNS для кожного з них. Якщо у вашому кластері увімкнено DNS, усі поди можуть автоматично розпізнавати сервіси за їх іменем DNS. DNS-сервер Kubernetes — це єдиний спосіб отримати доступ до сервісів зовнішніх імен.

ServiceTypes для опублікування сервісів

Служби Kubernetes дають можливість доступу до групи подів, яку K8s визначає за допомогою селектора ярликів. Це можуть бути програми, які намагаються отримати доступ до інших програм у кластері, або це може дозволити зовнішній доступ до програми, що працює в кластері. Kubernetes ServiceTypes дає змогу вказати, який сервіс ви хочете отримати.

Схему зробив Ahmet Alp Balkan, розробник у команді обчислювальної інфраструктури та платформ у Twitter

Види ServiceType:

ClusterIP: це тип служби за замовчуванням. Це робить сервіс доступним лише з кластера та дозволяє програмам у ньому спілкуватися одна з одною. Зовнішнього доступу до сервісу немає.
LoadBalancer: цей ServiceType надає зовнішній доступ до служб за допомогою балансувальника навантаження хмарного провайдера. Трафік із зовнішнього балансувальника спрямовується до серверних подів. При цьому як розподіляти навантаження визначає хмарний провайдер.
NodePort: це дозволяє зовнішньому трафіку отримувати доступ до служби, відкриваючи певний порт на всіх нодах. Будь-який трафік, надісланий до цього порту, потім пересилається до служби.
ExternalName: цей тип служби зіставляє службу з іменем DNS за допомогою вмісту поля externalName та повертає запис канонічного імені CNAME із його значенням. Ніякого проксі при цьому не треба.

Напуття

Вітаємо! Тепер ви знаєте правила та основи роботи мережі Kubernetes. Це означає, що вам під силу налаштування зв’язку між контейнерами, подами та сервісами. Проте, щоб закріпити ці знання, радимо спробувати налаштувати мережу у Kubernetes на практиці.

Якщо ви хочете відкривати для себе інші сторони K8s — дайте нам про це знати. Залишіть коментар і поділіться, які теми вам були б цікаві.
Також ви завжди можете отримати комплексні знання та навички на нашому курсі Адміністрування Kubernetes. Зараз всі курси проходять в індивідуальному форматі — лише ви та викладач, тож у вас є можливість навчатись у своєму темпі та взяти від навчання максимум.