Сценарии администрирования#

В руководстве приведены инструкции по выполнению сценариев администрирования компонента Cost Calculator (SZUX) продукта Platform V Cost Calculator (SZU).

Примечание:

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

Имя переменной не определяет конкретную среду контейнеризации.

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

Пользователь базы данных должен обладать расширенной политикой аутентификации, которая позволяет ограничивать использование базы данных и устанавливать требования к паролям, назначая профили ролям.

Конфигурирование параметров безопасности для стороннего программного обеспечения выполнятся в соответствии с базовыми настройками этого программного обеспечения.

Отдельная роль в ролевой модели компонента не предусмотрена.

Администрирование элементов#

Компонент функционирует с помощью своих основных элементов:

• сервис визуализации интерфейсов;

• сервис бизнес-логики;

• база данных.

Сервис визуализации интерфейсов - модуль szux-pl в системе оркестрации контейнеризированных приложений.

Модуль воспроизводится на базовом образе Nginx.

Сервис бизнес-логики - модуль szux_bh в системе оркестрации контейнеризированных приложений.

Для мониторинга работоспособности приложения подключен модуль Spring boot actuator.

Реализована возможность получения данных о состоянии приложения на основании end-point/actuator/.

Детальная информация по получению данных end-point размещена в документации API Spring boot actuator.

По умолчанию включена функция передачи метрик с параметрами, указанными в конфигурации:

• annotation - Services - pod szux_bh:

 prometheus.io.path: /actuator/prometheus 
 prometheus.io.port: '8080' 
 prometheus.io.scrape: 'true

Команды запускаются внутри pod szux_bh.

Существующие API доступны для просмотра по swagger ссылке:

http://<hostname>/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config,

где hostname – адрес сервиса до сервера.

Таблица. Список end-point /actuator/

База данных#

База данных сопровождается стандартными инструментами и подходами к сопровождению к базе данных.

Защита, архивирование, восстановление данных реализовано инструментами базы данных.

Аудит событий#

Аудит событий используется для фиксации особо важных событий в компоненте:

• Импорт данных из файлов и внешних сервисов в компонент;

• Экспорт данных из компонента;

• Удаление элементов компонента.

Использование аудита событий опционально. Настраивается в соответствии с требованиями по функционированию компонента.

Проверено использование аудита событий в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка аудита событий выполняется перед установкой текущего компонента.

При настройке рекомендуется использование документации на сервис аудита.

Настройка аудита событий#

Аудит событий реализован с помощью компонента Единый коллектор телеметрии (COTE) продукта Platform V Monitor (OPM).

Взаимодействие компонента и сервиса аудита должно быть реализовано с помощью компонента для аутентификации и авторизации межсервисных взаимодействий One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD).

Для настройки аудита выполните действия:

1. Настройте подключение к компоненту (COTE) согласно документации на него;

2. Заполните параметры конфигурационных файлов:

   • параметр для включения функции:

     • common.conf.yml:

       • SzuxProfilesActive - добавьте профиль для включения аудита;

   • параметры для настройки сервиса аудита:

     • common.conf.yml:

       • укажите host, port сервиса для сервиса аудита;

     • szux-bh.conf:

       • заполнить конфигурационные параметры для настройки аудита;

   • параметры для настройки сервиса для аутентификации и авторизации межсервисных взаимодействий (OTTS)

     • common.conf.yml:

       • заполните параметры для настройки генерации конфигурационных файлов egress для ОТТ-серверов;

     • szux.isito.all.conf:

       • заполните шаблон для формирования ссылок при вызове серверов OTTS.

3. Добавьте secrets в Secret Management System (для ОТТS). Подробно описано в разделе Настройка хранения secret в Secret Management System текущего документа;

4. Выполните установку/обновление текущего компонента.

5. Выполните проверку работоспособности (проверка описана в разделе Проверка работоспособности документа Руководство по установке).

Примечание:

Если режим включен, но компонент для аудита недоступен, текущий компонент функционировать не будет.

Аутентификация#

Аутентификации используется для проверки подлинности пользователя и безопасности межсервисных взаимодействий (последнее описано в соответствующих разделах).

