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

Обзор Service

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

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

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

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

Service

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

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

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

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

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

Figure 1 Inter-pod access

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

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

Figure 2 Accessing pods through a Service

Endpoint and EndpointSlice

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

Endpoints — традиционный объект ресурса для обнаружения сервисов. Endpoint представляет собой набор конечных точек всех pod‑ов, связанных с Service. Endpoint автоматически создаётся для каждого Service с определённым селектором. Он сохраняет список IP‑адресов и портов всех соответствующих pod‑ов. После удаления или воссоздания pod его IP‑адрес может измениться. Endpoint обновляет IP‑адрес и порт pod‑а соответственно, чтобы Service продолжал направлять трафик к правильным pod‑ам.

Ключевые возможности Endpoints включают:

Каждый объект Endpoint соответствует единственной Service.

Каждый Endpoint хранит IP-адреса и порты всех backend pods, связанных с Service.

Любое изменение статуса pod приводит к обновлению соответствующего объекта Endpoint.

По умолчанию объект Endpoint может содержать до 1000 endpoints. Если это ограничение превышено, дополнительные endpoints отбрасываются и не включаются в объект.

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

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

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

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

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

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

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

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

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

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 предназначен для балансировки нагрузки для большого количества Services. Он имеет набор оптимизированных API и использует оптимизированные алгоритмы поиска вместо простого поиска правил в списке. Для получения подробной информации см. IPVS proxy mode.

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

Service Affinity (externalTrafficPolicy)

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

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

С помощью консоли: При создании NodePort и LoadBalancer Services в консоли CCE вы можете настроить Service Affinity, используя параметр 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

If the value of externalTrafficPolicy is Local, requests sent from <node-IP-address:Service-port> will be forwarded only to the pod on the local node. If the node does not have a pod, the requests are suspended.

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

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

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

Table 1 Сравнение двух типов Service Affinity
Категория	Уровень кластера (Cluster)	Node-level (Local)
Application scenario	Этот режим применяется к сценариям, где не требуется высокая производительность и не нужно сохранять исходный IP-адрес клиента. Этот режим обеспечивает более сбалансированную нагрузку на каждый узел в кластере.	Этот режим применяется к сценариям, где требуется высокая производительность и необходимо сохранять исходный IP-адрес клиента. Однако трафик перенаправляется только на узел, где находится контейнер, и трансляция исходного IP-адреса не выполняется.
Access mode	IP-адреса и порты доступа всех узлов в кластере могут обращаться к рабочей нагрузке, связанной с Service.	Только IP-адрес и порт доступа узла, на котором расположена рабочая нагрузка, могут обращаться к рабочей нагрузке, связанной с Service.
Obtaining client source IP address	Исходный IP-адрес клиента не может быть получен.	Исходный IP-адрес клиента может быть получен.
Access performance	Доступ к Service может привести к потере производительности из‑за перенаправления маршрута, и следующий хоп для пакета данных может быть другим узлом.	Доступ к Service не приведёт к потере производительности из‑за перенаправления маршрута.
Load balancing	Распространение трафика обеспечивает хорошую общую балансировку нагрузки.	Существует потенциальный риск несбалансированного распространения трафика.
Другой особый случай	Нет	В разных моделях сетей контейнеров и режимах переадресации сервисов доступ к 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	NodePort Service открывает порт на каждом узле кластера, позволяя внешнему трафику получать доступ к Service через \u003cnode-IP-address\u003e:\u003cnode-port\u003e.	Сценарии, когда требуется временный или низкообъёмный доступ. Например, в тестовой среде вы можете использовать NodePort Service при развертывании и отладке веб‑приложения.
LoadBalancer	LoadBalancer Service добавляет внешний балансировщик нагрузки поверх NodePort Service и распределяет внешний трафик между несколькими pod‑ами в кластере. Он автоматически назначает внешний IP‑адрес, чтобы обеспечить доступ клиентам. LoadBalancer Services обрабатывают трафик TCP и UDP на уровне Layer 4 (транспортный уровень) модели OSI. При необходимости их можно расширить для поддержки возможностей Layer 7 (уровень приложений) для управления трафиком HTTP и HTTPS.	Облачные приложения, которым требуется стабильный, легко управляемый вход для внешнего доступа. Например, в производственной среде вы можете использовать LoadBalancer Services для публикации публичных сервисов, таких как веб‑приложения и API‑сервисы, в Интернет. Эти сервисы часто должны обрабатывать большой объём трафика, обеспечивая высокую доступность.
DNAT	DNAT Service предоставляет Network Address Translation (NAT) для всех узлов в кластере, чтобы несколько узлов могли использовать общий EIP.	Сервисы, которым требуется временный или низкообъёмный доступ из Интернета. DNAT Services обеспечивают более высокую надёжность, чем NodePort Services. При использовании DNAT Service нет необходимости привязывать EIP к отдельному узлу, и запросы всё равно могут распределяться между рабочими нагрузками, даже если один из внутренних узлов недоступен.
Headless Service	Для headless Services IP‑адрес кластера не выделяется. Когда клиент пытается получить доступ к backend‑pod и выполняет DNS‑запрос к Service, он получает список IP‑адресов backend‑pod‑ов. Это позволяет клиенту напрямую взаимодействовать с отдельными pod‑ами.	Приложения, которым требуется прямое взаимодействие с конкретными backend‑pod, без использования прокси‑серверов или балансировщиков нагрузки. Например, при развертывании stateful‑приложения (например, базы данных ClickHouse) вы можете использовать headless Service. Он позволяет 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 192.168.10.36 port 900: Connection refused

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

