Облачная платформаВсе платформы

Обзор Service

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

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

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

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

Service

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

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

Например, Deployment используется для развертывания фронтенда и бэкенда приложения. Фронтенд вызывает бэкенд для вычислений, как показано в Figure 1.

Figure 1 Inter-pod access

Для решения этих проблем Kubernetes вводит Service, которые предоставляют стабильные сетевые интерфейсы и постоянные IP‑адреса для pod‑ов. Вы можете задать эти IP‑адреса с помощью Service CIDR blocks при создании кластера. Блоки Service CIDR используются для назначения IP‑адресов Service. Service использует селектор меток для определения целевых pod‑ов и применяет балансировку нагрузки для равномерного распределения трафика между ними. Эта абстракция устраняет сложность прямого доступа к отдельным pod‑ам и повышает доступность и эффективность рабочих нагрузок.

В приведённом выше примере для backend pod‑ов создаётся Service, который используется frontend pod‑ом для доступа к этим backend pod‑ам. Таким образом, frontend pod остаётся неизменным при любых изменениях backend pod‑ов, как показано в Figure 2.

Figure 2 Доступ к pod‑ам через Service

Endpoint и EndpointSlice

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

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

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

Категория	Endpoint	EndpointSlice	Различие
Архитектура	Все эндпоинты хранятся в одном объекте.	Эндпоинты хранятся в разных шардах.	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 для обработки и фильтрации большого количества пакетов данных. Она позволяет гибко задавать последовательности правил, привязываемых к различным точкам в конвейере обработки пакетов. При использовании iptables kube-proxy реализует NAT и балансировку нагрузки в хуке NAT pre‑routing. Для каждого Service kube-proxy устанавливает правило iptables, которое захватывает трафик, направленный к ClusterIP Service и его портам, и перенаправляет его к одному из backend pod‑ов. По умолчанию iptables выбирает backend pod случайным образом. Подробнее см.iptables proxy mode.
IPVS построен поверх Netfilter и балансирует нагрузки транспортного уровня в ядре Linux. IPVS может направлять запросы к сервисам на основе TCP или UDP к реальным серверам, делая сервисы реальных серверов выглядеть как виртуальные сервисы на едином IP‑адресе.
В режиме IPVS kube-proxy использует балансировку нагрузки IPVS вместо iptables. IPVS разработан для балансировки нагрузки большого количества Service. Он обладает набором оптимизированных API и использует оптимизированные поисковые алгоритмы вместо простого перебора правил. Подробнее см.IPVS proxy mode.

Подробное сравнение iptables и IPVS см.Comparing iptables and IPVS.

Service Affinity (externalTrafficPolicy)

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

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

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

Через 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, запросы, отправленные с <node-IP-address:Service-port> будут перенаправлены только к pod‑у на локальном узле. Если узел не имеет pod‑а, запросы будут приостановлены.
- Если значение externalTrafficPolicy равно Cluster, запросы будут перенаправлены внутри кластера, и backend‑нагрузка будет доступна с любого IP‑адреса узла и порта Service.
- Если externalTrafficPolicy не задан, будет использоваться значение по умолчанию Cluster.

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

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

Типы Service

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

Тип Service	Описание	Сценарий применения
ClusterIP	ClusterIP Service — тип Service по умолчанию в 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 Service обрабатывает TCP и UDP трафик на уровне 4 (транспортный уровень) модели OSI. При необходимости его можно расширить для поддержки возможностей уровня 7 (прикладной уровень) для управления HTTP и HTTPS трафиком.	Облачные приложения, которым нужен стабильный и лёгкий в управлении вход для внешнего доступа. Например, в продуктивной среде можно использовать LoadBalancer Service для публикации публичных сервисов, таких как веб‑приложения и API‑сервисы, в Интернет. Такие сервисы часто должны обрабатывать большой объём трафика, сохраняя высокую доступность.
DNAT	DNAT Service предоставляет Network Address Translation (NAT) NAT для всех узлов кластера, позволяя нескольким узлам использовать один EIP.	Сервисы, которым нужен временный или низкоёмкостный доступ из Интернета. DNAT Service обеспечивает более высокую надёжность, чем NodePort Service. При DNAT Service не требуется привязывать EIP к отдельному узлу, запросы могут распределяться между нагрузкой, даже если один из узлов кластера недоступен.
	Headless Service	Приложения, которым требуется прямое взаимодействие с конкретными backend pod‑ами, без использования прокси или балансировщиков. Например, при развертывании stateful‑приложения (например, базы данных ClickHouse) можно использовать Headless Service. Он позволяет pod‑ам приложения напрямую обращаться к каждому pod ClickHouse и выполнять целенаправленные операции чтения и записи. Это повышает общую эффективность обработки данных.

