Облачная платформаAdvanced

Обзор службы

Эта статья полезна?

Язык статьи: Русский

Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

В Kubernetes Служба делает приложение, запущенное на наборе подов, доступным по сети. Она предоставляет постоянное имя DNS для этих подов и распределяет трафик между ними для балансировки нагрузки. Этот раздел описывает базовые концепции служб Kubernetes и предоставляет сравнение различных типов служб.

Служба

После создания пода прямой доступ к нему может привести к некоторым проблемам:

Контроллер, такой как Deployment, может удалить под и в любой момент воссоздать его. Если под будет воссоздан, доступ к нему может завершиться неудачей.
IP‑адрес не может быть назначен поду, пока под не запущен. До запуска пода его IP‑адрес неизвестен.
Приложения обычно работают на нескольких подах, использующих один и тот же образ. Поочерёдный доступ к подам неэффективен.

Например, Deployment используется для развертывания фронтенда и бэкенда приложения. Фронтенд вызывает бэкенд для вычислений, как показано в Рисунок 1. Три Под работают в backend, и они независимы и заменяемы. Когда backend Под пересоздаётся, новому Под присваивается новый IP address, но frontend Под не знает об этом изменении.

Рисунок 1 Доступ между Подами

Чтобы решить эти проблемы, Kubernetes внедряет Сервисы, которые предоставляют стабильные сетевые интерфейсы и постоянные IP address для Подов. Вы можете установить эти IP address используя CIDR‑блоки сервиса во время создания кластера. CIDR‑блоки сервиса используются для назначения IP address сервисам. Сервис использует селектор меток для идентификации целевых Подов и использует балансировку нагрузки для равномерного распределения трафика между ними. Эта абстракция устраняет сложность прямого доступа к отдельным Подам и повышает как доступность, так и эффективность рабочих нагрузок.

Для приведённого выше примера Сервис создаётся для backend Подов и используется frontend Подом для доступа к этим backend Подам. Таким образом, frontend Под остаётся неизменным при любых изменениях backend Подов, как показано в Рисунок 2.

Рисунок 2 Доступ к подам через Сервис

Эндпоинт и EndpointSlice

В Kubernetes и Эндпоинты, и EndpointSlices являются объектами ресурсов, используемыми для управления сетевыми эндпоинтами подов бэкэнд‑сервиса.

Эндпоинты являются традиционным объектом ресурса для обнаружения сервиса. Эндпоинт представляет собой коллекцию эндпоинтов всех подов, связанных с Сервисом. Эндпоинт автоматически создаётся для каждого Сервиса с определённым селектором. Он записывает список IP‑адресов и портов всех подходящих подов. После удаления или пересоздания пода его IP‑адрес может измениться. Эндпоинт соответственно обновляет IP‑адрес и порт пода, чтобы обеспечить продолжение маршрутизации трафика Сервисом к правильным подам.
Ключевые особенности Эндпоинтов включают:
- Каждый объект Эндпоинт соответствует одному Сервису.
- Каждый Эндпоинт хранит IP‑адреса и порты всех бэкэнд‑подов, связанных с Сервисом.
- Любое изменение статуса пода инициирует обновление соответствующего объекта Эндпоинт.
- По умолчанию объект Эндпоинт может содержать до 1000 эндпоинтов. Если этот предел превышен, дополнительные эндпоинты обрезаются и не включаются в объект.
EndpointSlices являются альтернативой традиционному Endpoints API, представленному как альфа‑фича в Kubernetes v1.16 и продвинутому до стабильного в v1.21. Они решают ограничения производительности Endpoints в больших кластерах и управляют сетевыми конечными точками с помощью шардинга.
- Каждый Service связан с одним или несколькими EndpointSlices.
- По умолчанию каждый EndpointSlice может содержать до 100 endpoints. При превышении этого лимита Kubernetes создает дополнительные EndpointSlices, чтобы разместить оставшиеся endpoints.
- Endpoints группируются по протоколу, порту и имени Service.
- EndpointSlices поддерживают типы адресов IPv4, IPv6 и полностью квалифицированное доменное имя (FQDN).

Различия между объектами Endpoint и EndpointSlice перечислены в таблице ниже.

