Руководство по установке#

В руководстве приведены инструкции по установке компонента Сервисный прокси (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реда контейнеризации

Да

Kubernetes

1.21 и выше

Рекомендовано. Правообладателем АО «СберТех» также рекомендована среда контейнеризации – Platform V DropApp, см. раздел «Платформенные зависимости»

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

Cреда контейнеризации

Да

Red Hat OpenShift

4.6 и выше

Опционально

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

Базовая ОС для контейнеров

Да

ALT Linux

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 в проекте.

Проверка работоспособности#

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

  1. Зайти в нужный проект;

  2. В меню выбрать пункт Workload/Pods;

  3. На странице найти нужный Pod прикладного сервиса;

  4. Нажать на вкладку и выбрать Logs;

  5. Выбрать контейнер сервисного прокси (istio-proxy);

  6. В консоли не должно быть ошибок;

  7. Убедиться, что есть строка Envoy proxy is ready (прокси готов к работе).

Picture Picture

Также можно убедиться в том, что сам сервисный прокси запущен путем просмотра статуса контейнера istio-proxy. Статусы Ready и Started должны быть в значении True.

Проверка работоспособности интеграций#

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

Откат#

Откат сервисного прокси на предыдущую версию может быть выполнен только в рамках отката компоненты POLM в контрольной панели Synapse Service Mesh. Процесс отката описан в документации POLM Руководство по установке в разделе Откат.

Часто встречающиеся проблемы и пути их устранения#

Проблема

Пути решения

Сервисный прокси не может подключиться к компоненту POLM, в системном журнале видно сообщение Envoy proxy is NOT ready

Проверьте корректность подключения к контрольной панели Synapse Service Mesh.
Обратитесь к системным администраторам контрольной панели Synapse Service Mesh

До прикладного приложения не доходят запросы

Проверьте access-логи сервисного прокси. Возможные варианты сообщений описаны ниже.

В access-логе сервисного прокси видно сообщение:
NR (No route configured):
В конфигурации сервисного прокси отсутствует требуемый маршрут

Авторизуйтесь в прикладном проекте. Если вызов направлен на внутренний сервис, проверьте наличие сервиса с таким именем, проверьте корректность параметров хост/порт в конфигурационных файлах прикладного проекта - Gateway, DestinationRule и VirtualService. Если вызов направлен на внешний хост, проверьте наличие конфигурационного файла ServiceEntry для данного сочетания хост/порт

В access-логе сервисного прокси видно сообщение:
UO (Upstream overflow with circuit breaking):
Поставщик перегружен запросами

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

В access-логе сервисного прокси видно сообщение:
UF (Failed to connect to upstream):
Поставщик сбросил соединение

Авторизуйтесь в прикладном проекте. Если вы используете автоматическую аутентификацию ISTIO_MUTUAL, проверьте наличие конфликта в разделе trafficPolicy конфигурационного файла DestinationRule, относящегося к проблемному сервису, и раздела Spec/mTLS конфигурационного файла peerAuthentication. В случае указания разных режимов работы в поле TLS - возможны указанные ошибки

В access-логе сервисного прокси видно сообщение:
UH (No healthy upstream):
Поставщик неработоспособен

Авторизуйтесь в прикладном проекте. Проверьте наличие вызываемого сервиса - в веб-интерфейсе Home/Networking/Services/Search_by_name найдите сервис. Проверьте наличие запущенного Pod, на который ссылается сервис -  в веб-интерфейсе кликните правой кнопкой мыши на найденный сервис, выберите вкладку Pods на открывшейся странице, убедитесь, что статус Pods на данной странице имеет значение running

Если указанные пути решения не помогли, обратитесь к системным администраторам контрольной панели Synapse Service Mesh.

Чек-лист валидации установки#

  1. Слева в меню Workloads выберите раздел Pods.

  2. В списке выберите Pod нужного прикладного сервиса и перейдите в него.

  3. На вкладке Details в разделе Containers должен появиться контейнер с сервисным прокси (istio-proxy).