Протоколи Service

Якщо ви налаштовуєте Service, ви можете обрати будь-який мережевий протокол, що підтримується Kubernetes.

Kubernetes підтримує наступні протоколи для Service:

• SCTP
• TCP (типово)
• UDP

Коли ви визначаєте Service, ви також можете вказати протокол застосунку, який він використовує.

Цей документ описує деякі особливі випадки, всі з яких зазвичай використовують TCP як транспортний протокол:

• HTTP та HTTPS
• PROXY protocol
• TLS термінація на балансувальнику навантаження

Підтримувані протоколи

Існує 3 допустимі значення для protocol порту Service:

SCTP

При використанні втулка мережі, що підтримує SCTP-трафік, ви можете використовувати SCTP для більшості Service. Для Service типу LoadBalancer підтримка SCTP залежить від можливості постачальника хмарних послуг надавати цю функцію. (Більшість не підтримують).

SCTP не підтримується на вузлах, що працюють під управлінням Windows.

Підтримка багатодомашніх SCTP-асоціацій

Підтримка багатодомашніх SCTP-асоціацій вимагає, щоб втулок CNI міг підтримувати призначення декількох інтерфейсів та IP-адрес для Podʼів.

NAT для багатодомашніх SCTP-асоціацій вимагає спеціальної логіки у відповідних модулях ядра.

TCP

Ви можете використовувати TCP для будь-якого виду Service, і це стандартний протокол.

UDP

Ви можете використовувати UDP для більшості Service. Для Service типу LoadBalancer підтримка UDP залежить від можливості постачальника хмарних послуг надавати цю функцію.

Особливі випадки

HTTP

Якщо ваш постачальник хмарних послуг підтримує це, ви можете використовувати Service у режимі LoadBalancer для налаштування балансувальника навантаження поза межами вашого кластера Kubernetes у спеціальному режимі, де балансувальник навантаження вашого постачальника хмарних послуг реалізує зворотнє проксіювання трафіку HTTP / HTTPS, з перенаправленням трафіку на бекенд-точки доступу для цього Service.

Зазвичай, ви встановлюєте протокол для Service як TCP і додаєте анотацію (зазвичай специфічну для вашого постачальника хмарних послуг), яка налаштовує балансувальник навантаження для обробки трафіку на рівні HTTP. Ця конфігурація може також включати обслуговування HTTPS (HTTP через TLS) та зворотнє проксіювання plain HTTP до вашого навантаження.

Ви можете додатково вказати, що протокол застосунку зʼєднання є http або https. Використовуйте http, якщо сесія від балансувальника навантаження до вашого навантаження є HTTP без TLS, та використовуйте https, якщо сесія від балансувальника навантаження до вашого навантаження використовує TLS-шифрування.

PROXY protocol

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

Балансувальник навантаження тоді надсилає початкову серію октетів, що описують вхідне зʼєднання, схоже на цей приклад (PROXY protocol v1):

PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

Дані після проксі-протоколу є оригінальними даними від клієнта. Коли будь-яка сторона закриває зʼєднання, балансувальник навантаження також ініціює закриття зʼєднання та надсилає будь-які залишкові дані, якщо це можливо.

Зазвичай, ви визначаєте Service із протоколом TCP. Ви також встановлюєте анотацію, специфічну для вашого постачальника хмарних послуг, яка налаштовує балансувальник навантаження обгортати кожне вхідне зʼєднання у PROXY протокол.

TLS

Якщо ваш постачальник хмарних послуг підтримує це, ви можете використовувати Service із типом LoadBalancer як спосіб налаштування зовнішнього зворотного проксіювання, де зʼєднання від клієнта до балансувальника навантаження зашифроване за допомогою TLS, а балансувальник навантаження виступає як TLS-сервер. Зʼєднання від балансувальника навантаження до вашого навантаження також може бути TLS, або може бути plain text. Точні варіанти залежать від вашого постачальника хмарних послуг або користувацької реалізації Service.

Зазвичай, ви встановлюєте протокол як TCP та встановлюєте анотацію (зазвичай специфічну для вашого постачальника хмарних послуг), яка налаштовує балансувальник навантаження виступати як TLS-сервер. Ви б налаштовували TLS-ідентифікацію (як сервер, та можливо також як клієнт, який підключається до вашого навантаження) за допомогою механізмів, специфічних для вашого постачальника хмарних послуг.