# 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

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

В кластере CCE Turbo, использующем Cloud Native Network 2.0, node-level affinity поддерживается только когда backend Service подключён к pod с hostNetwork.

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

Service Type Released on the Server	Access Type	Request Initiation Location on the Client	Tunnel Network Cluster (IPVS)	VPC Network Cluster (IPVS)	Tunnel Network Cluster (iptables)	VPC Network Cluster (iptables)
NodePort Service	Public/Private network	Same node as the service pod	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: Доступ выполнен успешно. Доступ к любому узлу через IP‑адрес и порт узла, отличному от того, где расположен сервер: Доступ не выполнен.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: Доступ выполнен успешно. Доступ к любому узлу через IP‑адрес и порт узла, отличному от того, где расположен сервер: Доступ не выполнен.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: Доступ выполнен успешно. Доступ к любому узлу через IP‑адрес и порт узла, отличному от того, где расположен сервер: Доступ не выполнен.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: Доступ выполнен успешно. Доступ к любому узлу через IP‑адрес и порт узла, отличному от того, где расположен сервер: Доступ не выполнен.
		Разные узлы от service pod	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: Доступ выполнен успешно. Доступ к другому узлу через его IP‑адрес и порт: Доступ не выполнен.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: Доступ выполнен успешно. Доступ к узлу, где находится клиент, через частный IP‑адрес и порт узла: Доступ выполнен успешно. Доступ к узлу, где находится клиент, через публичный IP‑адрес и порт узла: Доступ не выполнен. Доступ к другому узлу через его IP‑адрес и порт: Доступ не выполнен.	Доступ к узлу, где находится сервер, через IP-адрес узла и порт: доступ выполнен успешно. Доступ к узлу, где находится клиент, через частный IP-адрес узла и порт: доступ выполнен успешно. Доступ к узлу, где находится клиент, через публичный IP-адрес узла и порт: доступ не выполнен. Доступ к другому узлу через его IP-адрес и порт: доступ не выполнен.	Доступ к узлу, где находится сервер, через IP-адрес узла и порт: доступ выполнен успешно. Доступ к узлу, где находится клиент, через частный IP-адрес узла и порт: доступ выполнен успешно. Доступ к узлу, где находится клиент, через публичный IP-адрес узла и порт: доступ не выполнен. Доступ к другому узлу через его IP-адрес и порт: доступ не выполнен.
		Другие контейнеры на том же узле, что и service pod.	Доступ к узлу, где находится сервер, через IP-адрес узла и порт: доступ выполнен успешно. Доступ к любому узлу через IP-адрес узла и порт, кроме того, где находится сервер: доступ не выполнен.	Доступ к узлу, где находится сервер, через публичный IP-адрес узла и порт: доступ выполнен успешно. Доступ к узлу, где находится сервер, через частный IP-адрес узла и порт: доступ не выполнен. Доступ к любому узлу через IP-адрес узла и порт, кроме того, где находится сервер: доступ не выполнен.	Доступ к узлу, где находится сервер, через IP-адрес узла и порт: доступ выполнен успешно. Доступ к любому узлу через IP‑адрес и порт узла, кроме того, где расположен сервер: доступ не удался.	Доступ к узлу, где расположен сервер, через публичный IP‑адрес и порт узла: доступ выполнен успешно. Доступ к узлу, где расположен сервер, через приватный IP‑адрес и порт узла: доступ не удался. Доступ к любому узлу через IP‑адрес и порт узла, кроме того, где расположен сервер: доступ не удался.
		Другие контейнеры на разных узлах от service pod.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: доступ выполнен успешно. Доступ к узлу, где находится клиент, через приватный IP‑адрес и порт узла: доступ выполнен успешно. Доступ к другому узлу через его IP‑адрес и порт: доступ не удался.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: доступ выполнен успешно. Доступ к узлу, где находится клиент, через приватный IP‑адрес и порт узла: доступ выполнен успешно. Доступ к другому узлу через его IP‑адрес и порт: доступ не удался.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: доступ выполнен успешно. Доступ к любому узлу через IP‑адрес и порт узла, кроме того, где расположен сервер: доступ не удался.	Доступ к узлу, где расположен сервер, через IP‑адрес и порт узла: доступ выполнен успешно. Доступ к любому узлу через IP‑адрес и порт узла, кроме того, где расположен сервер: доступ не удался.
LoadBalancer Service, использующий shared load balancer	Private network	Тот же узел, что и service pod	The access failed.	The access failed.	The access failed.	The access failed.
LoadBalancer Service, использующий 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.

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

(Recommended) В кластере используйте 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 load balancer, а затем к рабочей нагрузке. Подробности см. Configuring Passthrough Networking for a LoadBalancer Service.

Note

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

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

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

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

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

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

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