---
title: Область дії конфігурації
description: Показує, як налагодити конфігурацію в Istio, щоб отримати переваги в роботі та продуктивності.
weight: 60
keywords: [scalability]
owner: istio/wg-networking-maintainers
test: no
---

Щоб налаштувати сервісну мережу, панель управління Istio (Istiod) читає різні конфігурації, включаючи основні типи Kubernetes, такі як `Service` і `Node`, а також власні типи Istio, такі як `Gateway`. Ці конфігурації потім надсилаються до панелі даних (див. [Архітектура](/docs/ops/deployment/architecture/) для отримання додаткової інформації).

Стандартно, панель управління читає всі конфігурації в усіх просторах імен. Кожен екземпляр проксі отримає конфігурацію для всіх просторів імен також. Це включає інформацію про робочі навантаження, які не зареєстровані в сервісній мережі.

Це забезпечує правильну поведінку з самого початку, але позначається на масштабованості. Кожна конфігурація має свою вартість (переважно в одиницях ЦП і памʼяті) для підтримки та актуалізації. На великих масштабах критично важливо обмежити область дії конфігурації, щоб уникнути надмірного споживання ресурсів.

## Механізми обмеження {#scoping-mechanisms}

Istio пропонує кілька інструментів для контролю області дії конфігурації для задоволення різних випадків використання. Залежно від ваших вимог, їх можна використовувати окремо або разом.

* `Sidecar` надає механізм для конкретних робочих навантажень, щоб _імплементувати_ набір конфігурацій
* `exportTo` надає механізм для _експорту_ конфігурації до набору робочих навантажень
* `discoverySelectors` надає механізм, щоб Istio повністю ігнорував набір конфігурацій

### Імпорт з `Sidecar` {#sidecar-import}

Поле [`egress.hosts`](/docs/reference/config/networking/sidecar/#IstioEgressListener) в `Sidecar` дозволяє вказати список конфігурацій для імпорту. Тільки конфігурації, які відповідають зазначеним критеріям, будуть видимі для sidecar, які підлягають `Sidecar` ресурсу.

Наприклад:

{{< text yaml >}}
apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
spec:
  egress:
  - hosts:
    - "./*" # Імплементувати всі конфігурації з нашого простору імен
    - "bookinfo/*" # Імплементувати всі конфігурації з простору імен bookinfo
    - "external-services/example.com" # Імплементувати тільки 'example.com' з простору імен external-services
{{< /text >}}

### `exportTo` {#exportTo}

Istio's `VirtualService`, `DestinationRule` і `ServiceEntry` мають поле `spec.exportTo`. Аналогічно, `Service` можна налаштувати з анотацією `networking.istio.io/exportTo`.

На відміну від `Sidecar`, який дозволяє власнику робочого навантаження контролювати залежності, `exportTo` працює в протилежному напрямку і дозволяє власникам сервісів контролювати видимість свого власного сервісу.

Наприклад, ця конфігурація робить сервіс `details` видимим тільки для власного простору імен і простору імен `client`:

{{< text yaml >}}
apiVersion: v1
kind: Service
metadata:
  name: details
  annotations:
    networking.istio.io/exportTo: ".,client"
spec: ...
{{< /text >}}

### `DiscoverySelectors` {#discoveryselectors}

В той час як попередні елементи управління працюють на рівні власника робочого навантаження або сервісу, [`DiscoverySelectors`](/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig) надає загальне управління видимістю конфігурації в межах сервісної мережі. Discovery selectors дозволяють вказати критерії для яких просторів імен повинні бути видимі панелі управління. Будь-які простори імен, які не відповідають критеріям, повністю ігноруються панеллю управління.

Це можна налаштувати як частину `meshConfig` під час установки. Наприклад:

{{< text yaml >}}
meshConfig:
  discoverySelectors:
    - matchLabels:
        # Дозволити будь-які простори імен з `istio-discovery=enabled`
        istio-discovery: enabled
    - matchLabels:
        # Дозволити "kube-system"; Kubernetes автоматично додає цю мітку до кожного простору імен
        kubernetes.io/metadata.name: kube-system
{{< /text >}}

{{< warning >}}
Istiod завжди відкриває спостереження за всіма просторами імен. Однак, discovery selectors будуть ігнорувати обʼєкти, які не вибрані на дуже ранньому етапі обробки, мінімізуючи витрати.
{{</ warning >}}

## Часті питання {#frequestly-asked-questions}

### Як дізнатися вартість певної конфігурації? {#how-can-i-understand-the-cost-of-a-certain-configuration}

Щоб отримати найкращий результат від обмеження конфігурації, може бути корисно зрозуміти вартість кожного обʼєкта. На жаль, немає простої відповіді; масштабованість залежить від великої кількості факторів. Однак є кілька загальних вказівок:

_Зміни_ конфігурації є дорогими в Istio, оскільки вони вимагають повторних обчислень. Хоча зміни `Endpoints` (зазвичай від масштабування Pod) добре оптимізовані, більшість інших конфігурацій є досить дорогими. Це може бути особливо шкідливо, коли контролери постійно вносять зміни в обʼєкт (іноді це відбувається випадково!). Деякі інструменти для виявлення, які конфігурації змінюються:

* Istiod буде записувати кожну зміну, наприклад: `Push debounce stable 1 for config Gateway/default/gateway: ..., full=true`. Це показує, що обʼєкт `Gateway` в просторі імен `default` змінився. `full=false` представляло б оптимізоване оновлення, таке як `Endpoint`. Примітка: зміни в `Service` і `Endpoints` будуть відображатися як `ServiceEntry`.
* Istiod надає метрики `pilot_k8s_cfg_events` і `pilot_k8s_reg_events` для кожної зміни.
* `kubectl get <resource> --watch -oyaml --show-managed-fields` може показати зміни в обʼєкті (або обʼєктах), щоб допомогти зрозуміти, що змінюється і ким.

[Headless services](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) (крім тих, що оголошені як [HTTP](/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection)) масштабуються на кількість вказаних екземплярів. Це робить великі headless services дорогими, і хорошим кандидатом для виключення з `exportTo` або еквівалентним.

### Що трапляється, якщо я підключаюсь до сервісу поза межами моєї області дії? {#what-happens-if-i-connect-to-a-service-outside-of-my-scope}

Коли ви підключаєтеся до сервісу, який був виключений через один з механізмів обмеження, панель даних не буде знати нічого про призначення,
тому він буде оброблений як [Несумісний трафік](/docs/ops/configuration/traffic-management/traffic-routing/#unmatched-traffic).

### Що з Gateways? {#what-about-gateways}

Хоча [Gateways](/docs/setup/additional-setup/gateway/) враховують `exportTo` і `DiscoverySelectors`, обʼєкти `Sidecar` не впливають на Gateways. Однак, на відміну від sidecar, gateways не мають стандартної конфігурації для всього кластера. Натомість кожна конфігурація явно прикріплена до шлюзу, що в основному дозволяє уникати цієї проблеми.

Однак, [наразі](https://github.com/istio/istio/issues/29131) частина конфігурації панелі даних (термін "кластер", в термінах Envoy) завжди надсилається для всього кластера, навіть якщо вона не вказується явно.