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

> Концепції та ресурси, що лежать в основі роботи в мережі в Kubernetes.

---

LLMS index: [llms.txt](/llms.txt)

---

## Мережева модель Kubernetes {#the-kubernetes-network-model}

Мережева модель Kubernetes складається з кількох частин:

* Кожен [pod](/docs/concepts/workloads/pods/) у кластері отримує
  власну унікальну кластерну IP-адресу.

  * Pod має власний приватний мережевий простір імен, який спільно використовують всі контейнери всередині podʼа. Процеси, що працюють у різних контейнерах в одному podʼі, можуть спілкуватися між собою через `localhost`.

* _Мережа pod'а_ (також називається кластерною мережею) керує комунікацією між podʼами. Вона забезпечує, що (за відсутності навмисної сегментації мережі):

  * Усі podʼи можуть спілкуватися з усіма іншими podʼами, незалежно від того, чи знаходяться вони на одному [вузлі](/docs/concepts/architecture/nodes/), чи на різних. Podʼи можуть спілкуватися безпосередньо, без використання проксі-серверів чи трансляції адрес (NAT).

    У Windows це правило не застосовується до podʼів з мережею вузла.

  * Агенти на вузлі (такі як системні демони чи kubelet) можуть спілкуватися з усіма podʼами на цьому вузлі.

* API [Service](/docs/concepts/services-networking/service/) дозволяє надати стабільну (довготривалу) IP-адресу або імʼя хосту для сервісу, реалізованого одним або кількома podʼами, при цьому окремі podʼи, що складають сервіс, можуть змінюватися з часом.

  * Kubernetes автоматично керує обʼєктами [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/), які надають інформацію про podʼи, що підтримують сервіс.

  * Реалізація проксі сервісу відстежує набір обʼєктів Service та EndpointSlice і програмує панель даних для маршрутизації трафіку сервісу до його бекендів, використовуючи API операційної системи або хмарних провайдерів для перехоплення або переписування пакетів.

