Руководство по установке#
В руководстве приведены инструкции по установке компонента Сервисный прокси (SVPX) продукта Platform V Synapse Service Mesh (SSM).
Термины и определения#
Термин/аббревиатура |
Определение |
|---|---|
CPU |
Central Processing Unit, центральный процессор |
KB |
Килобайт (КБ) — единица измерения количества информации, равная 1024 байтам |
MB |
Мегабайт (МБ) — единица измерения количества информации, равная 1024 KB |
ГБ |
Гигабайт (ГБ) — единица измерения количества информации, равная 1024 MB |
TB |
Терабайт (ТБ) — единица измерения количества информации, равная 1024 ГБ |
TPS |
Ticks per Second, число тактов в секунду |
Милликор |
Метрическая единица измерения, используемая для измерения загрузки процессора |
Pod |
Набор контейнеров внутри узла кластера Kubernetes |
Deployment |
Набор инструкций для запуска приложения в Kubernetes |
Платформа |
Платформа оркестрации приложений с средствами автоматизации и управления на основе политик, например Kubernetes |
Сервисная сетка / Service Mesh |
Архитектурный паттерн реализации управляемых, безопасных, контролируемых, прозрачных взаимодействий между микросервисными приложениями, обеспечиваемый набором прокси (Сервисных и Граничных), установленных в namespace потребителя |
Platform V Synapse Service Mesh / SSM |
Программный продукт на базе Istio SE, обеспечивающий возможность создания сервисной сети поверх Платформенной в Kubernetes |
Istio SE |
Настраиваемая сервисная сетка с открытым исходным кодом, служащая для взаимодействия, мониторинга и обеспечения безопасности контейнеров в кластере Kubernetes |
Контрольная панель |
Проект, где запущены управляющие приложения Synapse Service Mesh (компонент POLM) |
Управление политиками / POLM |
Компонент Управление политиками из состава продукта Platform V Synapse Service Mesh |
Граничный прокси / IGEG |
Компонент Граничный прокси Platform V Synapse Service Mesh |
Сервисный прокси / SVPX |
Компонент Сервисный прокси Platform V Synapse Service Mesh |
Ingress Gateway |
Прокси для контроля внешнего трафика входящего в проект. Позволяет включать для входящего трафика такие функции как маршутизация, балансировка нагрузки, безопасность и мониторинг |
Egress Gateway |
Прокси для контроля исходящего трафика из проекта. Egress позволяет применять правила мониторинга и правила маршрутизации к выходящему трафику |
Проект / namespace |
Изолированная область (пространство имен) в кластере Kubernetes, предназначенное для разграничения доступа к ресурсам кластера (Deployment, Service, и т.д.) |
Системные требования#
Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются клиентом при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.
Системное программное обеспечение#
Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.
Категория ПО |
Обязательность установки (да/нет) |
Наименование ПО |
Версия |
Продукт, функциональная совместимость с которым подтверждена |
Описание |
|---|---|---|---|---|---|
Cреда контейнеризации |
Да |
1.21 и выше |
Рекомендовано. Правообладателем АО «СберТех» также рекомендована среда контейнеризации – Platform V DropApp, см. раздел «Платформенные зависимости» |
Платформа контейнеризации для запуска компонентов сервиса |
|
Cреда контейнеризации |
Да |
4.6 и выше |
Опционально |
Платформа контейнеризации приложений с средствами автоматизации и управления на основе политик |
|
Базовая ОС для контейнеров |
Да |
10 и выше |
Опционально. Правообладателем АО «СберТех» также рекомендована ОС – Platform V SberLinux OS Server, см. раздел «Платформенные зависимости» |
Операционная система |
|
Примечание:
*
Да — категория ПО обязательна для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данной категории ПО).
Нет — категория ПО необязательна для функционирования сервиса (это означает, что сервис может выполнять свои основные функции без установки данной категории ПО).
**
Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.
Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.
Платформенные зависимости#
У компонента SVPX реализована интеграция со следующими компонентами из состава продукта:
Наименование компонента Platform V |
Код компонента Platform V |
Версия продукта |
Код и наименование компонента |
Обязательность установки (да/нет) |
Описание |
|---|---|---|---|---|---|
Platform V Synapse Service Mesh |
SSM |
3.9 |
POLM/Управление политиками |
Да |
Управление политиками из состава продукта Platform V Synapse Service Mesh формирует конфигурации компонент сервисного и граничного прокси. Данный компонент определяет базовые настройки и политики инжекта сервисного прокси в прикладные сервисы |
Platform V Synapse Service Mesh |
SSM |
3.9 |
IGEG/Граничный прокси |
Нет |
Граничный прокси из состава продукта Platform V Synapse Service Mesh участвует в формировании сервисной сетки Service Mesh, обеспечивая защиту входящего/исходящего трафика в проекте |
Для настройки, контроля и функционирования компонента SVPX реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех»:
Наименование продукта |
Код |
Версия продукта |
Код и наименование компонента |
Обязательность установки (да/нет) |
Описание |
Аналог других производителей |
|---|---|---|---|---|---|---|
Platform V DropApp |
K8S |
1.1-60 и выше |
K8SC K8S Core |
Да |
Дистрибутив Kubernetes со встроенными механизмами мультитенантности и бессерверным исполнением |
Kubernetes, Red Hat OpenShift Container Platform |
Platform V SberLinux OS Server |
SLO |
8.7 и выше |
INST Операционная система |
Да |
С контейнеров для запуска модулей компонента |
ОС Альт 8 СП |
У компонента SVPX реализована интеграция со следующими программными продуктами, правообладателем которых является АО «СберТех»:
Наименование компонента Platform V |
Код компонента Platform V |
Версия продукта |
Код и наименование компонента |
Обязательность установки (да/нет) |
Описание |
|---|---|---|---|---|---|
Platform V Backend |
#BD |
4.2.0 и выше |
OTTS One-Time Password (OTP)/OTT |
Нет |
Сервис для аутентификации и авторизации межсервисных взаимодействий |
Platform V Monitor |
OPM |
1.2 и выше |
LOGA/Журналирование |
Нет |
Сервис предназначен для сохранения логов и предоставляет возможности для их просмотра и анализа конечными пользователями (сотрудниками поддержки) |
Platform V Monitor |
OPM |
4.0 и выше |
MONA/Объединенный мониторинг Unimon |
Нет |
Продукт предназначен для сбора данных о производительности, доступности и работоспособности прикладных приложений и инфраструктуры |
Примечание:
***
Да — компонент или продукт необходим для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данного компонента).
Нет — необязательный для функционирования сервиса компонент или продукт (это означает, что сервис может выполнять свои основные функции без установки данного компонента).
****
Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».
Аппаратные требования#
Для установки компонента требуется следующая конфигурация аппаратного обеспечения, рассчитанная в зависимости от схемы взаимодействия и количества TPS.
Процессор
CPU измеряется в милликорах (millicores). Один милликор равен 1⁄1000 ядра. 1000 милликоров = 1 ядро.
Память
Память измеряется в KB, MB, ГБ и TB.
Единицы измерения:
1024 bytes = 1 KB;
1024 KB = 1 MB;
1024 MB = 1 ГБ;
1024 ГБ = 1 TB.
На промышленных стендах для повышения надежности для критичных сервисов рекомендуется устанавливать request = limit.
Стандартные значения ресурсов сервисного прокси определенные в настройках контрольной панели (компонент POLM):
CPU Request, millicores |
CPU Limit, millicores |
Memory Request, MB |
Memory Limit, MB |
|---|---|---|---|
100 |
200 |
128 |
256 |
Примерные значения по ресурсам сервисного прокси в зависимости от нагрузки на прикладной сервис с инжектированным сервисным прокси:
TPS |
CPU / Request, millicores |
CPU / Limit, millicores |
Memory / Request, MB |
Memory / Limit, MB |
|---|---|---|---|---|
0-10 |
100 |
200 |
200 |
400 |
10-100 |
250 |
500 |
250 |
500 |
>100 |
350 |
700 |
300 |
600 |
Для сервисного прокси требуемые и максимальные значения задаются администраторами с помощью настроек контрольной панели (компонент POLM). Если требуется установить другие значения ресурсов сервисного прокси, то можно переопределить их с помощью аннотаций в Deployment прикладного сервиса.
Чтобы переопределить настройки по умолчанию, нужно добавить аннотацию в Deployment прикладного сервиса:
apiVersion: apps/v1
kind: Deployment
spec:
template:
metadata:
annotations:
sidecar.istio.io/inject: 'true'
sidecar.maistra.io/proxyCPULimit: 300m
sidecar.maistra.io/proxyMemoryLimit: 300Mi
sidecar.istio.io/proxyCPU: 300m
sidecar.istio.io/proxyMemory: 300Mi
Подготовка окружения#
Перед установкой проверьте соблюдение следующих условий:
Развернутый и настроенный кластер Платформы (Kubernetes 1.19 и выше);
В кластере создан проект для развертывания контрольной панели Synapse Service Mesh (компонент POLM);
В кластере создан прикладной проект и подключен к контрольной панели Synapse Service Mesh (компонент POLM). Действия по подключению проекта выполняют администраторы контрольной панели.
Установка#
Установка платформенных зависимостей производится по с инструкции, входящей в комплект соответствующих дистрибутивов.
Перед началом установки сервисного прокси необходимо убедиться в том, что в кластере платформы установлен компонент POLM, в состав которого входит докер-образ сервисного прокси.
Установка сервисного прокси представляет собой внедрение в Pod прикладного сервиса дополнительного контейнера (istio-proxy), функционирующего в режиме sidecar.
Чтобы установить в Pod прикладного сервиса контейнер с сервисным прокси, добавьте аннотацию в Deployment приложения прикладного сервиса. Проект прикладного сервиса при этом должен быть подключен к одной из контрольных панелей Synapse Service Mesh (компонент POLM) в соответствии с документацией на POLM.
apiVersion: apps/v1
kind: Deployment
spec:
template:
metadata:
annotations:
sidecar.istio.io/inject: 'true'
Для внесения изменений в конфигурацию уже установленного проекта пользователь должен иметь права изменения ресурсов Deployment в проекте.
Обновление#
Все настройки сервисного прокси устанавливаются в проекте контрольной панели Synapse Service Mesh, в котором развернут сервис управления политиками (компонент POLM).
Именно сервис Управления политиками автоматически добавляет (инжектит) сервисный прокси в прикладной Pod. Для обновления сервисного прокси необходимо обновить сервис управления политиками (компонент POLM) на новую версию, чтобы он при инжекте вставлял новый образ сервисного прокси. Процес обновления описан в документации по компоненте POLM Руководство по установке в разделе Обновление.
Для обновления сервисного прокси в приложении, требуется провести рестарт Pod, после чего новая версия сервисного прокси загрузится автоматически для всех прикладных сервисов подключенных к контрольной панели Synapse Service Mesh. Рестарт может осуществляться с использованием различных стратегий, например, rolling update, в зависимости от требований приложений, запущенных в данном Pod.
Удаление#
Для удаления Sidecar istio-proxy из Pod прикладного сервиса необходимо отредактировать Deployment приложения прикладного сервиса и указать false в значении sidecar.istio.io/inject:
apiVersion: apps/v1
kind: Deployment
spec:
template:
metadata:
annotations:
sidecar.istio.io/inject: 'false'
Для внесения изменений в конфигурацию уже установленного проекта пользователь должен иметь права изменения ресурсов Deployment в проекте.
Проверка работоспособности#
Проверка работоспособности платформенных зависимостей производится по с инструкции, входящей в комплект соответствующих дистрибутивов.
Зайти в нужный проект;
В меню выбрать пункт Workload/Pods;
На странице найти нужный Pod прикладного сервиса;
Нажать на вкладку
⋮и выбрать Logs;Выбрать контейнер сервисного прокси (istio-proxy);
В консоли не должно быть ошибок;
Убедиться, что есть строка Envoy proxy is ready (прокси готов к работе).