Категория	Endpoint	EndpointSlice	Различие
Архитектура	Все endpoints хранятся в одном объекте.	Endpoints хранятся в разных шардах.	EndpointSlice распределяет конечные точки в нескольких объектах.
Максимальное количество конечных точек на объект	1000	100	EndpointSlice поддерживает больше конечных точек за счёт шардов.
Гранулярность обновления	Требуется полное обновление объекта при любом изменении	Обновляются только затронутые шарды	Когда изменяется pod, EndpointSlice обновляет только затронутые шарды.
Сетевой трафик	Высокий (весь объект передаётся при любом изменении)	Низкий (только изменённые шарды передаются)	У них существенные различия в больших кластерах.
Потребление ресурсов API	Высокий	Низкий	EndpointSlices снижают нагрузку на etcd.
Версия Kubernetes	Поддерживается во всех версиях (Endpoints будет прекращено в v1.33 и заменено на EndpointSlices.)	Введено в v1.16, стабильно с v1.21	Кластеры более ранних версий могут не поддерживать EndpointSlices.
Сценарий применения	Небольшие кластеры	Большие кластеры	EndpointSlices разработаны для сред с высокой производительностью.

Перенаправление запросов (iptables и IPVS)

kube-proxy является ключевым компонентом кластера Kubernetes. Он используется для балансировки нагрузки и перенаправления данных между Service и его backend pod'ами. CCE поддерживает два iptables и IPVS перенаправление запросов.

iptables является функцией ядра Linux для обработки и фильтрации большого количества пакетов данных. Он позволяет гибко присоединять последовательности правил к различным hook'ам в конвейере обработки пакетов. Когда используется iptables, kube-proxy реализует NAT и балансировку нагрузки в NAT pre-routing hook. Для каждого Service kube-proxy устанавливает правило iptables, которое захватывает трафик, предназначенный для Service's ClusterIP и ports и перенаправляет его к одному из backend pods. По умолчанию iptables случайным образом выбирает backend pod. Для получения подробностей см iptables режим прокси.
IPVS построен поверх Netfilter и балансирует нагрузки транспортного уровня как часть ядра Linux. IPVS может перенаправлять запросы к TCP- или UDP‑based services к реальным серверам и заставлять сервисы реальных серверов выглядеть как виртуальные сервисы на едином IP-адресе.
В режиме IPVS kube-proxy использует IPVS load balancing вместо iptables. IPVS разработан для балансировки нагрузки большого количества Services. Он имеет набор оптимизированных API и использует оптимизированные алгоритмы поиска вместо простого поиска правил в списке. Для получения подробностей см IPVS режим прокси.

Для получения подробностей о сравнении iptables и IPVS см Сравнение iptables и IPVS.

Привязка службы (externalTrafficPolicy)

Для службы NodePort и LoadBalancer Service запросы сначала отправляются на порт узла, затем на службу и, наконец, на Под, поддерживающий эту службу. Под, поддерживающий службу, может находиться не на том узле, который получает запросы. По умолчанию задняя рабочая нагрузка может быть доступна с любого IP-адреса узла и порта службы. Если Под не находится на узле, получающем запрос, запрос будет перенаправлен на узел, где расположен Под, что может привести к потере производительности.

Вы можете настроить привязку службы с помощью консоли или YAML.

С помощью консоли: При создании служб NodePort и LoadBalancer в консоли CCE вы можете настроить привязку службы, используя Привязка службы опцию.

С помощью YAML: Эта externalTrafficPolicy Параметр в Service используется для определения того, может ли внешний трафик быть направлен к локальным узлам или конечным точкам кластера. Ниже приведён пример:
```
apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
spec:
  externalTrafficPolicy: Local #  Service affinity
  ports:
  - name: service
    nodePort: 30000
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: NodePort
```
- Если значение externalTrafficPolicy равно Local, запросы, отправленные с IP-адрес узла:порт службы будет перенаправлен только к pod на локальном узле. Если узел не имеет pod, запросы будут приостановлены.
- Если значение externalTrafficPolicy равно Cluster, запросы перенаправляются внутри кластера, и бэкенд‑нагрузка может быть доступна с любого IP-адреса узла и порта службы.
- Если externalTrafficPolicy не задан, значение по умолчанию Cluster будет использоваться.

В таблице ниже сравниваются два варианта привязки сервиса (externalTrafficPolicy).