Использование аутентификации опционально. Настраивается в соответствии с требованиями по функционированию компонента.

Проверено использование аутентификации в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка аутентификации выполняется перед установкой текущего компонента.

При настройке рекомендуется использование документации на сервис аутентификации.

Примечание:

Если режим включен, но компонент для аутентификации недоступен, текущий компонент функционировать не будет.

Настройка аутентификации пользователя#

Аутентификация реализована с помощью компонента для проксирования аутентификации IAM Proxy (AUTH) продукта Platform V IAM SE (IAM) совместно с системой управления доступом.

Текущий компонент не предъявляет требований к выбору системы управления доступом.

Выбор системы регламентируется компонентом для проксирования аутентификации (например, компонент KeyCloak.SE (KCSE)).

Создание пользователей, создание ролей, назначение ролей для пользователей производится в системе управления доступом. Требования по аутентификационным данным пользователя, управление данными рекомендуется уточнять в документации на эту систему.

Запрос через компонент для проксирования аутентификации (AUTH) отправляется в систему управления доступом, где проходит аутентификация и авторизация.

Вход в текущий компонент выполняется, если компонент для проксирования аутентификации (AUTH) возвращает JWT-токен, в котором содержится информация пользователе и его роли.

Если роли у пользователя нет, права на выполнение каких-либо действий в компоненте будут отсутствовать.

Для настройки аутентификации выполните действия:

1. Настройте подключение к компоненту (AUTH) согласно документации на него.

2. Настройте ссылку для подключения к текущему компоненту (обратитесь в техническую поддержку системы аутентификации):

   • Настройте location.

     Пример настройки конфигурационного файла junction для компонента проксирования аутентификации (AUTH):

# RDS Client managed
# Ответвление для Platform V Cost Calculator (запросы с URL /szux/*)
location /szux/ {
        set $jctroot "/szux";
        set $server_jct 'costcalculator-<ПрефиксСтенда>.ingress.<Домен системы контейнерезации>';
        set $scheme_jct 'https';
 
        include common/rds-set-header-host-to-backend.location.conf;
        include common/rds-ssl-sni-on-szux.server.conf;
 
        proxy_ssl_name <proxy_ssl_name>;
 
         proxy_pass https://backend_jct_<код компонента>;
 
 
}
    }

• Включите использование location.

  Пример настройки конфигурационного файла для компонента проксирования аутентификации (AUTH):

# RDS Client managed
upstream backend_jct_szux {
        include common/jct.upstream.conf;
 
        server costcalculator-<ПрефиксСтенда>.ingress.< Домен системы контейнерезации>:443;
}

3. Заведите пользователей в системе управления доступом (обратитесь в техническую поддержку системы).

4. Заполните параметры конфигурационных файлов для текущего компонента:

   • параметр для включения функции (можно выбрать один из вариантов):

     • common.conf.yml:

       • SzuxProfilesActive - добавьте профиль для включения аутентификации.

     • szux-bh.conf:

       • bh.configmap.data.profiles.active - добавьте профиль для включения аутентификации.

5. Выполните установку/обновление текущего компонента.

6. Выполните проверку работоспособности (проверка описана в разделе Проверка работоспособности документа Руководство по установке).

Авторизация#

Авторизация используется для предоставления определенных прав на выполнение действий определенному пользователю (или группе) и безопасности межсервисных взаимодействий (последнее описано в соответствующих разделах).

Использование авторизации опционально. Настраивается в соответствии с требованиями по функционированию компонента.

Проверено использование авторизации в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка авторизации выполняется перед установкой текущего компонента.

При настройке рекомендуется использование документации на сервис авторизации.

Примечание:

Если режим включен, но компонент для авторизации недоступен, текущий компонент функционировать не будет.

Настройка авторизации пользователя#

Авторизация реализована с помощью компонента для проксирования аутентификации IAM Proxy (AUTH) продукта Platform V IAM SE (IAM) совместно с системой управления доступом.

Текущий компонент не предъявляет требований к выбору системы управления доступом.

Выбор системы регламентируется компонентом для проксирования аутентификации (например, компонент KeyCloak.SE (KCSE)).

