Якщо ви налаштовуєте Service, ви можете обрати будь-який мережевий протокол, що підтримується Kubernetes.
Kubernetes підтримує наступні протоколи для Service:
Коли ви визначаєте Service, ви також можете вказати протокол застосунку, який він використовує.
Цей документ описує деякі особливі випадки, всі з яких зазвичай використовують TCP як транспортний протокол:
Існує 3 допустимі значення для protocol порту Service:
SCTPПри використанні втулка мережі, що підтримує SCTP-трафік, ви можете використовувати SCTP для більшості Service. Для Service з type: LoadBalancer підтримка SCTP залежить від того, чи надає таку можливість хмарний провайдер. (Більшість не надає).
SCTP не підтримується на вузлах, що працюють під управлінням Windows.
Підтримка SCTP-асоціацій з мультихомінгом вимагає, щоб втулок CNI міг підтримувати призначення декількох інтерфейсів та IP-адрес для Podʼа.
NAT для SCTP-асоціацій з мультихомінгом вимагає спеціальної логіки у відповідних модулях ядра.
TCPВи можете використовувати TCP для будь-якого виду Service, і це типовий мережевий протокол.
UDPВи можете використовувати UDP для більшості Service. Для Service з type: LoadBalancer підтримка UDP залежить від того, чи надає таку можливість хмарний провайдер.
Якщо ваш хмарний провайдер це підтримує, ви можете використовувати Service у режимі LoadBalancer для налаштування балансувальника навантаження поза межами вашого кластера Kubernetes у спеціальному режимі, де балансувальник навантаження вашого хмарного провайдера реалізує зворотне проксіювання HTTP / HTTPS з перенаправленням трафіку на бекенд-точки доступу цього Service.
Зазвичай ви встановлюєте протокол для Service як TCP і додаєте анотацію (зазвичай специфічну для вашого хмарного провайдера), яка налаштовує балансувальник навантаження для обробки трафіку на рівні HTTP. Ця конфігурація може також включати обслуговування HTTPS (HTTP через TLS) та зворотне проксіювання звичайного HTTP до вашого робочого навантаження.
Можливо, ви також захочете вказати, що протокол застосунку зʼєднання є http або https. Використовуйте http, якщо сесія від балансувальника навантаження до вашого робочого навантаження є HTTP без TLS, та використовуйте https, якщо сесія від балансувальника навантаження до вашого робочого навантаження використовує TLS-шифрування.
Якщо ваш хмарний провайдер це підтримує, ви можете використовувати Service з type: LoadBalancer для налаштування балансувальника навантаження поза межами самого Kubernetes, який буде перенаправляти зʼєднання, обгорнуті у
протокол PROXY.
Балансувальник навантаження тоді надсилає початкову серію октетів, що описують вхідне зʼєднання, схоже на цей приклад (протокол PROXY v1):
PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
Дані після преамбули протоколу PROXY є оригінальними даними від клієнта. Коли будь-яка сторона закриває зʼєднання, балансувальник навантаження також ініціює закриття зʼєднання та надсилає будь-які залишкові дані, якщо це можливо.
Зазвичай ви визначаєте Service із протоколом TCP. Ви також встановлюєте анотацію, специфічну для вашого хмарного провайдера, яка налаштовує балансувальник навантаження обгортати кожне вхідне зʼєднання у протокол PROXY.
Якщо ваш хмарний провайдер це підтримує, ви можете використовувати Service з type: LoadBalancer як спосіб налаштування зовнішнього зворотного проксіювання, де зʼєднання від клієнта до балансувальника навантаження зашифроване за допомогою TLS, а балансувальник навантаження виступає як TLS-сервер. Зʼєднання від балансувальника навантаження до вашого робочого навантаження також може бути TLS або може бути незашифрованим. Точні доступні вам варіанти залежать від вашого хмарного провайдера або власної реалізації Service.
Зазвичай ви встановлюєте протокол як TCP та встановлюєте анотацію (зазвичай специфічну для вашого хмарного провайдера), яка налаштовує балансувальник навантаження виступати як TLS-сервер. Ви налаштовуєте TLS-ідентичність (як сервер, а можливо, також як клієнт, який підключається до вашого робочого навантаження) за допомогою механізмів, специфічних для вашого хмарного провайдера.