Также можно убедиться в том, что сам сервисный прокси запущен путем просмотра статуса контейнера istio-proxy. Статусы Ready и Started должны быть в значении True.
Проверка работоспособности интеграций#
При реализации архитектуры с компонентом LOGA необходимо ознакомиться с методами проверки работоспособности в документации указанных компонент.
Откат#
Откат сервисного прокси на предыдущую версию может быть выполнен только в рамках отката компоненты POLM в контрольной панели Synapse Service Mesh. Процесс отката описан в документации POLM Руководство по установке в разделе Откат.
Часто встречающиеся проблемы и пути их устранения#
Проблема |
Пути решения |
|---|---|
Сервисный прокси не может подключиться к компоненту POLM, в системном журнале видно сообщение Envoy proxy is NOT ready |
Проверьте корректность подключения к контрольной панели Synapse Service Mesh. |
До прикладного приложения не доходят запросы |
Проверьте access-логи сервисного прокси. Возможные варианты сообщений описаны ниже. |
В access-логе сервисного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Если вызов направлен на внутренний сервис, проверьте наличие сервиса с таким именем, проверьте корректность параметров хост/порт в конфигурационных файлах прикладного проекта - Gateway, DestinationRule и VirtualService. Если вызов направлен на внешний хост, проверьте наличие конфигурационного файла ServiceEntry для данного сочетания хост/порт |
В access-логе сервисного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Проверьте корректность конфигурации раздела connectionPoolSettings в DestinationRule |
В access-логе сервисного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Если вы используете автоматическую аутентификацию ISTIO_MUTUAL, проверьте наличие конфликта в разделе trafficPolicy конфигурационного файла DestinationRule, относящегося к проблемному сервису, и раздела Spec/mTLS конфигурационного файла peerAuthentication. В случае указания разных режимов работы в поле TLS - возможны указанные ошибки |
В access-логе сервисного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Проверьте наличие вызываемого сервиса - в веб-интерфейсе Home/Networking/Services/Search_by_name найдите сервис. Проверьте наличие запущенного Pod, на который ссылается сервис - в веб-интерфейсе кликните правой кнопкой мыши на найденный сервис, выберите вкладку Pods на открывшейся странице, убедитесь, что статус Pods на данной странице имеет значение running |
Если указанные пути решения не помогли, обратитесь к системным администраторам контрольной панели Synapse Service Mesh.
Чек-лист валидации установки#
Слева в меню Workloads выберите раздел Pods.
В списке выберите Pod нужного прикладного сервиса и перейдите в него.
На вкладке Details в разделе Containers должен появиться контейнер с сервисным прокси (istio-proxy).