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

Обзор Service

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

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

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

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

Service

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

Pod может быть удалён и воссоздан в любой момент контроллером, например Deployment. Если pod будет воссоздан, доступ к нему может потерпеть неудачу.

IP-адрес не может быть назначен pod до его запуска. До запуска pod его IP-адрес неизвестен.

Приложения обычно работают на нескольких pod, использующих один и тот же образ. Доступ к pod по отдельности неэффективен.

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

Figure 1 Взаимный доступ между pod

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

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

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

Endpoint and 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 endpoint'ов. Если это ограничение превышено, дополнительные endpoint'ы отбрасываются и не включаются в объект.

EndpointSlices являются альтернативой традиционному API Endpoints, представленной как альфа‑функция в Kubernetes v1.16 и продвинутой до стабильной в v1.21. Они решают ограничения производительности Endpoints в больших кластерах, распределяя сетевые endpoint'ы.

Каждый Service связан с одной или несколькими EndpointSlices.

По умолчанию каждый EndpointSlice может содержать до 100 endpoint'ов. Когда это ограничение превышено, Kubernetes создает дополнительные EndpointSlices для размещения оставшихся endpoint'ов.

Endpoint'ы группируются по протоколу, порту и имени Service.

EndpointSlices поддерживают типы адресов IPv4, IPv6 и полностью квалифицированные доменные имена (FQDN).

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

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

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

kube-proxy является ключевым компонентом кластера Kubernetes. Он используется для балансировки нагрузки и перенаправления данных между Service и его бэкенд‑подами. CCE поддерживает следующие Service forwarding modes: iptables, nftables (v1.35 и позже), и IPVS.

nftables — это высокопроизводительный фреймворк фильтрации и управления пакетами, встроенный в ядро Linux, предназначенный для замены iptables. Он устраняет узкие места производительности и ограничения масштабируемости, обеспечивая более эффективный и гибкий контроль сетевого трафика. Построенный на механизме хуков Netfilter, nftables использует единый конфигурационный фреймворк для интеграции управления правилами для нескольких протоколов (IPv4, IPv6, ARP и другие), устраняя необходимость в отдельных наборах правил для каждого протокола. Он также оптимизирует сопоставление правил с помощью хеш‑структур данных, повышая эффективность в сценариях высокой конкуренции.

В режиме nftables kube-proxy использует nftables вместо iptables для настройки переадресации пакетов и правил NAT. По сравнению с iptables nftables предлагает более простой синтаксис и более гибкую организацию правил. Он поддерживает инкрементные обновления правил путем изменения отдельных правил без замены полного набора, что оптимизирует производительность управления правилами в сценариях крупномасштабных сервисов и лучше учитывает рост кластера Kubernetes. Подробнее см. nftables proxy mode.

iptables — это функция ядра Linux для обработки и фильтрации большого количества пакетов данных. Она позволяет гибко привязывать последовательности правил к различным хукам в конвейере обработки пакетов. Когда используется iptables, kube-proxy реализует NAT и балансировку нагрузки в хуке NAT pre-routing. Для каждой Service kube-proxy устанавливает правило iptables, которое перехватывает трафик, предназначенный для ClusterIP и портов Service, и перенаправляет его к одному из backend‑подов. По умолчанию iptables случайным образом выбирает backend‑под. Подробнее см. iptables proxy mode.

IPVS построен поверх Netfilter и балансирует нагрузки транспортного уровня как часть ядра Linux. IPVS может направлять запросы к сервисам на основе TCP или UDP к реальным серверам и делать сервисы реальных серверов видимыми как виртуальные сервисы на одном IP‑адресе.

В режиме IPVS kube-proxy использует балансировку нагрузки IPVS вместо iptables. IPVS предназначен для балансировки нагрузки для большого количества Service. Он имеет набор оптимизированных API и использует оптимизированные алгоритмы поиска вместо простого перебора правил в списке. Подробнее см. IPVS proxy mode.

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

Service Affinity (externalTrafficPolicy)

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

Вы можете настроить service affinity с помощью консоли или YAML.

Using the console: При создании NodePort и LoadBalancer Service в консоли CCE вы можете настроить service affinity, используя параметр Service Affinity.

Using 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, запросы, отправленные из \u003cnode-IP-address:Service-port\u003e, будут перенаправлены только к pod на локальном узле. Если на узле нет pod, запросы приостанавливаются.