Создание пользователей, создание ролей, назначение ролей для пользователей производится в системе управления доступом. Требования по данным пользователя для авторизации, управление данными рекомендуется уточнять в документации на эту систему.

Запрос через компонент для проксирования аутентификации (AUTH) отправляется в систему управления доступом, где проходит аутентификация и авторизация.

Вход в текущий компонент выполняется, если компонент для проксирования аутентификации (AUTH) возвращает JWT-токен, в котором содержится информация пользователе и его роли.

Проверка прав на выполнение действий для определенной роли происходит на стороне приложения текущего компонента.

Для настройки авторизации выполните действия:

1. Выполните настройку аутентификации пользователя (описано в соответствующем разделе).

2. Настройте принадлежность ролей для пользователя (обратитесь в техническую поддержку системы управления доступом).

   1. Заведите роли:

      • SIZING_USER;

      • AUDITOR;

      • SIZING_BUSINESS_ADMIN.

   2. Назначьте пользователям существующие роли.

3. Выполните установку/обновление текущего компонента.

4. Выполните проверку работоспособности (проверка описана в разделе Проверка работоспособности документа Руководство по установке).

Хранение secrets#

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

Хранение информации реализовано с помощью следующих инструментов:

• с помощью встроенных инструментов системы оркестрации контейнеризированных приложений. Настройка не требуется;

• с помощью сервиса Secret Management System.

Настройка хранения secrets#

Хранение secrets может быть реализовано с помощью сервиса Secret Management System.

Использование сервиса опционально. Настраивается в соответствии с требованиями по функционированию компонента.

Проверено использование сервиса в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка выполняется перед установкой текущего компонента.

При настройке рекомендуется использование документации на сервис.

Для настройки выполните действия:

1. Создайте заявку на добавление группы пользователей в Active directory;

2. Создайте заявки по шаблонам:

   • Получение доступа до KV хранилища Secret Management System. При получении доступа должны быть выполнены следующие действия: создана группа, выбран тип secrets, выставлен путь до хранилища, выставлен доступ к группе с определенной ролью, предоставлен доступ к engine;

   • Получение доступа до PKI engine Secret Management System. При получении доступа должны быть выполнены следующие действия: создана группа, выбран разрешенный доменный суффикс, выставлен доступ к группе, предоставлен доступ к engine;

   • Получение доступа до метода аутентификации из Kubernetes/Platform V DropApp/Openshift. При получении доступа должны быть выполнены следующие действия: выбран тип, наименование кластера, выбраны имена namespaсe, выставлен доступ к группе;

3. Перенесите secrets в группу. Количество secret определяется видом engine:

   1. PKI – генерация сертификатов, ключей выполняется автоматически при развертывании;

   2. КV – заполнение всех сертификатов выполняется в кодировке base64.

   • Кодирование в base64 выполняется с помощью команды:

     echo "Тело secret" | base64

   • Декодирование в base64 выполняется с помощью команды:

     echo "Код в в base64" | base64 --decode Тело secret

     Следует учесть, что при декодировании по умолчанию в конец теста может добавиться спецсимвол \n (перенос строки).

     Для проверки добавьте в систему оркестрации контейнеризированных приложений переменную через secret или configmap и запустите pod.

     В терминале поднятого контейнера введите env и/или export и найдите переменную с актуальным значением.

     Если перенос строки присутствует, то это будет видно в терминале.

   3. Наименования группы и secret должны соответствовать наименованиям, указанным в таблице.

Таблица. Список secrets

4. Заполните параметры конфигурационных файлов:

   • Выставите режим работы с сервисом в файле custom_property.conf.yml:

     • szux.ose.secman.enabled=true.

   • Выберете engine для элементов сервиса в файле szux-all.conf:

     • базы данных (DB);

     • istio (ingress/egress);

     • OTTS.

     Для выбранного engine выставите значение = true.

     Для другого engine выставите значение = false.

   • Выставите дополнительные параметры для работы с сервисом:

     • в файле szux-bh.conf:

       Заполните параметры для выбранного engine (параметры неиспользуемого engine не заполняются).

     • в файле szux.isito.all.conf:

       • общие параметры;

       • параметры для выбранного engine (параметры неиспользуемого engine не заполняются).

   • Выставите/проверьте дополнительные параметры работы с сервисом журналирования и мониторинга в файле szux-bh.fb.sidecar:

     • конфигурацию fluent-controller;

     • ключи в Secret Management System;

     • наименование и путь до CA сертификата;

     • инициализацию SSL на Egress.