Таблица 1 Сравнение двух типов привязки сервиса
Категория	Уровень кластера (Cluster)	Уровень узла (Local)
Приложение	Этот режим применяется в сценариях, где не требуется высокая производительность и не необходимо сохранять исходный IP‑адрес клиента. Этот режим обеспечивает более равномерную нагрузку на каждый узел кластера.	Этот режим применяется в сценариях, где требуется высокая производительность и необходимо сохранять исходный IP‑адрес клиента. Однако трафик перенаправляется только на узел, где находится контейнер, и преобразование исходного IP‑адреса не выполняется.
Режим доступа	IP‑адреса и порты доступа всех узлов кластера могут получать доступ к рабочей нагрузке, связанной с Service.	Только IP‑адрес и порт доступа узла, где размещена нагрузка, могут получить доступ к нагрузке, связанной с Service.
Получение исходного IP‑адреса клиента	Исходный IP‑адрес клиента невозможно получить.	Исходный IP‑адрес клиента можно получить.
Производительность доступа	Доступ к Service может вызвать потерю производительности из‑за перенаправления маршрута, и следующий hop для пакета данных может быть другим узлом.	Доступ к Service не вызовет потери производительности из‑за перенаправления маршрута.
Балансировка нагрузки	Трафик имеет хорошую общую балансировку нагрузки.	Существует потенциальный риск несбалансированного распространения трафика.
Другой особый случай	Нет	В разных моделях сетей контейнеров и режимах перенаправления сервисов доступ к Services изнутри кластера может завершиться неудачей. Для подробностей см. Почему сервис не может быть доступен изнутри кластера.

Типы сервисов

Вы можете создать определённый тип Сервиса в кластере. Описание и сценарии применения различных типов Сервисов приведены в таблице ниже.

Тип сервиса	Описание	Сценарий применения
ClusterIP	ClusterIP Сервисы являются типом сервисов Kubernetes по умолчанию. Они назначают виртуальный IP‑адрес, доступный только внутри кластера, из блока Service CIDR кластера.	Сервисы, которым необходимо общаться только внутри кластера и которые не требуется раскрывать за пределами кластера. Например, если pod фронтенд‑приложения в кластере должен получить доступ к базе данных бекенда в том же кластере, вы можете создать ClusterIP Service для базы данных бекенда, чтобы обеспечить доступ к базе данных бекенда только изнутри кластера.
NodePort	NodePort Service открывает порт на каждом узле в кластере, позволяя внешнему трафику получать доступ к Service через <node-IP-address>:<node-port>.	Сценарии, когда требуется временный или низконагруженный доступ. Например, в тестовой среде вы можете использовать NodePort Service при развертывании и отладке веб‑приложения.
LoadBalancer	LoadBalancer Service добавляет внешний балансировщик нагрузки поверх NodePort Service и распределяет внешний трафик по нескольким pod внутри кластера. Он автоматически назначает внешний IP‑адрес, позволяя клиентам получить доступ. LoadBalancer Services обрабатывают трафик TCP и UDP на уровне 4 (транспортный слой) модели OSI. Их можно расширить для поддержки возможностей уровня 7 (прикладной слой), чтобы управлять трафиком HTTP и HTTPS.	Облачные приложения, требующие стабильной и простого в управлении точки входа для внешнего доступа. Например, в рабочей среде вы можете использовать LoadBalancer Services для публикации публичных сервисов, таких как веб‑приложения и API‑сервисы, в Интернет. Такие сервисы часто должны обрабатывать большой трафик, поддерживая высокую доступность.
DNAT	Служба DNAT предоставляет Преобразование сетевых адресов (NAT) для всех узлов в кластере, чтобы несколько узлов могли совместно использовать EIP.	Сервисы, которые требуют временного или низкоёмкого доступа из Интернета. Службы DNAT обеспечивают более высокую надёжность по сравнению со службами NodePort. При использовании службы DNAT нет необходимости привязывать EIP к отдельному узлу, и запросы всё равно могут распределяться по рабочей нагрузке, даже если какой‑то из внутренних узлов недоступен.
Headless Service	Для headless Service не выделяется IP‑адрес кластера. Когда клиент пытается получить доступ к backend pod и выполняет DNS‑запрос к Service, он получает список IP‑адресов backend pod. Это позволяет клиенту напрямую взаимодействовать с отдельными pod.	Приложения, которым требуется прямое взаимодействие с конкретными backend pod вместо использования прокси или балансировщиков нагрузки. Например, при развертывании stateful‑приложения (например, базы данных ClickHouse) можно использовать headless Service. Он позволяет pod‑приложениям напрямую обращаться к каждому pod ClickHouse и выполнять целенаправленные операции чтения и записи. Это повышает общую эффективность обработки данных.