* API [Gateway](/docs/concepts/services-networking/gateway/) (або його попередник [Ingress](/docs/concepts/services-networking/ingress/)) дозволяє зробити сервіси доступними для клієнтів поза кластером.

  * Простішим, але менш гнучким механізмом кластерного ingress є використання API Service з типом [`type: LoadBalancer`](/docs/concepts/services-networking/service/#loadbalancer), якщо підтримується відповідним <a class='glossary-tooltip' title='Організація, що надає платформу для хмарних обчислень.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-cloud-provider' target='_blank' aria-label='постачальником хмарних послуг'>постачальником хмарних послуг</a>.

* [NetworkPolicy](/docs/concepts/services-networking/network-policies) — це вбудований API Kubernetes, який дозволяє контролювати трафік між podʼами або між podʼами та зовнішнім світом.

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

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

* Налаштування простору імен мережі pod виконується системним програмним забезпеченням, яке реалізує [Container Runtime Interface](/docs/concepts/containers/cri/).

* Мережею pod керує [реалізація мережі pod](/docs/concepts/cluster-administration/addons/#networking-and-network-policy). На Linux більшість середовищ виконання контейнерів використовують <a class='glossary-tooltip' title='Втулки мережевого інтерфейсу контейнера (CNI) є типом мережевих втулків, які відповідають специфікації appc/CNI.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/' target='_blank' aria-label='Container Networking Interface (CNI)'>Container Networking Interface (CNI)</a>, щоб взаємодіяти з реалізацією мережі pod, тому ці реалізації часто називаються _CNI втулками_.

* Kubernetes надає стандартну реалізацію проксіювання сервісів, яка називається <a class='glossary-tooltip' title='kube-proxy — це мережевий проксі, що запущений на кожному вузлі кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/command-line-tools-reference/kube-proxy/' target='_blank' aria-label='kube-proxy'>kube-proxy</a>, але деякі реалізації мережі pod використовують власний сервісний проксі, який тісніше інтегрований з іншими компонентами.

* NetworkPolicy зазвичай також реалізується мережею pod. (Деякі простіші реалізації мережі pod не підтримують NetworkPolicy, або адміністратор може вирішити налаштувати мережу pod без підтримки NetworkPolicy. У таких випадках API буде присутній, але не матиме жодного ефекту.)

* Існує багато [реалізацій Gateway API](https://gateway-api.sigs.k8s.io/implementations/), деякі з яких специфічні для певних хмарних середовищ, інші більше орієнтовані на середовища "bare metal", а інші є більш універсальними.

## Що далі

[Підключення застосунків за допомогою Service](/docs/tutorials/services/connect-applications-service/) — це навчальний посібник, який дозволяє дізнатися більше про сервіси та мережу Kubernetes на практичному прикладі.

Стаття [Мережа кластера](/docs/concepts/cluster-administration/networking/) пояснює, як налаштувати мережу для вашого кластера, а також надає огляд задіяних технологій.

Щоб дізнатися про конкретні концепції мережі, дивіться:

* [Service](/docs/concepts/services-networking/service/) — експонує застосунок за допомогою однієї зовнішньої точки доступу
* [Ingress](/docs/concepts/services-networking/ingress/) — маршрутизація HTTP/HTTPS з урахуванням протоколу за допомогою URI, імен хостів та шляхів
* [Gateway API](/docs/concepts/services-networking/gateway/) — динамічне надання інфраструктури та розширена маршрутизація трафіку
* [Network Policies](/docs/concepts/services-networking/network-policies/) — контроль потоку трафіку на рівні IP-адрес або портів (рівень OSI 3 або 4)
* [DNS для Services та Pods](/docs/concepts/services-networking/dns-pod-service/) — виявлення сервісів у вашому кластері за допомогою DNS

---

Section pages:

- [Service](/uk/docs/concepts/services-networking/service/): Надайте доступ до застосунку, що працює в кластері, за допомогою однієї точки доступу, навіть якщо робота розподілена між декількома бекендами.
- [Ingress](/uk/docs/concepts/services-networking/ingress/): Робить вашу мережеву службу HTTP (або HTTPS) доступною за допомогою конфігурації, яка розуміє протокол та враховує вебконцепції, такі як URI, імена хостів, шляхи та інше. Концепція Ingress дозволяє вам направляти трафік на різні бекенди на основі правил, які ви визначаєте через API Kubernetes.
- [Контролери Ingress](/uk/docs/concepts/services-networking/ingress-controllers/): Для того, щоб ресурс [Ingress](/docs/concepts/services-networking/ingress/) працював у вашому кластері, повинен бути запущений _контролер Ingress_. Вам потрібно вибрати принаймні один контролер Ingress та переконатися, що він налаштований у вашому кластері. На цій сторінці перелічені поширені контролери Ingress, які ви можете встановити.
- [Gateway API](/uk/docs/concepts/services-networking/gateway/): Gateway API є різновидом видів API, які забезпечують динамічне надання інфраструктури та розширений маршрутизації трафіку.
- [EndpointSlices](/uk/docs/concepts/services-networking/endpoint-slices/): API EndpointSlice — це механізм, який Kubernetes використовує, щоб ваш Service масштабувався для обробки великої кількості бекендів і дозволяє кластеру ефективно оновлювати свій список справних бекендів.
- [Мережеві політики](/uk/docs/concepts/services-networking/network-policies/): Якщо ви хочете контролювати потік трафіку на рівні IP-адреси чи порту (рівень OSI 3 або 4), мережеві політики Kubernetes дозволяють вам визначати правила потоку трафіку всередині вашого кластера, а також між Podʼами та зовнішнім світом. Ваш кластер повинен використовувати мережевий втулок, який підтримує NetworkPolicy.
- [DNS для Service та Podʼів](/uk/docs/concepts/services-networking/dns-pod-service/): Ваше робоче навантаження може виявляти Serviceʼи всередині вашого кластеру за допомогою DNS; ця сторінка пояснює, як це працює.
- [Подвійний стек IPv4/IPv6](/uk/docs/concepts/services-networking/dual-stack/): Kubernetes дозволяє налаштувати мережеве зʼєднання з одним стеком IPv4, з одним стеком IPv6 або з подвійним стеком з обома сімействами мереж. Ця сторінка пояснює, як це зробити.
- [Маршрутизація з урахуванням топології](/uk/docs/concepts/services-networking/topology-aware-routing/): _Маршрутизацію з урахуванням топології_ надає механізм для збереження мережевого трафіку в межах зони, з якої він походить. Віддача переваги трафіку в межах однієї зони між Podʼами в вашому кластері може допомогти з надійністю, продуктивністю (мережевою затримкою та пропускною здатністю) або вартістю.
- [Мережеві аспекти Windows](/uk/docs/concepts/services-networking/windows-networking/)
- [Виділення IP-адрес ClusterIP Serviceʼам](/uk/docs/concepts/services-networking/cluster-ip-allocation/)
- [Політики внутрішнього трафіку Service](/uk/docs/concepts/services-networking/service-traffic-policy/): Якщо два Podʼа в вашому кластері хочуть взаємодіяти, і вони обидва фактично працюють на одному й тому ж вузлі, використовуйте _Політики внутрішнього трафіку Service_, щоб утримувати мережевий трафік в межах цього вузла. Уникнення зворотного звʼязку через кластерну мережу може допомогти підвищити надійність, продуктивність (затримку мережі та пропускну здатність) або вартість.