Область дії конфігурації

4 хвилин(и) перевірка сторінки

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

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

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

Механізми обмеження

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

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

Імпорт з `Sidecar`

Поле egress.hosts в Sidecar дозволяє вказати список конфігурацій для імпорту. Тільки конфігурації, які відповідають зазначеним критеріям, будуть видимі для sidecar, які підлягають Sidecar ресурсу.

Наприклад:

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

`exportTo`

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

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

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

apiVersion: v1
kind: Service
metadata:
  name: details
  annotations:
    networking.istio.io/exportTo: ".,client"
spec: ...

`DiscoverySelectors`

В той час як попередні елементи управління працюють на рівні власника робочого навантаження або сервісу, DiscoverySelectors надає загальне управління видимістю конфігурації в межах сервісної мережі. Discovery selectors дозволяють вказати критерії для яких просторів імен повинні бути видимі панелі управління. Будь-які простори імен, які не відповідають критеріям, повністю ігноруються панеллю управління.

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

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

Часті питання

Як дізнатися вартість певної конфігурації?

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

Зміни конфігурації є дорогими в 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 (крім тих, що оголошені як HTTP) масштабуються на кількість вказаних екземплярів. Це робить великі headless services дорогими, і хорошим кандидатом для виключення з exportTo або еквівалентним.

Що трапляється, якщо я підключаюсь до сервісу поза межами моєї області дії?

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

Що з Gateways?

Хоча Gateways враховують exportTo і DiscoverySelectors, обʼєкти Sidecar не впливають на Gateways. Однак, на відміну від sidecar, gateways не мають стандартної конфігурації для всього кластера. Натомість кожна конфігурація явно прикріплена до шлюзу, що в основному дозволяє уникати цієї проблеми.

Однак, наразі частина конфігурації панелі даних (термін “кластер”, в термінах Envoy) завжди надсилається для всього кластера, навіть якщо вона не вказується явно.