Почему Служба не может быть доступна изнутри кластера

Если аффинность службы Службы установлена на уровне узла, то есть значение externalTrafficPolicy равно Local, Служба может не быть доступна изнутри кластера (конкретно, узлы или контейнеры). Информация, похожая на следующую, отображается:

upstream connect error or disconnect/reset before headers. reset reason: connection failure
Or
curl: (7) Failed to connect to 192.168.10.36 port 900: Connection refused

Часто происходит, что балансировщик нагрузки в кластере недоступен. Причина следующая: При создании Службы в Kubernetes, kube-proxy добавляет адрес доступа к балансировщику нагрузки в виде внешнего IP-адреса (External-IP, как показано в выводе команды) в iptables или IPVS. Если клиент внутри кластера инициирует запрос к балансировщику нагрузки, адрес считается внешним IP-адресом Службы, и запрос напрямую переадресуется kube-proxy, не проходя через балансировщик нагрузки за пределами кластера.

# kubectl get svc nginx
NAME    TYPE           CLUSTER-IP      EXTERNAL-IP                   PORT(S)        AGE
nginx   LoadBalancer   10.247.76.156   123.**.**.**,192.168.0.133   80:32146/TCP   37s

Когда значение externalTrafficPolicy равно Local, сбои доступа в разных моделях сети контейнеров и режимах переадресации сервисов следующие:

Note

Для многоподовой нагрузки убедитесь, что все pod доступны. В противном случае существует вероятность, что доступ к нагрузке не удался.
В кластере CCE Turbo, использующем Cloud Native Network 2.0, привязка на уровне узла поддерживается только когда бекенд Service подключён к pod с hostNetwork.
Таблица перечисляет только сценарии, в которых доступ может быть сбойным. Другие сценарии, не указанные в таблице, означают, что доступ нормален.

Тип сервиса Выпущено на сервере	Тип доступа	Местоположение инициирования запроса на клиенте	Кластер туннельной сети (IPVS)	Кластер сети VPC (IPVS)	Кластер туннельной сети (iptables)	Кластер сети VPC (iptables)
Сервис NodePort	Публичная/приватная сеть	Тот же узел, что и pod сервиса	Доступ к IP address и NodePort на узле, где находится сервер: Доступ успешен. Доступ к IP address и NodePort на любом узле, отличном от того, где находится сервер: Доступ не удался.	Доступ к IP address и NodePort на узле, где находится сервер: Доступ успешен. Доступ к IP address и NodePort на любом узле, отличном от того, где находится сервер: Доступ не удался.	Доступ к IP address и NodePort на узле, где находится сервер: Доступ успешен. Доступ к IP address и NodePort на любом узле, отличном от того, где находится сервер: Доступ не удался.	Доступ к IP address и NodePort на узле, где находится сервер: Доступ успешен. Доступ к IP address и NodePort на любом узле, отличном от того, где находится сервер: Доступ не удался.
		Разные узлы от service pod	Доступ к IP address и NodePort на узле, где находится сервер: Доступ успешен. Доступ к IP‑address и NodePort на другом узле: Доступ не удался.	Доступ к IP‑address и NodePort на узле, где расположен сервер: Доступ успешен. Доступ к частному IP‑address и NodePort на узле, где находится клиент: Доступ успешен. Доступ к публичному IP‑address и NodePort на узле, где запущен клиент: Доступ не удался. Доступ к IP‑address и NodePort на другом узле: Доступ не удался.	Доступ к IP‑address и NodePort на узле, где расположен сервер: Доступ успешен. Доступ к частному IP‑address и NodePort на узле, где находится клиент: Доступ успешен. Доступ к публичному IP‑address и NodePort на узле, где запущен клиент: Доступ не удался. Доступ к IP‑address и NodePort на другом узле: Доступ не удался.	Доступ к IP‑address и NodePort на узле, где расположен сервер: Доступ успешен. Доступ к частному IP-адресу и NodePort на узле, где находится клиент: Доступ выполнен успешно. Доступ к публичному IP-адресу и NodePort на узле, где работает клиент: Доступ не выполнен. Доступ к IP-адресу и NodePort на другом узле: Доступ не выполнен.
		Другие контейнеры на том же узле, что и сервисный pod	Доступ к IP-адресу и NodePort на узле, где расположен сервер: Доступ выполнен успешно. Доступ к IP-адресу и NodePort на любом узле, отличном от того, где расположен сервер: Доступ не выполнен.	Доступ к публичному IP-адресу и NodePort на узле, где расположен сервер: Доступ выполнен успешно. Доступ к частному IP-адресу и NodePort на узле, где расположен сервер: Доступ не выполнен. Доступ к IP-адресу и NodePort на любом узле, отличном от того, где расположен сервер: Доступ не выполнен.	Доступ к IP-адресу и NodePort на узле, где расположен сервер: Доступ выполнен успешно. Получить доступ к IP-адресу и NodePort на любом узле, отличном от того, где находится сервер: Доступ не выполнен.	Получить доступ к публичному IP-адресу и NodePort на узле, где находится сервер: Доступ выполнен успешно. Получить доступ к приватному IP-адресу и NodePort на узле, где находится сервер: Доступ не выполнен. Получить доступ к IP-адресу и NodePort на любом узле, отличном от того, где находится сервер: Доступ не выполнен.
		Другие контейнеры на разных узлах от service pod	Получить доступ к IP-адресу и NodePort на узле, где находится сервер: Доступ выполнен успешно. Получить доступ к приватному IP-адресу и NodePort на узле, где находится клиент: Доступ выполнен успешно. Получить доступ к IP-адресу и NodePort на другом узле: Доступ не выполнен.	Получить доступ к IP-адресу и NodePort на узле, где находится сервер: Доступ выполнен успешно. Получить доступ к приватному IP-адресу и NodePort на узле, где находится клиент: Доступ выполнен успешно. Доступ к IP-адресу и NodePort на другом узле: Доступ не выполнен.	Доступ к IP-адресу и NodePort на узле, где расположен сервер: Доступ выполнен успешно. Доступ к IP-адресу и NodePort на любом узле, отличном от того, где расположен сервер: Доступ не выполнен.	Доступ к IP-адресу и NodePort на узле, где расположен сервер: Доступ выполнен успешно. Доступ к IP-адресу и NodePort на любом узле, отличном от того, где расположен сервер: Доступ не выполнен.