5. Выполните установку/обновление текущего компонента.

6. Выполните проверку работоспособности (проверка описана в разделе Проверка работоспособности документа Руководство по установке).

Примечание:

Если режим включен, но компонент для хранения secrets недоступен, текущий компонент функционировать не будет.

Обновление secrets#

В компоненте предусмотрено обновление secret.

Обновление secret выполняется в нескольких режимах:

• принудительное. Выполняется после перезапуска pod;

• в автоматическом режиме. Настроено по умолчанию.

Автоматическое обновление доступно для групп secret, указанных в таблице.

Таблица. Список secrets

Существует несколько вариантов инициализации терминации трафика при обновлении secrets (применимость к secrets описана в таблице):

• уровень бизнес-логики;

• egress.

Проверка secrets проходит в зависимости от инициализации терминации трафика:

• уровень бизнес-логики:

  • Проверка изменения secret происходит по расписанию;

  • В случае обнаружения изменения secret – выполняется его обновление.

• egress:

  • Проверка и обновление secrets происходит в соответствии с документацией на egress.

Настройка обновления secrets#

Для настройки выполните действия:

1. Заполните параметры конфигурационных файлов:

   • Выберите режим инициализации терминации трафика в разделе База данных в файле szux-bh.conf.

   • Настройте расписание для проверки обновления в файле szux-bh.conf (выполняется при необходимости изменения):

     • hotswap.delay.in.milliseconds (расписание периодичности проверки (по умолчанию выставлена 1 минута)).

     • hotswap.initial.delay.in.milliseconds (время старта расписания относительно начала работы (по умолчанию 10 секунд)).

2. Выполните установку/обновление текущего компонента.

3. Выполните проверку обновления:

   • Обновите secret;

   • Проверьте статус обновления secret в журнале логирования pod сервиса бизнес-логики.

     Статус должен отобразиться в следующем формате:

     • Refresh cert list: наименование файла secret (например, secret-szux-additional);

     • Refresh parameter list: наименование параметра secret (например, db.config.username).

Журналирование#

Для компонента предусмотрен сбор и накопление сиcтемных событий (сообщений).

Сбор и накопление сиcтемных событий реализовано с помощью следующих инструментов:

• с помощью встроенных инструментов системы оркестрации контейнеризированных приложений. Настройка не требуется;

• с помощью компонентов продукта Platform V Monitor (OPM).

Настройка журналирования#

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

• сбор, накопление и передача осуществляется через fluent-bit-sidecar (с добавлением logback). Встраивается в текущий компонент с помощью образа Агента LOGA журналирование (ALOG);

• хранение осуществляется в Apache Kafka компонента Abbys (LGDB).

Использование журналирования опционально. Настраивается в соответствии с требованиями по функционированию компонента.

Проверено использование журналирования в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка журналирования выполняется перед установкой текущего компонента.

Для настройки выполните действия:

1. Ознакомьтесь с инструкцией по подключению в Руководстве прикладного разработчика Агента LOGA журналирование (ALOG);

2. Получите необходимую информацию для интеграции у администраторов сред:

   • host Apache Kafka;

   • название topic;

3. Добавьте необходимые параметры в конфигурационный файл в common repository common.conf.yml:

   • раздел SecMan:

     • VaultKubernetesPath;

   • раздел Apache Kafka:

     • SzuxKafkaBootstrapServers;

     • SzuxKafkaTopic;

4. Сформируйте сертификаты:

   • корневой:

     • получите корневой типа root.cr;

     • получите корневой для Secret Management System типа secman-ca.crt;

     • корневой сертификат необходимо расположить в common repository по пути repository/стенд/ansible/files/ssl/;

       • Клиентский сертификат и приватный ключ сертификата для интеграции с модулем Агента LOGA журналирование (ALOG) и отправкой событий в Apache Kafka:

         • выпуск сертификатов зависит от варианта работы:

           • если планируется работа без использования Secret Management System - выпускаются сертификаты без удостоверяющего цента. Располагаются в хранилище из сертификатов;

           • если планируется работа с использованием Secret Management System. В зависимости от выбранного engine (подробнее описано в разделе Хранение secrets текущего документа):

             • PKI - сертификаты не выпускаются;

             • KV - выпускаются сертификаты удостоверяющего цента;