Если значение externalTrafficPolicy равно Cluster, запросы перенаправляются внутри кластера, и backend‑нагрузка доступна с любого node IP address и service port.

Если externalTrafficPolicy не задан, будет использовано значение по умолчанию Cluster.

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

Table 1 Сравнение двух типов service affinity
Категория	Уровень кластера (Cluster)	Уровень узла (Local)
Приложение	Этот режим применяется в сценариях, где не требуется высокая производительность и не необходимо сохранять исходный IP-адрес клиента. Этот режим обеспечивает более сбалансированную нагрузку на каждый узел в кластере.	Этот режим применяется в сценариях, где требуется высокая производительность и необходимо сохранять исходный IP-адрес клиента. Однако трафик перенаправляется только на узел, где находится контейнер, и трансляция исходного IP-адреса не выполняется.
Режим доступа	IP-адреса и порты доступа всех узлов в кластере могут обращаться к нагрузке, связанной с Service.	Только IP-адрес и порт доступа узла, на котором расположена нагрузка, могут обращаться к нагрузке, связанной с Service.
Получение исходного IP-адреса клиента	Исходный IP-адрес клиента не может быть получен.	Исходный IP-адрес клиента может быть получен.
Производительность доступа	Доступ к Service может вызвать потерю производительности из‑за перенаправления маршрута, и следующий хоп для пакета данных может быть другим узлом.	Доступ к 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 кластера.	Service, которые необходимо лишь взаимодействовать друг с другом внутри кластера и не требуют экспозиции за пределами кластера. Например, если pod фронтенд‑приложения в кластере должен получить доступ к базе данных бекенда в том же кластере, вы можете создать ClusterIP Service для базы данных бекенда, чтобы обеспечить доступ к базе данных бекенда только внутри кластера.
NodePort	A NodePort Service opens a port on each node in a cluster to allow external traffic to access the Service through <node-IP-address>:<node-port>.	Сценарии, когда требуется временный или низкообъёмный доступ. Например, в тестовой среде вы можете использовать сервис NodePort при развертывании и отладке веб‑приложения.
LoadBalancer	Сервис LoadBalancer добавляет внешний балансировщик нагрузки поверх сервиса NodePort и распределяет внешний трафик между несколькими pod‑ами в кластере. Он автоматически назначает внешний IP‑адрес, чтобы обеспечить доступ клиентам. Сервисы LoadBalancer обрабатывают трафик TCP и UDP на уровне 4 (транспортный уровень) модели OSI. Их можно расширить для поддержки возможностей уровня 7 (уровень приложений) для управления трафиком HTTP и HTTPS.	Облачные приложения, которым требуется стабильная и простая в управлении точка входа для внешнего доступа. Например, в производственной среде вы можете использовать сервисы LoadBalancer для публикации публичных сервисов, таких как веб‑приложения и API‑сервисы, в Интернет. Такие сервисы часто должны обрабатывать большой объём трафика, обеспечивая высокую доступность.
DNAT	Сервис DNAT предоставляет Network Address Translation (NAT) для всех узлов в кластере, чтобы несколько узлов могли использовать общий EIP.	Сервисы, которым требуется временный или низкообъёмный доступ из Интернета. Сервисы DNAT обеспечивают более высокую надёжность, чем сервисы NodePort. При использовании сервиса DNAT нет необходимости привязывать EIP к отдельному узлу, и запросы всё равно могут распределяться между рабочими нагрузками, даже если один из узлов выходит из строя.
Headless Services	Для безголовых сервисов (headless Services) IP‑адрес кластера не выделяется. Когда клиент пытается обратиться к backend‑pod и выполняет DNS‑запрос к Сервису, он получает список IP‑адресов backend‑pod‑ов. Это позволяет клиенту напрямую взаимодействовать с отдельными pod‑ами.	Приложения, которым требуется прямое взаимодействие с конкретными backend‑pod, вместо использования прокси‑серверов или балансировщиков нагрузки. Например, при развертывании stateful‑приложения (например, базы данных ClickHouse) можно использовать безголовый сервис. Он позволяет pod‑ам приложения напрямую обращаться к каждому pod‑у ClickHouse и выполнять целенаправленные операции чтения и записи. Это повышает общую эффективность обработки данных.

Почему Service недоступен изнутри кластера

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

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

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

Note

Для многоподовой рабочей нагрузки убедитесь, что все pod доступны. В противном случае существует вероятность, что доступ к рабочей нагрузке будет невозможен.