LoadBalancer Service использует общий балансировщик нагрузки	Приватная сеть	Тот же узел, что и service pod	Доступ не выполнен.	Доступ не выполнен.	Доступ не выполнен.	Доступ не выполнен.
	Приватная сеть	Другие контейнеры на том же узле, что и service pod	Доступ не выполнен.	Доступ не выполнен.	Не удалось получить доступ.	Не удалось получить доступ.
LoadBalancer Service, использующий выделенный балансировщик нагрузки (Local), для соединения с NGINX Ingress Controller	Приватная сеть	Тот же узел, что и cceaddon-nginx-ingress-controller pod	Не удалось получить доступ.	Не удалось получить доступ.	Не удалось получить доступ.	Не удалось получить доступ.
	Приватная сеть	Другие контейнеры на том же узле, что и cceaddon-nginx-ingress-controller pod	Не удалось получить доступ.	Не удалось получить доступ.	Не удалось получить доступ.	Не удалось получить доступ.

Можно использовать следующие методы для решения этой проблемы:

(Рекомендуется) В кластере используйте ClusterIP Service или доменное имя сервиса для доступа.
Установить externalTrafficPolicy для Service в Кластер, что означает привязку сервиса на уровне кластера. Обратите внимание, что это влияет на устойчивость исходного адреса.
Предположим, что имя Service равно my-service и он находится в default пространстве имён. Пример команды kubectl выглядит следующим образом:
```
kubectl patch service my-service -n default --type='merge' -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'
```
Используя функцию сквозного проброса Service, kube-proxy обходится, когда для доступа используется адрес ELB. Сначала происходит обращение к балансировщику нагрузки ELB, затем к рабочей нагрузке. Для подробностей см. Настройка сквозной сети для LoadBalancer Service.
Note
В стандартном кластере CCE после настройки сквозной сети с помощью выделенного балансировщика нагрузки частный IP-адрес балансировщика недоступен с узла, где размещён pod рабочей нагрузки, или с других pod на том же узле.
Проброс сетевого взаимодействия не поддерживается для кластеров v1.15 или более ранних.
В режиме сети IPVS настройки проброса Сервисов, подключенных к одному балансировщику нагрузки, должны быть одинаковыми.
Если используется привязка сервиса на уровне узла (локальная), kubernetes.io/elb.pass-through автоматически устанавливается в onlyLocal для включения проброса.

Родительская тема: Сервисы

Поддержка Юридические документы