5. Добавьте secrets в Secret Management System;

   1. Выполняется при использовании интеграции с сервисом;

   2. Описано в разделе Хранение secrets текущего документа;

6. Заполните параметры конфигурационного файла szux-bh.fb.sidecar;

   • параметр включения/выключения;

   • конфигурацию fluent-controller;

   • обязательные параметры для заполнения (с признаком «заполнить параметр»);

7. Выполните установку/обновление текущего компонента;

8. Выполните проверку работоспособности (раздел Проверка работоспособности документа Руководство по установке).

Примечание:

Если Apache Kafka компонента Abbys (LGDB) будет недоступна, текущий компонент будет функционировать без отправления событий.

Если настройка интеграции выполнена неверно, текущий компонент функционировать не будет.

Мониторинг#

Для компонента предусмотрен сбор и накопление метрик компонента.

Сбор и накопление метрик реализовано с помощью следующих инструментов:

• с помощью встроенных инструментов системы оркестрации контейнеризированных приложений. Настройка не требуется;

• с помощью компонентов продукта Platform V Monitor (OPM).

Настройка мониторинга#

Мониторинг может быть реализован с помощью следующих элементов:

• сбор, накопление и передача осуществляется элементами (pods) сервиса Объединенный мониторинг Unimon (MONA), которые устанавливается отдельным дистрибутивом в проект с текущим компонентом;

• хранение осуществляется в Apache Kafka компонента Abbys (LGDB).

Использование мониторинга опционально. Настраивается в соответствии с требованиями по функционированию компонента.

Проверено использование мониторинга в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка мониторинга выполняется перед установкой текущего компонента.

При настройке рекомендуется использование документации на сервис мониторинга.

Для настройки выполните действия:

1. Установите элементы сервиса (pods) Объединенный мониторинг Unimon (MONA) в соответствии с Руководством по установке на него.

2. Измените конфигурацию аннотаций service (выполняется при необходимости):

Exposes Micrometer-Prometheus App by CLuster Ip
 prometheus.io.path
 prometheus.io.por

3. Выполните проверку работоспособности (раздел Проверка работоспособности документа Руководство по установке).

Примечание:

Если Apache Kafka компонента Abbys (LGDB) будет недоступна, текущий компонент будет функционировать без отправления метрик.

Система сбора и накопления метрик сторонних систем мониторинга#

В компоненте предусмотрены сбор и хранение метрик мониторинга вычислительных ресурсов при помощи сторонних систем мониторинга.

Система сбора собирает метрики при помощи сторонних систем мониторинга и хранит их в своем хранилище для анализа и прогнозирования потребления ресурсов.

Сбор и хранение метрик реализованы с помощью cистемы хранения и обработки временных рядов. В качестве системы сбора и хранения метрик мониторинга используется Victoria Metrics.

Использование функции опционально.

Проверено использование сбора и накопления метрик в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка сбора выполняется перед установкой текущего компонента.

Для настройки Victoria Metrics воспользуйтесь документацией на программный продукт.

Настройка сбора и хранения метрик#

Для настройки выполните действия:

1. Установите сервис;

2. При необходимости выпустите сертификат для доступа: tls.crt/tls.key;

3. Настройте параметры работы сервиса:

   • Расположение файла с настройками: Unit/etc/systemd/system/victoria-metrics.service;

   • Пример настройки: victoria-metrics.service;

4. Настройте параметры для сбора:

   • Расположите файл с настройками в directory, куда установлен сервис: /victoria-metrics/scrape.yaml;

   • Задайте параметры для сбора в файле: scrape.yaml:

     • Расположение метрик;

     • Список метрик, которые необходимо собирать;

     • Периодичность сбора (агрегация данных по временным интервалам);

     • Адреса источников, с которых необходимо собирать метрики (Prometheus, Victoria Metrics);

