Налаштування конфігурації встановлення

Передумови

Перш ніж почати, перевірте наступні передумови:

  1. Завантажте реліз Istio.
  2. Виконайте всі необхідні налаштування для вашої платформи.
  3. Перевірте вимоги до 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, який дозволяє змінювати наступні параметри. Використовуйте цей список, щоб визначити налаштування для зміни:

  1. Ресурси
  2. Проби готовності
  3. Кількість реплік
  4. HorizontalPodAutoscaler
  5. PodDisruptionBudget
  6. Анотації Podʼів
  7. Анотації сервісів
  8. ImagePullPolicy
  9. Priority class name
  10. Node selector
  11. Affinity та anti-affinity
  12. Сервіс
  13. Toleration
  14. Стратегія
  15. Env
  16. Security context Podʼів
  17. 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 також створює будь-які проміжні вузли в шляху, які відсутні в ресурсі.

Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!