В таблице перечислены только сценарии, при которых доступ может быть невозможен. Другие сценарии, не указанные в таблице, означают, что доступ работает нормально.

Для кластеров CCE, использующих IPVS, установите externalTrafficPolicy в Local для привязки Service на уровне узла. Для кластеров CCE Turbo с отключенным DataPlane V2 поддержка привязки на уровне узла возможна только когда бэкенд Service использует hostNetwork.

Тип Server Service	Тип доступа	Источник запросов клиента	Кластер Tunnel Network	Кластер VPC Network (DataPlane V2 отключен. Если включен, см. Clusters with DataPlane V2 Enabled.)	Кластер CCE Turbo (DataPlane V2 отключен. Если включен, см. Clusters with DataPlane V2 Enabled.)
NodePort Service	Публичная/приватная сеть	Тот же node, что и service pod	Доступ через node IP + NodePort на server node: Успех Доступ через node IP + NodePort на non-server node: Ошибка	Доступ через node IP + NodePort на server node: Успех Доступ через node IP + NodePort на non-server node: Ошибка	Доступно
		Другой node, чем service pod	Доступ через node IP + NodePort на server node: Успех Доступ через node IP + NodePort на другом node: Ошибка	Доступ через node IP + NodePort на server node: Успех Доступ через node private IP + NodePort на client node: Успех Доступ через node EIP + NodePort на client node: Ошибка Доступ через node IP + NodePort на другом node: Ошибка	Доступно
		Другие containers на том же node, что и service pod	Доступ через node IP + NodePort на серверном узле: Success Доступ через node IP + NodePort на несерверном узле: Failure	Доступ через node EIP + NodePort на серверном узле: Success Доступ через node private EIP + NodePort на серверном узле: Failure Доступ через node IP + NodePort на несерверном узле: Failure	Accessible
		Другие контейнеры на другом узле, отличном от service pod	Доступ через node IP + NodePort на серверном узле: Success Доступ через node private IP + NodePort на клиентском узле: Success Доступ через node IP + NodePort на другом узле: Failure	Доступ через node IP + NodePort на серверном узле: Success Доступ через node private IP + NodePort на клиентском узле: Success Доступ через node IP + NodePort на другом узле: Failure	Accessible
LoadBalancer Service, использующий выделенный load balancer	Приватная сеть	Тот же узел, что и service pod	Недоступно	Недоступно	Доступно
LoadBalancer Service, использующий выделенный load balancer	Приватная сеть	Другие контейнеры на том же узле, что и service pod	Недоступно	Недоступно	Доступно

Для кластеров CCE, использующих iptables, установите externalTrafficPolicy в Local для привязки Service на уровне узла. Для кластеров CCE Turbo with DataPlane V2 disabled, привязка на уровне узла поддерживается только когда бэкенд Service использует hostNetwork.

Server Service Type	Access Type	Client Request Source	Tunnel Network Cluster	VPC Network Cluster (DataPlane V2 отключён. Если включено, см. Clusters with DataPlane V2 Enabled.)	CCE Turbo Cluster (DataPlane V2 отключён. Если включён, см. Clusters with DataPlane V2 Enabled.)
NodePort Service	Public/Private network	Тот же узел, что и service pod	Доступ через node IP + NodePort на серверном узле: Успешно Доступ через node IP + NodePort на узле, не являющемся сервером: Неудача	Доступ через node IP + NodePort на серверном узле: Успешно Доступ через node IP + NodePort на узле, не являющемся сервером: Неудача	Доступно
		Другой узел, чем service pod	Доступ через node IP + NodePort на серверном узле: Успешно Доступ через node private IP + NodePort на клиентском узле: Успешно Доступ через node EIP + NodePort на клиентском узле: Неудача Доступ через node IP + NodePort на другом узле: Неудача	Доступ через node IP + NodePort на серверном узле: Успешно Доступ через частный IP узла + NodePort на клиентском узле: Успешно Доступ через EIP узла + NodePort на клиентском узле: Не удалось Доступ через IP узла + NodePort на другом узле: Не удалось	Доступно
		Другие контейнеры на том же узле, что и pod сервиса	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP узла + NodePort на несерверном узле: Не удалось	Доступ через EIP узла + NodePort на серверном узле: Успешно Доступ через частный EIP узла + NodePort на серверном узле: Не удалось Доступ через IP узла + NodePort на несерверном узле: Не удалось	Доступно
		Другие контейнеры на другом узле, отличном от pod сервиса	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP узла + NodePort на несерверном узле: Не удалось	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP‑узла + NodePort на узле без сервера: Failure	Accessible