5. Настройте перенаправление трафика на 443, если это необходимо.

   Пример:

sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443 # Перенаправить трафик с порта 443 на 8443
sudo mkdir -p /etc/iptables # Создать директорию /etc/iptables, если ее нет
sudo iptables-save > /etc/iptables/rules.v4 # Сохранить текущие правила iptables в файл rules.v4

6. Заполните параметры в конфигурационных файлах:

   1. в группе Система сбора и накопления метрик сторонних систем мониторинга в szux-bh.conf;

   2. в группе Сторонние Prometheus: в szux.isito.all.conf.

7. Выполните установку/обновление текущего компонента;

8. Выполните проверку работоспособности (раздел Проверка работоспособности документа Руководство по установке).

Примечание:

Если Victoria Metrics будет недоступна или настройка интеграции выполнена неверно, текущий компонент будет функционировать без сбора метрик.

Загрузка информации#

Для компонента предусмотрена загрузка информации для быстрого заполнения данных приложения:

• через пользовательский интерфейс в формате файла .json;

• через внешнее API в формате файла .zip.

Функциональность описана в соответствующем разделе Руководства оператора.

Выгрузка информации#

Для компонента предусмотрена выгрузка информации с данными приложения:

• через пользовательский интерфейс:

  • для каталога Продукты в формате файла .json;

  • для каталога Расчеты в формате файла .xlsx.

Функциональность описана в соответствующем разделе Руководства оператора.

Выгрузка информации из базы данных доступна инструментами базы данных.

Информация о сервисе#

Компонент, продукт предоставляет информацию о текущей версии приложения.

Просмотр информации доступен в файле формата .swidtag.

Файл находится в дистрибутиве на компонент, на продукт.

Наименование файла содержит следующую информацию:

<Имя поставщика_наименование программного обеспечения>.swidtag.

При формировании файла сервис заполняет свою информацию в виде пары ключ-значение, описанные в таблице.

Таблица. Информация о компоненте

Скрипты для работы с компонентом#

При работе с компонентом могут использоваться скрипты для сбора данных из других источников информации и импорта их в компонент.

Описание скриптов указано в документе Руководство по использованию скриптов.

Сторонние сертификаты#

Компонент может использовать сторонние сертификаты.

Использование сертификатов настраивается в соответствии с требованиями по функционированию компонента.

Сертификаты используются для реализации функций:

• подключение к базе данных (клиентский и серверный сертификат);

• сетевая безопасность;

• подключение к другим сервисам.

Защита сети и данных, которые передаются по каналам связи#

Для компонента предусмотрена защита сети и данных, которые передаются по каналам связи.

Для аутентификации внутренних и внешних элементов компонента рекомендуется использовать протокол mTLS/TLS версии 1.2, реализуемый средствами Istio-proxy.

Функция осуществляется сторонними компонентами.

Программное обеспечение, необходимое для реализации функции указано в разделе Системное программное обеспечение документа Руководство по установке.

Использование сервиса для защиты данных опционально. Настраивается в соответствии с требованиями по функционированию компонента.

Проверено использование сервиса в следующих системах оркестрации контейнеризированных приложений:

• Platform V DropApp.

Настройка выполняется перед установкой текущего компонента.

При настройке рекомендуется использование документации на сервис.

Настройка защиты сети и данных#

Для настройки выполните действия:

1. Настройте подключение к сервису для защиты данных (обратитесь в техническую поддержку общей инфраструктуры).

   Укажите параметры подключения, выберите сервис для выполнения функции.

2. Сформируйте сертификаты для Istio.

   Расположите сертификаты в системе хранения сертификатов, в зависимости от способа хранения:

   • используется Secret Management System - сертификаты располагаются в зависимости от выбранного engine (подробнее описано в разделе Хранение secrets текущего документа);

   • не используется Secret Management System - сертификаты располагаются в хранилище из сертификатов.

3. Выполните установку/обновление текущего компонента.

4. Выполните проверку работоспособности (проверка описана в разделе Проверка работоспособности документа Руководство по установке).

Примечание:

Если Istio будет недоступен, текущий компонент функционировать не будет.