Налаштування конфігурації встановлення
Передумови
Перш ніж почати, перевірте наступні передумови:
- Завантажте реліз Istio.
- Виконайте всі необхідні налаштування для вашої платформи.
- Перевірте вимоги до Podʼів та Сервісів.
Окрім встановлення будь-якого з вбудованих профілів конфігурації Istio, istioctl install
надає повний API для налаштування конфігурації.
Параметри конфігурації в цьому API можна встановлювати індивідуально за допомогою параметрів --set
у командному рядку. Наприклад, щоб увімкнути ведення логів у режимі налагодження в стандартному профілі конфігурації, використовуйте таку команду:
$ istioctl install --set values.global.logging.level=debug
Альтернативно, конфігурацію IstioOperator
можна задати у YAML-файлі та передати до istioctl
за допомогою параметра -f
:
$ istioctl install -f samples/operator/pilot-k8s.yaml
Визначення компонента Istio
API IstioOperator
визначає компоненти, як показано в таблиці нижче:
Компоненти |
---|
base |
pilot |
ingressGateways |
egressGateways |
cni |
istiodRemote |
Налаштування для кожного з цих компонентів доступні в API в components.<назва компоненту>
. Наприклад, щоб змінити (на false) налаштування enabled
для компонента pilot
, використовуйте команду --set components.pilot.enabled=false
або задайте це в ресурсі IstioOperator
таким чином:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
pilot:
enabled: false
Усі компоненти також мають спільний API для зміни налаштувань, специфічних для Kubernetes, в components.<назва компоненту>.k8s
, як описано в наступному розділі.
Налаштування параметрів Kubernetes
API IstioOperator
дозволяє налаштовувати параметри Kubernetes для кожного компоненту у відповідний спосіб.
Кожен компонент має KubernetesResourceSpec
, який дозволяє змінювати наступні параметри. Використовуйте цей список, щоб визначити налаштування для зміни:
- Ресурси
- Проби готовності
- Кількість реплік
HorizontalPodAutoscaler
PodDisruptionBudget
- Анотації Podʼів
- Анотації сервісів
ImagePullPolicy
- Priority class name
- Node selector
- Affinity та anti-affinity
- Сервіс
- Toleration
- Стратегія
- Env
- Security context Podʼів
- Volumes та volume mounts
Усі ці налаштування Kubernetes використовують визначення API Kubernetes, тому документація Kubernetes може бути використана як довідник.
Наступний приклад файлу overlay налаштовує ресурси та параметри горизонтального масштабування podʼів для Pilot:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
pilot:
k8s:
resources:
requests:
cpu: 1000m # перевизначення з 500m стандартно
memory: 4096Mi # ... з 2048Mi стандартно
hpaSpec:
maxReplicas: 10 # ... з 5 стандартно
minReplicas: 2 # ... з 1 стандартно
Використовуйте istioctl install
, щоб застосувати змінені налаштування до кластера:
$ istioctl install -f samples/operator/pilot-k8s.yaml
Налаштування параметрів Istio за допомогою Helm API
API IstioOperator
включає інтерфейс для доступу до Helm API за допомогою поля values
.
Наступний YAML-файл налаштовує глобальні параметри та параметри Pilot за допомогою Helm API:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
values:
pilot:
traceSampling: 0.1 # перевизначення з 1.0
global:
monitoringPort: 15014
Деякі параметри тимчасово існують у Helm API та IstioOperator
API одночасно, включаючи ресурси Kubernetes, імена просторів і налаштування ввімкнення. Спільнота Istio рекомендує використовувати API IstioOperator
, оскільки він більш послідовний, перевіряється і відповідає процесу просування функцій у спільноті.
Налаштування шлюзів
Шлюзи є особливим типом компонента, оскільки можна визначити кілька шлюзів для вхідного та вихідного трафіку. В API IstioOperator
шлюзи визначаються як список. Профіль default
встановлює один шлюз для вхідного трафіку, названий istio-ingressgateway
. Ви можете перевірити стандартні значення для цього шлюзу. Вбудовані шлюзи можна налаштовувати так само як і будь-який інший компонент.
Новий шлюз для користувача можна створити, додавши новий елемент у список:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
ingressGateways:
- name: istio-ingressgateway
enabled: true
- namespace: user-ingressgateway-ns
name: ilb-gateway
enabled: true
k8s:
resources:
requests:
cpu: 200m
serviceAnnotations:
cloud.google.com/load-balancer-type: "internal"
service:
ports:
- port: 8060
targetPort: 8060
name: tcp-citadel-grpc-tls
- port: 5353
name: tcp-dns
Зверніть увагу, що значення Helm (spec.values.gateways.istio-ingressgateway/egressgateway
) спільні для всіх шлюзів вхідного/вихідного трафіку. Якщо ці значення потрібно налаштувати окремо для кожного шлюзу, рекомендується використовувати окремий CR IstioOperator
для створення маніфесту для шлюзів користувача, окремо від основної установки Istio:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
profile: empty
components:
ingressGateways:
- name: ilb-gateway
namespace: user-ingressgateway-ns
enabled: true
# Копіюйте налаштування з istio-ingressgateway за потреби.
values:
gateways:
istio-ingressgateway:
debug: error
Розширене налаштування встановлення
Налаштування зовнішніх чартів і профілів
Команди istioctl install
, manifest generate
і profile
можуть використовувати будь-яке з наступних джерел для чартів і профілів:
- Вбудовані чарт-файли. Це стандартне значення, якщо не вказано опцію
--manifests
. Вбудовані чарт-файли такі ж, як і ті, що в теціmanifests/
релізу Istio.tgz
. - Чарти у локальній файловій системі, наприклад,
istioctl install --manifests istio-1.24.3/manifests
.
Чарти та профілі у локальній файловій системі можна налаштовувати, редагуючи файли в manifests/
. Для великих змін рекомендується створити копію теки manifests
і вносити зміни там. Зверніть увагу, що макет вмісту в теки manifests
повинен бути збережений.
Профілі, що знаходяться в manifests/profiles/
, можна редагувати та додавати нові, створюючи нові файли з потрібним імʼям профілю та розширенням .yaml
. istioctl
сканує підтеку profiles
, і всі профілі, що знаходяться там, можна використовувати за іменем у полі профілю IstioOperatorSpec
. Вбудовані профілі стандартно накладаються на YAML-файл профілю перед застосуванням накладок користувача. Наприклад, ви можете створити новий файл профілю з назвою custom1.yaml
, який змінює деякі налаштування з профілю default
, а потім застосувати накладку користувача поверх цього:
$ istioctl manifest generate --manifests mycharts/ --set profile=custom1 -f path-to-user-overlay.yaml
У цьому випадку файли custom1.yaml
і user-overlay.yaml
будуть накладені на default.yaml
, щоб отримати остаточні значення, які використовуються як вхідні дані для генерації маніфесту.
Загалом, створення нових профілів не є обовʼязковим, оскільки подібний результат можна досягти, передавши кілька накладок користувача. Наприклад, команда вище є еквівалентною передачі двох файлів накладки користувача:
$ istioctl manifest generate --manifests mycharts/ -f manifests/profiles/custom1.yaml -f path-to-user-overlay.yaml
Створення власного профілю необхідне тільки якщо ви повинні посилатися на профіль за іменем через IstioOperatorSpec
.
Накладання патча на вихідний маніфест
CR IstioOperator
, вхідний для istioctl
, використовується для генерації вихідного маніфесту, що містить ресурси Kubernetes, які потрібно застосувати до кластера. Вихідний маніфест можна додатково налаштувати для додавання, модифікації або видалення ресурсів через API overlays IstioOperator після його генерації, але перед застосуванням до кластера.
Наступний приклад файлу накладки (patch.yaml
) демонструє тип вихідного маніфесту, який можна отримати:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
profile: empty
hub: docker.io/istio
tag: 1.1.6
components:
pilot:
enabled: true
namespace: istio-control
k8s:
overlays:
- kind: Deployment
name: istiod
patches:
# Вибір елемента списку за значенням
- path: spec.template.spec.containers.[name:discovery].args.[30m]
value: "60m" # перевизначено з 30m
# Вибір елемента списку за ключем:значенням
- path: spec.template.spec.containers.[name:discovery].ports.[containerPort:8080].containerPort
value: 1234
# Перевизначення з об'єктом (зверніть увагу на | у значенні: перший рядок)
- path: spec.template.spec.containers.[name:discovery].env.[name:POD_NAMESPACE].valueFrom
value: |
fieldRef:
apiVersion: v2
fieldPath: metadata.myPath
# Видалення елемента списку
- path: spec.template.spec.containers.[name:discovery].env.[name:REVISION]
# Видалення елемента мапи
- path: spec.template.spec.containers.[name:discovery].securityContext
- kind: Service
name: istiod
patches:
- path: spec.ports.[name:https-dns].port
value: 11111 # ПЕРЕВИЗНАЧЕНО
Передача файлу до istioctl manifest generate -f patch.yaml
застосовує ці патчі до вихідного маніфесту стандартного профілю. Два змінені ресурси будуть модифіковані, як показано нижче (деякі частини ресурсів опущено для стислості):
apiVersion: apps/v1
kind: Deployment
metadata:
name: istiod
spec:
template:
spec:
containers:
- args:
- 60m
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
apiVersion: v2
fieldPath: metadata.myPath
name: discovery
ports:
- containerPort: 1234
---
apiVersion: v1
kind: Service
metadata:
name: istiod
spec:
ports:
- name: https-dns
port: 11111
---
Зверніть увагу, що патчі застосовуються в зазначеному порядку. Кожен патч застосовується на вивід з попереднього патчу. Шляхи в патчах, які не існують у вихідному маніфесті, будуть створені.
Вибір елемента списку
Як istioctl --set
, так і поле k8s.overlays
у CR IstioOperator
підтримують вибір елемента списку за [index]
, [value]
або за [key:value]
. Прапорець --set
також створює будь-які проміжні вузли в шляху, які відсутні в ресурсі.