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

Обзор сервиса

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

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

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

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

Сервис

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

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

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

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

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

Figure 1 Inter-pod access

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

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

Figure 2 Accessing pods through a Service

Эндпоинт и EndpointSlice

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

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

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

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

Каждый Endpoint хранит IP-адреса и порты всех backend pod, связанных с 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 перечислены в таблице ниже.

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 использует единый конфигурационный фреймворк для интеграции управления правилами across multiple protocols (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.

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

Service Affinity (externalTrafficPolicy)

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

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

Using the console: При создании Service типа NodePort и LoadBalancer в консоли 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

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
Category	Cluster-level (Cluster)	Node-level (Local)
Application	Этот режим применяется в сценариях, где не требуется высокая производительность и не нужно сохранять исходный IP‑адрес клиента. Этот режим обеспечивает более сбалансированную нагрузку на каждый узел в кластере.	Этот режим применяется в сценариях, где требуется высокая производительность и необходимо сохранять исходный IP‑адрес клиента. Однако трафик перенаправляется только на узел, где находится контейнер, и трансляция исходного IP‑адреса не выполняется.
Access mode	IP‑адреса и порты доступа всех узлов в кластере могут обращаться к рабочей нагрузке, связанной с Service.	Только IP‑адрес и порт доступа узла, на котором расположена рабочая нагрузка, могут обращаться к рабочей нагрузке, связанной с Service.
Obtaining client source IP address	Исходный IP‑адрес клиента не может быть получен.	Исходный IP‑адрес клиента может быть получен.
Access performance	Доступ к 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 address, чтобы обеспечить доступ клиентам. Сервисы 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 address кластера не выделяется. Когда клиент пытается обратиться к backend pod и выполняет DNS‑запрос к Сервису, он получает список IP address 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 **.**.**.** port 900: Connection refused
Or
curl: (28) Failed to connect to **.**.**.** port 1122: Connection timed out

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

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

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

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

Тип Service сервера	Тип доступа	Источник запросов клиента	Кластер Tunnel Network	Кластер VPC Network (DataPlane V2 отключен. Если включен, см. Clusters with DataPlane V2 Enabled.)	Кластер CCE Turbo (DataPlane V2 отключен. Если включен, см. Clusters with DataPlane V2 Enabled.)
NodePort Service	Public/Private network	Тот же узел, что и pod сервиса	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP узла + NodePort на несерверном узле: Неудача	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP узла + NodePort на несерверном узле: Неудача	Доступно
		Другой узел, чем pod сервиса	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP узла + NodePort на другом узле: Неудача	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через частный IP узла + NodePort на клиентском узле: Успешно Доступ через EIP узла + NodePort на клиентском узле: Неудача Доступ через IP узла + NodePort на другом узле: Неудача	Доступно
		Другие контейнеры на том же узле, что и pod сервиса	Доступ через node IP + NodePort на серверном узле: Успешно Доступ через node IP + NodePort на узле без роли сервера: Не удалось	Доступ через node EIP + NodePort на серверном узле: Успешно Доступ через node private EIP + NodePort на серверном узле: Не удалось Доступ через node IP + NodePort на узле без роли сервера: Не удалось	Доступно
		Другие контейнеры на другом узле, отличном от pod сервиса	Доступ через node IP + NodePort на серверном узле: Успешно Доступ через node private IP + NodePort на клиентском узле: Успешно Доступ через node IP + NodePort на другом узле: Не удалось	Доступ через node IP + NodePort на серверном узле: Успешно Доступ через node private IP + NodePort на клиентском узле: Успешно Доступ через node IP + NodePort на другом узле: Не удалось	Доступно
LoadBalancer Service с использованием dedicated load balancer	Приватная сеть	Тот же узел, что и service pod	Недоступно	Недоступно	Доступно
	Приватная сеть	Другие контейнеры на том же узле, что и service pod	Недоступно	Недоступно	Доступно

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

Тип серверного Service	Тип доступа	Источник клиентского запроса	Кластер туннельной сети	VPC Network Cluster (DataPlane V2 отключён. Если включён, см. Clusters with DataPlane V2 Enabled.)	CCE Turbo Cluster (DataPlane V2 отключён. Если включено, см. Clusters with DataPlane V2 Enabled.)
Служба NodePort	Публичная/приватная сеть	Тот же узел, что и pod службы	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP узла + NodePort на несерверном узле: Не удалось	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через IP узла + NodePort на несерверном узле: Не удалось	Доступно
		Другой узел, чем pod службы	Доступ через IP узла + NodePort на серверном узле: Успешно Доступ через приватный IP узла + NodePort на клиентском узле: Успешно Доступ через EIP узла + NodePort на клиентском узле: Не удалось Доступ через IP узла + NodePort на другом узле: Не удалось	Доступ через 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 на серверном узле: Успешно Доступ через node IP + NodePort на узле без сервера: Failure	Доступно
LoadBalancer Service использует выделенный load balancer	Приватная сеть	Тот же узел, что и service pod	Недоступно	Недоступно	Доступно
LoadBalancer Service использует выделенный load balancer	Приватная сеть	Другие контейнеры на том же узле, что и service pod	Недоступно	Недоступно	Доступно

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

Note

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

Server Service Type	Тип доступа	Источник клиентского запроса	VPC Network Cluster (DataPlane V2 включён для замены kube-proxy)	CCE Turbo Cluster (DataPlane V2 включён для замены kube-proxy)
NodePort Service	Публичная/приватная сеть	Тот же узел, что и pod сервиса	Доступ через node IP + NodePort на серверном узле: Успех Доступ через node private IP + NodePort на несерверном узле: Успех Доступ через node EIP + NodePort на несерверном узле: Неудача	Доступ через node IP + NodePort на серверном узле: Успех Доступ через node private IP + NodePort на несерверном узле: Успех Доступ через node EIP + NodePort на несерверном узле: Неудача
		Другой узел, чем pod сервиса	Доступ через node IP + NodePort на серверном узле: Успех Доступ через частный IP-адрес узла + NodePort на узле, не являющемся сервером: Успешно Доступ через EIP узла + NodePort на узле, не являющемся сервером: Не удалось	Доступ через IP-адрес узла + NodePort на серверном узле: Успешно Доступ через частный IP-адрес узла + NodePort на узле, не являющемся сервером: Успешно Доступ через EIP узла + NodePort на узле, не являющемся сервером: Не удалось
		Другие контейнеры на том же узле, что и service pod	Доступ через IP-адрес узла + NodePort на серверном узле: Успешно Доступ через IP-адрес узла + NodePort на другом узле: Не удалось	Доступ через IP-адрес узла + NodePort на серверном узле: Успешно Доступ через IP-адрес узла + NodePort на другом узле: Не удалось
		Другие контейнеры на узле, отличном от того, где находится service pod	Доступ через IP-адрес узла + NodePort на серверном узле: Успешно Доступ через частный IP-адрес узла + NodePort на клиентском узле: Успешно Доступ через IP-адрес узла + NodePort на другом узле: Не удалось	Доступ через IP-адрес узла + NodePort на серверном узле: Успешно Доступ через node private IP + NodePort на клиентском узле: Success Доступ через node IP + NodePort на другом узле: Failure
LoadBalancer Service, использующий выделенный load balancer	Private network	Тот же узел, что и service pod	Inaccessible	Inaccessible
LoadBalancer Service, использующий выделенный load balancer	Private network	Другие контейнеры на том же узле, что и service pod	Inaccessible	Accessible

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

(Recommended) В кластере используйте ClusterIP Service или service domain name для доступа.

Установите externalTrafficPolicy сервиса в значение Cluster, что означает привязку сервиса на уровне кластера. Обратите внимание, что это влияет на source address persistence.

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

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

Используя функцию pass-through сервиса, kube-proxy обходится, когда для доступа используется ELB address. Сначала обращаются к 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 сервисов, подключенных к одному и тому же load balancer, должны быть одинаковыми.

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

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

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

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