LoadBalancer Service с использованием dedicated load balancer	Private network	Тот же узел, что и service pod	Inaccessible	Inaccessible	Accessible
	Private network	Другие контейнеры на том же узле, что и service pod	Inaccessible	Inaccessible	Accessible

Для кластеров с включённым DataPlane V2 установите externalTrafficPolicy в Local для привязки Service на уровне узла.

Note

DataPlane V2 поддерживается только в кластерах CCE VPC-network и Turbo. После включения он полностью заменяет kube-proxy, устраняя необходимость настройки service forwarding mode.

Server Service Type	Access Type	Client Request Source	VPC Network Cluster (DataPlane V2 Enabled to Replace kube-proxy)	CCE Turbo Cluster (DataPlane V2 Enabled to Replace kube-proxy)
NodePort Service	Public/Private network	Тот же узел, что и pod сервиса	Доступ через IP узла + NodePort на серверном узле: Успех Доступ через частный IP узла + NodePort на несерверном узле: Успех Доступ через EIP узла + NodePort на несерверном узле: Неудача	Доступ через IP узла + NodePort на серверном узле: Успех Доступ через частный IP узла + NodePort на несерверном узле: Успех Доступ через EIP узла + NodePort на несерверном узле: Неудача
		Другой узел, чем pod сервиса	Доступ через IP узла + NodePort на серверном узле: Успех Доступ через частный IP-адрес узла + NodePort на узле без сервера: Success Доступ через EIP узла + NodePort на узле без сервера: Failure	Доступ через IP-адрес узла + NodePort на серверном узле: Success Доступ через частный IP-адрес узла + NodePort на узле без сервера: Success Доступ через EIP узла + NodePort на узле без сервера: Failure
		Другие контейнеры на том же узле, что и service pod	Доступ через IP-адрес узла + NodePort на серверном узле: Success Доступ через IP-адрес узла + NodePort на другом узле: Failure	Доступ через IP-адрес узла + NodePort на серверном узле: Success Доступ через IP-адрес узла + NodePort на другом узле: Failure
		Другие контейнеры на другом узле, отличном от service pod	Доступ через IP-адрес узла + NodePort на серверном узле: Success Доступ через частный IP-адрес узла + NodePort на клиентском узле: Success Доступ через IP-адрес узла + NodePort на другом узле: Failure	Доступ через IP-адрес узла + NodePort на серверном узле: Success Доступ через приватный IP узла + NodePort на клиентском узле: Успешно Доступ через IP узла + NodePort на другом узле: Не удалось
LoadBalancer Service с использованием выделенного балансировщика нагрузки	Приватная сеть	Тот же узел, что и service pod	Недоступно	Недоступно
	Приватная сеть	Другие контейнеры на том же узле, что и service pod	Недоступно	Доступно

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

(Рекомендуется) В кластере используйте ClusterIP Service или доменное имя сервиса для доступа.

Установите externalTrafficPolicy сервиса в значение Cluster, что означает аффинность сервиса на уровне кластера. Обратите внимание, что это влияет на постоянство исходного адреса.

Предположим, что имя Service — my-service и оно находится в пространстве имён default. Пример команды kubectl приведён ниже:

kubectl patch service my-service -n default --type='merge' -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'

Используя функцию проброса (pass‑through) Service, kube-proxy обходится, когда для доступа используется адрес ELB. Сначала обращаются к балансировщику нагрузки ELB, а затем к рабочей нагрузке. Подробности см. в Configuring Passthrough Networking for a LoadBalancer Service.

Note

В стандартном кластере CCE после настройки passthrough networking с использованием выделенного load balancer частный IP-адрес load balancer недоступен с узла, на котором находится pod рабочей нагрузки, или с других pod на том же узле, что и рабочая нагрузка.

Эта функция доступна только в кластерах версии v1.19 и новее.

В IPVS параметры passthrough для Services, подключённых к одному и тому же load balancer, должны быть одинаковыми.

Если используется привязка сервиса уровня узла (local), kubernetes.io/elb.pass-through автоматически устанавливается в onlyLocal для включения passthrough networking.

Родительская тема: Services

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

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