Service, балансування навантаження та мережа

Мережева модель Kubernetes

Кожен Pod в Kubernetes отримує свою власну унікальну в межах кластера IP-адресу. Це означає, що вам не потрібно явним чином налаштовувати звʼязок між Podʼами і ви, майже ніколи, не відчуватимете потреби вручну призначати відповідність портів контейнерів портам хосту. Це створює чисту, зворотньосумісну модель, де Podʼи можна вважати подібними до віртуальних машин або фізичних серверів, з точки зору виділення портів, іменування, виявлення служб та балансування навантаження, конфігурації застосунків та міграції.

Kubernetes накладає наступні фундаментальні вимоги до будь-якої реалізації мережі (з урахуванням будь-якої цілеспрямованої політики сегментації мережі):

• Podʼи можуть спілкуватися з усіма іншими Podʼами на будь-якому іншому вузлі без NAT
• Агенти на вузлі (наприклад, системні служби, kubelet) можуть спілкуватися з усіма Podʼами на цьому вузлі

Примітка: Для тих платформ, які підтримують Podʼи, що працюють в мережі вузла (наприклад, Linux), коли Podʼи приєднуються до мережі вузла вони все ще можуть спілкуватися з усіма Podʼами на всіх вузлах без NAT.

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

IP-адреси Kubernetes існують на рівні Pod — контейнери всередині Pod спільно використовують свої мережеві простори імен, включаючи їх IP-адреси та MAC-адреси. Це означає, що контейнери всередині Pod можуть мати доступ до портів один одного через localhost. Це також означає, що контейнери всередині Pod повинні координувати використання портів, але це не відрізняється від процесів у віртуальній машині. Ця модель називається "IP-на-кожен-Pod".

Те, як це реалізовано, залежить від середовища виконання контейнерів в кожному конкретному випадку.

Можна запросити порти на самому вузлі (Node), які переспрямувати до вашого Podʼу. Це називається "портами на вузлі", але досить нішева операція. Те як це реалізовано, залежить від середовища виконання контейнерів в кожному конкретному випадку. Pod сам по собі не бачить існування чи відсутності портів хосту.

Мережа Kubernetes розвʼязує чотири проблеми:

• Контейнери в Pod використовують мережу для спілкування використовучи loopback.
• Service API дозволяє вам використовувати застосунок, що працює в Pod, щоб до нього можна було б дістатись ззовні вашого кластера.
• Ingress надає додаткові можливості спеціально для надання доступу до HTTP-застосунків, вебсайтів та API.
• Gateway API є додатком, який надає виразний, розширюваний та орієнтований на ролі різновиди API для моделювання мережевих служб.
• Ви також можете використовувати Services для публікації служб лише для внутрішнього використання в вашому кластері.

Посібник Поєднання застосунків за допомогою служб пояснює, як використовувати Service для забезпечення взаємодії між застосунками в Kubernetes.

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