# Service
> Надайте доступ до застосунку, що працює в кластері, за допомогою однієї точки доступу, навіть якщо робота розподілена між декількома бекендами.
---
LLMS index: [llms.txt](/llms.txt)
---
В Kubernetes, Service — це метод надання доступу ззовні до мережевого застосунку, який працює як один чи кілька Podʼів у вашому кластері.
Ключова мета Service в Kubernetes — це те, що вам не потрібно модифікувати ваш поточний застосунок для використання незнайомого механізму виявлення Service. Ви можете виконувати код в Podʼах, чи це буде код, призначений для світу, орієнтованого на хмари, або старий застосунок, який ви контейнеризували. Ви використовуєте Service, щоб зробити цей набір Podʼів доступним в мережі, так щоб клієнти могли взаємодіяти з ним.
Якщо ви використовуєте Deployment для запуску вашого застосунку, цей Deployment може динамічно створювати та знищувати Podʼи. З одного моменту і до наступного, ви не знаєте, скільки з цих Podʼів працюють і є справними; ви навіть не можете знати,
як називаються ці справні Podʼи. Podʼи Kubernetes створюються та знищуються щоб відповідати бажаному стану вашого кластера. Podʼи є ефемерними ресурсами (ви не повинні очікувати, що індивідуальний Pod є надійним та довговічним).
Кожен Pod отримує свою власну IP-адресу (Kubernetes очікує, що мережеві втулки гарантують це). Для даного Deployment у вашому кластері набір Podʼів, який працює в один момент часу, може відрізнятися від набору Podʼів, який працює для цього застосунку наступний момент часу.
Це призводить до проблеми: якщо певний набір Podʼів (назвемо їх "backend") надає функціонал іншим Podʼам (назвемо їх "frontend") всередині вашого кластера, як фронтенд дізнається та відстежує, яку IP-адресу підключати, щоб він міг використовувати частину робочого навантаження?
Познайомтесь з _Service_.
## Service в Kubernetes {#services-in-kubernetes}
API Service, що є частиною Kubernetes, є абстракцією, яка допомагає вам давати групі Podʼів доступ в мережі. Кожен обʼєкт Service визначає логічний набір endpoint (зазвичай endpoint — Pod) разом із політикою того, як робити ці Podʼи доступними.
Наприклад, розгляньте stateless бекенд для обробки зображень, який працює з 3 репліками. Ці репліки замінюються одна одною — фронтендам не важливо, який бекенд вони використовують. Хоча конкретні Podʼи, що складають бекенд, можуть змінюватися,
клієнти фронтенду не мають на це звертати уваги, і вони не повинні вести облік набору елементів бекендів самі.
Абстракція Service дозволяє таке відокремлення.
Набір Podʼів, яким призначається Service, зазвичай визначається
селектором, який ви визначаєте. Щоб дізнатися про інші способи визначення endpointʼів сервісу, дивіться [Сервіси _без_ селекторів](#services-without-selectors).
Якщо ваше навантаження використовує HTTP, ви можете викорисовувати [Ingress](/docs/concepts/services-networking/ingress/) для контролю над тим, як вебтрафік досягає цього навантаження. Ingress не є типом сервісу, але він діє як точка входу до вашого кластера. Ingress дозволяє обʼєднати ваші правила маршрутизації в один ресурс, щоб ви могли
експонувати кілька компонентів вашого навантаження, що працюють окремо в вашому кластері, під одним зовнішнім URL.
API [Gateway](https://gateway-api.sigs.k8s.io/#what-is-the-gateway-api) для Kubernetes надає додаткові можливості, які виходять за межі Ingress і Service. Ви можете додати Gateway до вашого кластера, це родина розширених API, реалізованих за допомогою CustomResourceDefinitions, і потім використовувати їх для налаштування доступу до мережевих сервісів, що працюють у вашому кластері.
### Хмарно-нативне виявлення сервісів {#cloud-native-service-discovery}
Якщо ви можете використовувати API Kubernetes для виявлення сервісів у вашому застосунку, ви можете звертатись до сервера API
по відповідні EndpointSlices. Kubernetes оновлює EndpointSlices для сервісу кожного разу, коли набір Podʼів у сервісі змінюється.
Для не-нативних застосунків Kubernetes пропонує способи розміщення мережевого порту чи балансувальника між вашим застосунком та Podʼами бекенду.
В будь-якому випадку ваше навантаження може використовувати ці [засоби виявлення сервісів](#discovering-services) для пошуку цільового сервісу, до якого воно хоче підʼєднатися.
## Визначення Сервісу {#defining-a-service}
Service — це обʼєкт (так само як Pod чи ConfigMap є обʼєктами). Ви можете створювати, переглядати або змінювати визначення Service, використовуючи API Kubernetes. Зазвичай для цього ви використовуєте інструмент, такий як `kubectl`, який звертається до API.
Наприклад, припустимо, у вас є набір Podʼів, які слухають TCP-порт 9376 і мають мітку `app.kubernetes.io/name=MyApp`. Ви можете визначити Сервіс, щоб
опублікувати цього TCP-слухача:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
Застосування цього маніфесту створює новий Сервіс з назвою "my-service" зі стандартним [типом служби](#publishing-services-service-types) ClusterIP. Сервіс обслуговує TCP-порт 9376 на будь-якому Podʼі з міткою `app.kubernetes.io/name: MyApp`.
Kubernetes призначає цьому Сервісу IP-адресу (так званий _кластерний IP_), що використовується механізмом віртуалізації IP-адрес. Для отримання докладнішої інформації про цей механізм, читайте [Віртуальні IP та Проксі-сервіси](/docs/reference/networking/virtual-ips/).
Контролер для цього Сервісу постійно сканує Podʼи, які відповідають його селектору, а потім вносить будь-які необхідні оновлення до набору EndpointSlices для Сервісу.
Назва обʼєкта Сервісу повинна бути дійсним [іменем мітки за стандартом RFC 1123](/docs/concepts/overview/working-with-objects/names#rfc-1123-label-names).
Примітка:
Сервіс може повʼязувати будь-який вхідний port з targetPort. Типово та для зручності, targetPort встановлено на те ж саме значення, що й поле port.
### Визначення портів {#field-spec-ports}
Визначення портів в Podʼах мають назви, і ви можете посилатися на ці назви в атрибуті `targetPort` Сервісу. Наприклад, ми можемо привʼязати `targetPort` Сервісу до порту Podʼа таким чином:
```yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
---
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
name: http-web-svc
```
Це працює навіть у випадку, якщо у Сервісу є суміш Podʼів з використанням одного налаштованого імені, з однаковим мережевим протоколом, доступним через різні номери портів. Це надає багато гнучкості для розгортання та розвитку вашого Сервісу. Наприклад, ви можете змінити номери портів, які Podʼи прослуховують в наступній версії вашого програмного забезпечення бекенду, без руйнівних наслідків для клієнтів.
Стандартним протоколом для Service є [TCP](/docs/reference/networking/service-protocols/#protocol-tcp); ви також можете використовувати будь-який інший [підтримуваний протокол](/docs/reference/networking/service-protocols/).
Оскільки багато Сервісів повинні працювати більше ніж з одним портом, Kubernetes підтримує [визначення кількох портів](#multi-port-services) для одного Сервісу. Кожне визначення порту може мати той же `protocol` або різні.
### Сервіси без селекторів {#services-without-selectors}
Сервіси найчастіше абстрагують доступ до Podʼів Kubernetes завдяки селектору, але коли вони використовуються разом із відповідним набором EndpointSlices обʼєктів та без селектора, Сервіс може абстрагувати інші типи бекендів, включаючи ті, які працюють поза кластером.
Наприклад:
* Ви хочете мати зовнішній кластер баз даних у вашому промисловому середовищі, але у своєму тестовому середовищі ви використовуєте свої власні бази даних.
* Ви хочете спрямувати ваш Сервіс на Сервіс в іншому Namespace чи в іншому кластері.
* Ви мігруєте робоче навантаження в Kubernetes. Під час оцінки цього підходу, ви запускаєте лише частину своїх бекендів в Kubernetes.
У будь-якому з цих сценаріїв ви можете визначити Сервіс _без_ вказівки селектора для відповідності Podʼам. Наприклад:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
```
Оскільки у цього Сервісу немає селектора, відповідні обʼєкти EndpointSlice не створюються автоматично. Ви можете повʼязувати Сервіс з мережевою адресою та портом, де він працює, додавши обʼєкт EndpointSlice вручну. Наприклад:
```yaml
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: my-service-1 # за звичай, використовуйте назву Сервісу
# як префікс для назви EndpointSlice
labels:
# Ви повинні встановити мітку "kubernetes.io/service-name".
# Встановіть її значення, щоб відповідати назві Сервісу
kubernetes.io/service-name: my-service
addressType: IPv4
ports:
- name: http # Має збігатись з іменем порту у визначенні Service
# визначеному вище
appProtocol: http
protocol: TCP
port: 9376
endpoints:
- addresses:
- "10.4.5.6"
- addresses:
- "10.1.2.3"
```
#### Власні EndpointSlices {#custom-endpointslices}
Коли ви створюєте обʼєкт [EndpointSlice](#endpointslices) для Сервісу, ви можете
використовувати будь-яку назву для EndpointSlice. Кожен EndpointSlice в просторі імен повинен мати унікальну назву. Ви поєднуєте EndpointSlice із Сервісом, встановлюючи label `kubernetes.io/service-name` на цьому EndpointSlice.
Примітка:
IP-адреси endpoint не повинні бути: локальними (127.0.0.0/8 для IPv4, ::1/128 для IPv6), або (169.254.0.0/16 та 224.0.0.0/24 для IPv4, fe80::/64 для IPv6).
IP-адреси endpoint не можуть бути кластерними IP-адресами інших Сервісів Kubernetes, оскільки kube-proxy не підтримує віртуальні IP-адреси як призначення.
Примітка:
Сервер API Kubernetes не дозволяє проксіювання до endpoint, які не повʼязані з Podʼами. Дії, такі як kubectl port-forward service/<service-name> forwardedPort:servicePort, де сервіс не має селектора, зазнають збою через це обмеження. Це запобігає використанню сервера API Kubernetes як проксі до endpoint, до яких викликач може не мати авторизації на доступ.
`ExternalName` Сервіс — це особливий випадок Сервісу, який не має селекторів і використовує DNS-імена замість них. Для отримання докладної інформації, див. розділ
[ExternalName](#externalname).
### EndpointSlices
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.21 [stable]
[EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) — це обʼєкти, які представляють підмножину (зріз) мережевих endpoint, які підтримують Сервіс.
Ваш кластер Kubernetes відстежує кількість endpointʼів, які представляє кожен EndpointSlice. Якщо для Сервісу є настільки багато endpointʼів, що досягається порогове значення, тоді Kubernetes додає ще один порожній EndpointSlice і зберігає там нову інформацію про endpoint. Типово Kubernetes створює новий EndpointSlice, як тільки наявні EndpointSlice всі містять принаймні 100 endpoint. Kubernetes не створює новий EndpointSlice, поки не буде потрібно додати додатковий endpoint.
Див. [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) для отримання додаткової інформації про цей API.
### Endpoint (deprecated) {#endpoints}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.33 [deprecated]
API EndpointSlice є розвитком старого API [Endpoints](/docs/reference/kubernetes-api/service-resources/endpoints-v1/). Застарілий API Endpoints має кілька проблем порівняно з EndpointSlice:
* Він не підтримує двостекові кластери.
* Не містить інформації, необхідної для підтримки нових функцій, таких як [trafficDistribution](/docs/concepts/services-networking/service/#traffic-distribution).
* Якщо список точок доступу буде надто довгим, щоб вміститися в одному обʼєкті, він буде скорочений.
Через це рекомендується, щоб усі клієнти використовували API EndpointSlice, а не Endpoints.
#### Endpoints з перевищеним обсягом {#over-capacity-endpoints}
Kubernetes обмежує кількість endpointʼів, які можуть поміститися в один обʼєкт Endpoints. Коли є понад 1000 endpointʼів, які підтримують Сервіс, Kubernetes розміщує дані в обʼєкті Endpoints. Оскільки Сервіс може бути повʼязаним
з більше ніж одним EndpointSlice, обмеження в 1000 endpointʼів впливає лише
на застарілий API Endpoints.
У цьому випадку Kubernetes вибирає не більше 1000 можливих endpointʼів, які слід зберегти в обʼєкті Endpoints, і встановлює анотацію на Endpoints: [`endpoints.kubernetes.io/over-capacity: truncated`](/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity). Панель управління також видаляє цю анотацію, якщо кількість бекенд-Podʼів впадає нижче 1000.
Трафік все ще відсилається на бекенди, але будь-який механізм балансування навантаження, який покладається на застарілий API Endpoints, відсилає трафік не більше, ніж до 1000 доступних бекенд-endpointʼів.
Той самий ліміт API означає, що ви не можете вручну оновлювати Endpoints так, щоб у них було понад 1000 endpointʼів.
### Протокол застосунку {#application-protocol}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.20 [stable]
Поле `appProtocol` надає можливість вказати протокол застосунку для кожного порту Сервісу. Це використовується як підказка для реалізацій для надання розширеної поведінки для протоколів, які вони розуміють. Значення цього поля відображається відповідними обʼєктами Endpoints та EndpointSlice.
Це поле відповідає стандартному синтаксису міток Kubernetes. Дійсні значення — це одне з:
* [стандартні назви служб IANA](https://www.iana.org/assignments/service-names).
* Імплементаційно-визначені префіксовані імена, такі як `mycompany.com/my-custom-protocol`.
* Імена з префіксом, визначені Kubernetes:
| Протокол | Опис |
|----------|-------------|
| `kubernetes.io/h2c` | HTTP/2 через відкритий текст, як описано в [RFC 9113](https://www.rfc-editor.org/rfc/rfc9113) |
| `kubernetes.io/ws` | WebSocket через відкритий текст, як описано у [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455) |
| `kubernetes.io/wss` | WebSocket через TLS, як описано у [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455) |
### Сервіси з кількома портами {#multi-port-services}
Для деяких Сервісів вам може знадобитися використовувати більше одного порту. Kubernetes дозволяє конфігурувати кілька визначень портів в обʼєкті Service. При використанні кількох портів для Сервісу, вам слід надавати всім портам імена,
щоб вони були однозначними. Наприклад:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
```
Примітка:
Так само як і з іменами в Kubernetes взагалі, імена портів мають містити лише буквено-цифрові символи в нижньому регістрі та -. Імена портів також повинні починатися та закінчуватися буквено-цифровим символом.
Наприклад, імена 123-abc та web є допустимими, але 123_abc та -web - ні.
Примітка:
Цей Сервіс видно як <NodeIP>:spec.ports[*].nodePort та .spec.clusterIP:spec.ports[*].port. Якщо встановлено прапорець --nodeport-addresses для kube-proxy або еквівалентне поле у файлі конфігурації kube-proxy, <NodeIP> буде IP-адресою вузла (або можливо IP-адресами) для фільтрування.
### `type: LoadBalancer` {#loadbalancer}
У хмарних постачальників, які підтримують зовнішні балансувальники навантаження, встановлення поля `type` в `LoadBalancer` надає балансувальник навантаження для вашого Сервісу. Створення балансувальника навантаження відбувається асинхронно, і інформація про створений балансувальник публікується у полі `.status.loadBalancer` Сервісу. Наприклад:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
clusterIP: 10.0.171.239
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 192.0.2.127
```
Трафік від зовнішнього балансувальника навантаження направляється на бекенд-Podʼи. Хмарний постачальник вирішує, як він балансує навантаження.
Для реалізації Сервісу з `type: LoadBalancer`, Kubernetes зазвичай починає з того, що вносить зміни, які еквівалентні вашим запитам на Сервіс `type: NodePort`. Компонент cloud-controller-manager потім налаштовує зовнішній балансувальник для пересилання трафіку на цей призначений порт вузла.
Ви можете налаштувати балансований за навантаженням Сервіс для [виключення](#load-balancer-nodeport-allocation) призначення порта вузла, за умови, що реалізація постачальника хмари це підтримує.
Деякі постачальники хмар дозволяють вам вказати `loadBalancerIP`. У цих випадках балансувальник створюється з вказаною користувачем `loadBalancerIP`. Якщо поле `loadBalancerIP` не вказано, то балансувальник налаштовується з ефемерною IP-адресою. Якщо ви вказали `loadBalancerIP`, але ваш постачальник хмари не підтримує цю функцію, то вказане вами поле `loadbalancerIP` ігнорується.
Примітка:
Поле .spec.loadBalancerIP для Сервісу було визнане застарілим в Kubernetes v1.24.
Це поле було недостатньо визначеним, і його значення різниться в різних реалізаціях. Воно також не підтримує мережі з подвійним стеком. Це поле може бути вилучено в майбутніх версіях API.
Якщо ви інтегруєтеся з постачальником, який підтримує вказання IP-адреси(в) балансувальника навантаження для Сервісу через анотацію (специфічну для постачальника), вам слід перейти на цей метод.
Якщо ви пишете код для інтеграції балансувальника з Kubernetes, уникайте використання цього поля. Ви можете інтегрувати його з Gateway замість Service, або ви можете визначити власні анотації (специфічні для постачальника) для Сервісу, які визначають еквівалентну деталь.
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.26 [stable](стандартно увімкнено)
Типово для Сервісів типу LoadBalancer, коли визначено більше одного порту, всі порти повинні мати один і той же протокол, і цей протокол повинен бути підтримуваний
постачальником хмари.
Функціональна можливість `MixedProtocolLBService` (стандартно увімкнена для kube-apiserver з версії v1.24) дозволяє використовувати різні протоколи для Сервісів типу LoadBalancer, коли визначено більше одного порту.
Примітка:
Набір протоколів, які можна використовувати для балансованих навантажень Сервісів, визначається вашим постачальником хмари; вони можуть накладати обмеження поза тим, що накладає API Kubernetes.
#### Вимкнення виділення порту вузла для балансувальника навантаження {#load-balancer-nodeport-allocation}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.24 [stable]
Ви можете вимкнути виділення порту вузла для Сервісу з `type: LoadBalancer`, встановивши поле `spec.allocateLoadBalancerNodePorts` в `false`. Це слід використовувати тільки для реалізацій балансувальників, які маршрутизують трафік безпосередньо до Podʼів, а не використовують порти вузла. Стандартно `spec.allocateLoadBalancerNodePorts` дорівнює `true`, і Сервіси типу LoadBalancer будуть продовжувати виділяти порти вузла. Якщо `spec.allocateLoadBalancerNodePorts` встановлено в `false` для існуючого Сервісу з виділеними портами вузла, ці порти вузла **не** будуть автоматично видалятися. Вам слід явно видалити запис `nodePorts` в кожному порту Сервісу для деалокації цих портів вузла.
#### Вказання класу реалізації балансувальника {#load-balancer-class}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.24 [stable]
Для Сервісу з `type` встановленим на `LoadBalancer`, поле `.spec.loadBalancerClass`
дозволяє вам використовувати реалізацію балансувальника, відмінну від тієї, яку типово встановлено постачальником хмари.
Типово `.spec.loadBalancerClass` не встановлено, і Сервіс з `LoadBalancer` використовує реалізацію балансувальника що постачається в хмарі, якщо кластер налаштовано постачальником хмари за допомогою прапорця компоненту `--cloud-provider`. Якщо ви вказуєте `.spec.loadBalancerClass`, вважається, що реалізація балансувальника, яка відповідає вказаному класу, відстежує Сервіси. Будь-яка стандартна реалізація балансувальника (наприклад, та, яку надає постачальник хмари), ігнорує Сервіси, у яких встановлено це поле. `spec.loadBalancerClass` може бути встановлено тільки для Сервісу типу `LoadBalancer`. Після встановлення його не можна змінити. Значення `spec.loadBalancerClass` повинно бути ідентифікатором у формі мітки, з необовʼязковим префіксом, таким як "`internal-vip`" або "`example.com/internal-vip`". Безпрефіксні імена зарезервовані для кінцевих користувачів.
#### Режим IP-адреси балансувальника навантаження {#load-balancer-ip-mode}
Для Service з типом `type: LoadBalancer`, контролер може встановити `.status.loadBalancer.ingress.ipMode`. `.status.loadBalancer.ingress.ipMode` вказує, як веде себе IP-адреса балансувальника. Воно може бути вказано лише тоді, коли вказано поле `.status.loadBalancer.ingress.ip`.
Є два можливі значення для `.status.loadBalancer.ingress.ipMode`: "VIP" та "Proxy". Типово встановлене значення "VIP", що означає, що трафік подається на вузол з призначенням, встановленим на IP та порт балансувальника. Є два випадки, коли встановлено значення "Proxy", залежно від того, як постачальник хмари балансує трафік:
* Якщо трафік подається на вузол, а потім перенаправляється до Podʼа, призначення буде встановлено на IP та порт вузла;
* Якщо трафік подається безпосередньо до Podʼа, призначення буде встановлено на IP та порт Podʼа.
Реалізації Сервісів можуть використовувати цю інформацію для налаштування маршрутизації трафіку.
#### Внутрішній балансувальник {#internal-load-balancer}
У змішаному середовищі іноді необхідно направляти трафік від Сервісів всередині того ж (віртуального) мережевого блоку.
У середовищі DNS з розділеним горизонтом вам знадобляться два Сервіси, щоб мати можливість маршрутизувати як зовнішній, так і
внутрішній трафік до ваших точок доступу.
Щоб встановити внутрішній балансувальник, додайте одну з наступних анотацій до Сервісу в залежності від постачальника хмари, який ви використовуєте:
metadata:
name: my-service
annotations:
networking.gke.io/load-balancer-type: "Internal"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-scheme: "internal"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
metadata:
name: my-service
annotations:
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
metadata:
annotations:
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
metadata:
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/oci-load-balancer-internal: true
Примітка:
Сервіс типу ExternalName приймає рядок IPv4 адреси, але трактує цей рядок як імʼя DNS, що складається з цифр, а не як IP-адресу (інтернет, однак, не дозволяє такі імена в DNS). Сервіси зовнішніх імен, які нагадують IPv4 адреси, не розвʼязуються DNS-серверами.
Якщо ви хочете звʼязати Сервіс безпосередньо з конкретною IP-адресою, розгляньте можливість використання headless Services.
Увага:
Можливі проблеми з використанням ExternalName для деяких загальних протоколів, таких як HTTP та HTTPS. Якщо ви використовуєте ExternalName, імʼя хоста, яке використовують клієнти всередині вашого кластера, відрізняється від
імені, на яке посилається ExternalName.
Для протоколів, які використовують імена хостів, ця різниця може призвести до помилок або непередбачуваних відповідей. HTTP-запити матимуть заголовок Host:, який сервер-джерело не визнає; сервери TLS не зможуть надати сертифікат, що відповідає імені хоста, до якого приєдно клієнта.
Примітка:
Коли у вас є Pod, який потребує доступу до Сервісу, і ви використовуєте метод змінної середовища для публікації порту та кластерного IP для Podʼів клієнта, ви повинні створити Сервіс перед створенням Podʼів клієнта. В іншому випадку ці Podʼи клієнта не матимуть заповнених змінних середовища.
Якщо ви використовуєте лише DNS для визначення кластерного IP для Сервісу, вам не потрібно турбуватися про цю проблему порядку.
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.36 [deprecated]
Всі користувачі повинні почати міграцію з `externalIPs`. Розгляньте можливість використання контролера зовнішнього балансувальника навантаження або реалізації Gateway API.
Якщо існують зовнішні IP-адреси, які маршрутизують до одного чи декількох вузлів кластера, Сервіси Kubernetes можна використовувати на цих `externalIPs`. Коли мережевий трафік потрапляє в кластер із зовнішнім IP (як IP призначення) та портом, який відповідає цьому Сервісу, правила та маршрути, які Kubernetes налаштовує, забезпечують маршрутизацію трафіку до однієї з точок доступу цього Сервісу.
При визначенні Сервісу ви можете вказати `externalIPs` для будь-якого [типу сервісу](#publishing-services-service-types). У наведеному нижче прикладі Сервіс з іменем `"my-service"` може отримати доступ від клієнтів за допомогою TCP за адресою `"198.51.100.32:80"` (розраховано із `.spec.externalIPs[]` та `.spec.ports[].port`).
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 49152
externalIPs:
- 198.51.100.32
```
Примітка:
Kubernetes не керує виділенням externalIPs; це відповідальність адміністратора кластера.
## API Обʼєкт {#api-object}
Сервіс — це ресурс верхнього рівня в Kubernetes REST API. Ви можете знайти більше деталей про [обʼєкт API Service](/docs/reference/generated/kubernetes-api/v1.36/#service-v1-core).
## Що далі
Дізнайтеся більше про Сервіси та те, як вони вписуються в Kubernetes:
* Дізнайтесь про [Підключення застосунків за допомогою Service](/docs/tutorials/services/connect-applications-service/).
* Прочитайте про [Ingress](/docs/concepts/services-networking/ingress/), який експонує маршрути HTTP та HTTPS ззовні кластера до Сервісів всередині вашого кластера.
* Прочитайте про [Gateway](/docs/concepts/services-networking/gateway/), розширення для Kubernetes, яке надає більше гнучкості, ніж Ingress.
Для отримання додаткового контексту прочитайте наступне:
* [Віртуальні IP та Сервісні проксі](/docs/reference/networking/virtual-ips/)
* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
* [Довідка API Service](/docs/reference/kubernetes-api/service-resources/service-v1/)
* [Довідка API EndpointSlice](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/)
* [Довідка API Endpoint (застаріла)](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