Why a Service Fails to Be Accessed from Within the Cluster

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

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

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

# kubectl get svc nginxNAME    TYPE           CLUSTER-IP      NAME    TYPE           CLUSTER-IP      EXTERNAL-IP                   PORT(S)        AGE
nginx   LoadBalancer   10.247.76.156                      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 привязка уровня узла поддерживается только когда backend Service подключён к pod‑у с hostNetwork.	Тип доступа	Местоположение инициирования запроса на клиенте	Tunnel Network Cluster (IPVS)	VPC Network Cluster (IPVS)	Tunnel Network Cluster (iptables)	VPC Network Cluster (iptables)
NodePort Service	Публичная/приватная сеть	Тот же узел, что и pod сервиса	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.
		Different nodes from the service pod	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к другому узлу через его IP‑адрес и порт: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через приватный IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через публичный IP‑адрес и порт узла: доступ не удался. Доступ к другому узлу через его IP‑адрес и порт: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через приватный IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через публичный IP‑адрес и порт узла: доступ не удался. Доступ к другому узлу через его IP‑адрес и порт: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через приватный IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через публичный IP‑адрес и порт узла: доступ не удался. Доступ к другому узлу через его IP‑адрес и порт: доступ не удался.
		Other containers on the same node as the service pod	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.	Доступ к узлу, где находится сервер, через публичный IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится сервер, через приватный IP‑адрес и порт узла: доступ не удался. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.	Доступ к узлу, где находится сервер, через публичный IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится сервер, через приватный IP‑адрес и порт узла: доступ не удался. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.
		Other containers on different nodes from the service pod	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через приватный IP‑адрес и порт узла: доступ успешен. Доступ к другому узлу через IP‑адрес и порт узла: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к узлу, где находится клиент, через приватный IP‑адрес и порт узла: доступ успешен. Доступ к другому узлу через IP‑адрес и порт узла: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.	Доступ к узлу, где находится сервер, через IP‑адрес и порт узла: доступ успешен. Доступ к любому другому узлу через IP‑адрес и порт узла, отличному от узла с сервером: доступ не удался.
LoadBalancer Service using a shared load balancer	Private network	Same node as the service pod	The access failed.	The access failed.	The access failed.	The access failed.
LoadBalancer Service using a shared load balancer	Private network	Other containers on the same node as the service pod	The access failed.	The access failed.	The access failed.	The access failed.

The following methods can be used to solve this problem:

(Recommended) В кластере используйте ClusterIP Service или доменное имя Service для доступа.
Set externalTrafficPolicy of the Service to Cluster, что означает привязку уровня кластера. Обратите внимание, что это влияет на постоянство исходного адреса.
Предположим, что Service называется my-service и находится в default namespace. Пример команды kubectl ниже:
```
kubectl patch service my-service -n default --type='merge' -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'
```
Leveraging the pass-through feature of the Service, kube-proxy is bypassed when the ELB address is used for access. The ELB load balancer is accessed first, and then the workload. For details, see Configuring Passthrough Networking for a LoadBalancer Service.
Note
In a CCE standard cluster, after passthrough networking is configured using a dedicated load balancer, the private IP address of the load balancer cannot be accessed from the node where a workload pod resides or other pods on the same node as the workload.
Passthrough networking is not supported for clusters of 1.15 or earlier.
In IPVS, the passthrough settings of Services connected to the same load balancer must be the same.
If node-level (local) service affinity is used, kubernetes.io/elb.pass-through is automatically set to onlyLocal to enable passthrough networking.

Parent topic: Services

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

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