Установка#

Важно!

С версии 3.11 осуществлен переход на установку с помощью Helm Chart!

Состав дистрибутива#

Выбор способа установки#

В зависимости от способа развертывания сервиса воспользуйтесь одной из инструкций:

• ручная установка сервиса;

• автоматизированная установка сервиса с использованием Deploy Tools;

• автоматизированная установка сервиса по агентской схеме с использованием Deploy Tools;

• автоматизированная установка сервиса с использованием Synapse Installer.

Подготовка окружения#

1. Namespace, в который требуется установить компонент SRLS, должен быть подключен к Istio: убедиться, что в namespace существуют стандартные Config Map Istio с именем istio-ca-root-cert (если нет, то добавить).

2. Убедиться, что в namespace существует ServiceAccount c именем default (если нет, то добавить).

3. Для доступа к образам из среды контейнеризации к Docker-registry требуется создать ImagePullSecret (<дистрибутив>/package/conf/helm/application/srls/templates/secrets/rls-image-pull-secret.yaml), для этого нужно подготовить JSON вида:

{"auths":{"registry.local.host.ru":{"username":"user","password":"pass","auth":"auth-b64","email":""}}}

Здесь:

• user — учетная запись для доступа к registry.local.host.ru;

• pass — пароль учетной записи;

• auth-b64 — base64 от строки в формате user:pass.

Заполнить поле .dockerconfigjson получившимся JSON:

kind: Secret
apiVersion: v1
metadata:
  name: rls-image-pull-secret
  namespace: ${srls.namespace}
data:
  .dockerconfigjson: >-
type: kubernetes.io/dockerconfigjson

4. Связать секрет rls-image-pull-secret с ServiceAccount, который используется для скачивания образов. Пример команды для Kubernetes:

   kubectl secrets link default rls-image-pull-secret --for=pull -n <namespace>

Здесь namespace — уникальное имя пространства.

Пример команды для OpenShift:

oc secrets link default rls-image-pull-secret --for=pull

5. Создать или обновить артефакт CustomResourceDefinition в среде контейнеризации Kubernetes или Red Hat OpenShift (опционально).

Пользовательские ресурсы являются расширением API Kubernetes. Артефакт CustomResourceDefinition (сокращенно CRD) позволяет определять пользовательские ресурсы — указать тип и схему ресурса. Добавление артефакта CRD позволяет затем использовать новые пользовательские ресурсы.

В нашем случае для артефактов типа GlobalRateLimit необходимо добавить следующий CRD: артефакт CRD.

В некоторых случаях для добавления CRD администраторы требуют артефакт типа CRDProxy, где в поле data размещен непосредственно CRD:

apiVersion: apps.firepaws.io/v1
kind: CRDProxy
metadata:
  name: crdproxy-globalratelimits-ratelimit-service
  namespace: ${srls.namespace}
serviceAccount:
  - rate-limiter-service
data: |-
  < содержимое нашего артефакта СRD >

Выбор Key-Value хранилища#

Доступные варианты Key-Value хранилища:

• Radish (поставляется в составе SRLS);

• Redis (в составе SRLS поставляются только скрипты развертывания).

Централизованный вариант развертывания#

Сертификаты для Egress Gateway#

Необходимо подготовить сертификаты для Egress Gateway (ca-root.pem, egress.key, egress.pem, kafka-ca.pem, kafka.key, kafka.pem), рекомендуемая утилита для генерации и выпуска сертификатов — OpenSSL.

Для хранения «чувствительной» информации с точки зрения безопасности целевым подходом является интеграция с Secret Management System.

• Вариант установки с Secret Management System.

Добавить необходимые сертификаты в Key-Value хранилище. Структура секрета в хранилище в формате JSON:

{
    "ca": "-----BEGIN CERTIFICATE-----<...>-----END CERTIFICATE-----\n",
    "crt": "-----BEGIN CERTIFICATE-----<...>-----END CERTIFICATE-----\n",
    "key": "-----BEGIN RSA PRIVATE KEY-----<...>-----END RSA PRIVATE KEY-----\n"
    "ttl": "3m"
}

Ключи в хранилище должны соответствовать указанным:

• Вариант установки без Secret Management System.

Добавить в Kubernetes или Red Hat OpenShift (опционально) секрет egress-secrets. Секрет может быть создан с помощью инструмента командной строки или через файл манифеста Secret.

Пример команды для Kubernetes:

   kubectl create secret generic egress-secrets \
                --from-file=ca-root.pem=ca-root.pem \
                --from-file=egress.key=egress.key \
                --from-file=egress.pem=egress.pem \
                -n <namespace>

   kubectl create secret generic egress-kafka-cert \
                --from-file=ca-root.pem=kafka-ca.pem \
                --from-file=egress.key=kafka.key \
                --from-file=egress.pem=kafka.pem \
                -n <namespace>

Здесь namespace — уникальное имя пространства.

Пример команды для OpenShift:

   oc create secret generic egress-secrets \
                --from-file=ca-root.pem=ca-root.pem \
                --from-file=egress.key=egress.key \
                --from-file=egress.pem=egress.pem

   oc create secret generic egress-kafka-cert \
                --from-file=ca-root.pem=kafka-ca.pem \
                --from-file=egress.key=kafka.key \
                --from-file=egress.pem=kafka.pem

Пример манифестов:

kind: Secret
apiVersion: v1
metadata:
  name: egress-secrets
  namespace: ${srls.namespace}
data:
  ca-root.pem: >-

  egress.key: >-

  egress.pem: >-

type: Opaque

kind: Secret
apiVersion: v1
metadata:
  name: egress-kafka-cert
  namespace: ${srls.namespace}
data:
  kafka-ca.pem: >-

  kafka.key: >-

  kafka.pem: >-

type: Opaque

Здесь поля ca-root.pem, egress.key, egress.pem, kafka-ca.pem, kafka.key, kafka.pem должны быть заполнены данными из соответствующих файлов в base64-кодировке.

Пример команды для получения данных в формате base64:

base64 -w 0 ca-root.pem

Сертификаты для RL Service#

Если планируется использование шифрования трафика между граничным прокси и централизованным RL Service, необходимо подготовить сертификаты для RL Service (ca-root.pem, server.key, server.pem). Рекомендуемая утилита для генерации и выпуска сертификатов — OpenSSL.

Для хранения «чувствительной» информации с точки зрения безопасности целевым подходом является интеграция с Secret Management System.

• Вариант установки с Secret Management System.

Добавить необходимые сертификаты в Key-Value хранилище. Структура секрета в хранилище в формате JSON:

{
    "ca": "-----BEGIN CERTIFICATE-----<...>-----END CERTIFICATE-----\n",
    "crt": "-----BEGIN CERTIFICATE-----<...>-----END CERTIFICATE-----\n",
    "key": "-----BEGIN RSA PRIVATE KEY-----<...>-----END RSA PRIVATE KEY-----\n"
    "ttl": "3m"
}

Ключи в хранилище должны соответствовать указанным:

• Вариант установки без Secret Management System.

Добавить в Kubernetes или Red Hat OpenShift (опционально) секрет rate-limiter-secrets. Секрет может быть создан с помощью инструмента командной строки или через файл манифеста Secret.

Пример команды для Kubernetes:

   kubectl create secret generic rate-limiter-secrets \
                --from-file=ca-root.pem=ca-root.pem \
                --from-file=egress.key=server.key \
                --from-file=egress.pem=server.pem \
                -n <namespace>

Здесь namespace — уникальное имя пространства.

Пример команды для OpenShift:

   oc create secret generic rate-limiter-secrets \
                --from-file=ca-root.pem=ca-root.pem \
                --from-file=egress.key=server.key \
                --from-file=egress.pem=server.pem

Пример манифеста:

kind: Secret
apiVersion: v1
metadata:
  name: rate-limiter-secrets
  namespace: ${srls.namespace}
data:
  ca-root.pem: >-

  server.key: >-

  server.pem: >-

type: Opaque

Здесь поля ca-root.pem, server.key, server.pem должны быть заполнены данными из соответствующих файлов в base64-кодировке.

Пример команды для получения данных в формате base64:

base64 -w 0 ca-root.pem

Ролевая модель централизованного варианта развертывания#

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

Ниже приведены артефакты, необходимые для настройки прав доступа (актуальные артефакты доступны в <дистрибутив>/package/conf/k8s/base/other/operator-role):

• ServiceAccount:

kind: ServiceAccount
apiVersion: v1
metadata:
  name: rate-limiter-service
  namespace: ${srls.namespace}

• ClusterRole:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rate-limiter-service-operator
rules:
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - ratelimit.service
    resources:
      - globalratelimits
  - verbs:
      - get
      - list
      - watch
      - update
      - patch
    apiGroups:
      - ratelimit.service
    resources:
      - globalratelimits/status
      - globalratelimits/finalizers

• ClusterRoleBinding:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rloperator-crb-${srls.namespace}
subjects:
  - kind: ServiceAccount
    name: rate-limiter-service
    namespace: ${srls.namespace}
roleRef:
  kind: ClusterRole
  name: rate-limiter-service-operator
  apiGroup: rbac.authorization.k8s.io

• Lease (если не создается в рамках установки через Deploy Tools):

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  name: srls-operator-lock
  namespace: ${srls.namespace}
  labels:
    app: rloperator
    proj: synapse-rls
    agent: srls

• Role:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: srls-operator-role
  namespace: ${srls.namespace}
rules:
  - verbs:
      - get
      - update
      - patch
    apiGroups:
      - 'coordination.k8s.io'
    resources:
      - leases
    resourceNames:
      - srls-operator-lock
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create

• RoleBinding:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rloperator-rb
  namespace: ${srls.namespace}
subjects:
  - kind: ServiceAccount
    name: rate-limiter-service
    namespace: ${srls.namespace}
roleRef:
  kind: Role
  name: srls-operator-role
  apiGroup: rbac.authorization.k8s.io

• ClusterRole:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: srls-role
rules:
  - verbs:
      - get
      - list
      - watch
      - create
      - update
      - patch
      - delete
    apiGroups:
      - networking.istio.io
    resources:
      - envoyfilters

Артефакт, который необходимо создать команде сопровождения прикладного namespace для подключения к централизованному SRLS:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: srls-role-binding
  namespace: ${namespace}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: srls-role
subjects:
- kind: ServiceAccount
  name: rate-limiter-service
  namespace: ${srls.namespace}

Сетевая видимость RL Service в рамках кластера#

Для обеспечения возможности подключения к Pod RL Service из других namespace необходимо создать артефакт (актуальный шаблон артефакта расположен в <дистрибутив>/package/conf/k8s/base/other/network-policy.yaml):

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: rlservice
  namespace: ${rls-namespace}
spec:
  podSelector:
    matchLabels:
      app: rls
      proj: synapse-rls
  ingress:
    - ports:
        - protocol: TCP
          port: 8081
      from:
        - podSelector:
            matchLabels:
              srls: ratelimit
          namespaceSelector: {}
  policyTypes:
    - Ingress

Артефакт разрешает входящий трафик в namespace централизованного SRLS к Pod RL Service по порту 8081 из других namespace, но только для Pod, у которых есть label srls: ratelimit. Данный подход позволяет сократить время на запрос к RL Service за счет прямого обращения, минуя Egress Gateway и Ingress Gateway.

Децентрализованный вариант развертывания#

Ролевая модель децентрализованного варианта развертывания#

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

При автоматизированном создании артефактов EnvoyFilter компонентом RL Operator в процессе обработки артефакта GlobalRateLimit (в параметре operator.disableEnvoyFilterAutomation установлено значение false) EnvoyFilters создаются для версий Envoy 1.25 (Istio 1.17, SSM 3.9) и выше (версии ниже не поддерживаются).

Возможен вариант развертывания, при котором не производится автоматизированное создание артефактов EnvoyFilter. В этом случае необходимо выбрать соответствующий артефакт Role, установить значение true стендозависимого параметра operator.disableEnvoyFilterAutomation и создать необходимые для работы артефакты EnvoyFilter самостоятельно. Инструкция по созданию артефакта EnvoyFilter описана в подразделе «Конфигурирование артефактов среды контейнеризации и Istio для децентрализованного варианта развертывания» раздела Подключение и конфигурирование документа «Руководство прикладного разработчика».

Ниже приведены артефакты, необходимые для настройки прав доступа (актуальные артефакты доступны в <дистрибутив>/package/conf/k8s/base/operator-role/other):

• ServiceAccount:

kind: ServiceAccount
apiVersion: v1
metadata:
  name: rate-limiter-service
  namespace: ${namespace}

• Role с поддержкой автоматизированного создания артефакта EnvoyFilter: srls-decentr-operator-role.yaml.

• Role без поддержки автоматизированного создания артефакта EnvoyFilter (опционально): srls-decentr-operator-role.yaml.

• Lease (если не создается в рамках установки через Deploy Tools):

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  name: srls-operator-lock
  namespace: ${namespace}
  labels:
    app: rloperator
    proj: synapse-rls
    agent: srls

• RoleBinding:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rloperator
  namespace: ${namespace}
subjects:
  - kind: ServiceAccount
    name: rate-limiter-service
    namespace: ${namespace}
roleRef:
  kind: Role
  name: srls-decentr-operator-role
  apiGroup: rbac.authorization.k8s.io

Параметры установки#

Параметры шаблонизации расположены в <дистрибутив>/package/conf/helm/application/srls/values.yaml.

Пример значения параметра endpoints:

[{"endpoint": "test-server2-endpoint:8080","name": "test service2","shortname": "server2","overall_limit": 100,"by_header": {"header": "synapse-consumerid","uri_prefixes": [{"uri_prefix": "/service","unit":"second","value": 5,"soft": {"step": 2,"value": 1},"anon_value": 10,"invokers": [{"header_value": "test-client-namespace2","name": "invoker_prefix_2","unit": "second","value": 10,"soft": {"step": 2,"value": 1}},{"header_value": "test-client-namespace1","name": "invoker_prefix_1","unit": "second","value": 5}]}]}},{"endpoint": "test-server-endpoint:8080","name": "test service","shortname": "server","overall_limit": -1,"by_header": {"header": "synapse-consumerid","unit": "minute","value": 5,"soft": {"step": 2,"value": 1},"anon_value": 10,"invokers": [{"header_value": "test-client-namespace2","name": "invoker2","unit": "second","value": 10,"soft": {"step": 2,"value": 1}},{"header_value": "test-client-namespace1","name": "invoker1","unit": "second","value": 5}]}},{"endpoint": "test-server3-endpoint:8080","name": "test service","shortname": "server","overall_limit": -1,"by_path": {"mask": "mask","unit": "second","quotas": {"flat": 7,"soft": {"step": 2,"value": 4}},"tenants": [{"name": "tenant1","resourceName": "rntenant1","unit": "second","quotas": {"soft": {"step": 1,"value": 2}}},{"name": "tenant2","resourceName": "rntenant2","unit": "second","quotas": {"flat": 1}}]}}]

Пример значения параметра bodySizesEntries:

[{"body_sizes_key": "size1", "body_sizes": [{"body_size":"5Ki", "value": 2}, {"body_size": "2M", "value": 5}]}, {"body_sizes_key": "size2", "body_sizes": [{"body_size": "100", invokers: [{"name": "invoker 1", "header_value": "invoker-1", "value": 15}]}]}]

Список стендозависимых параметров (указываются в конфигурации job) для установки и их описание представлены в таблице «Список и описание параметров». Стендозависимые параметры расположены в том же файле <дистрибутив>/package/conf/helm/application/srls/values.yaml.

Важно!

Названия стендозависимых параметров, начиная с версии компонента SRLS 4.2, отличаются от названий в предыдущих версиях.

Список и описание параметров:

Параметры числа реплик Pod:

Параметры лимитов и запросов ресурсов для Egress Gateway:

Параметры лимитов и запросов ресурсов для RL Operator:

Параметры лимитов и запросов ресурсов для Istio Sidecar RL Operator:

Параметры лимитов и запросов ресурсов для RL Service:

Параметры лимитов и запросов ресурсов для Istio Sidecar RL Service (объем ресурсов зависит от потребителя, рекомендуется определять по результатам нагрузочного тестирования):

Параметры лимитов и запросов ресурсов для Radish:

Параметры лимитов и запросов ресурсов для Istio Sidecar Radish (объем ресурсов зависит от потребителя, рекомендуется определять по результатам нагрузочного тестирования):

Параметры лимитов и запросов ресурсов для Redis:

Параметры лимитов и запросов ресурсов для Redis Sentinel:

Параметры конфигурирования классов приоритетов:

Параметры конфигурирования стратегии RollingUpdate:

Список параметров для настройки артефакта GlobalRateLimit при развертывании по агентской схеме.

Значения по умолчанию, приведенные в двойных фигурных скобках, указывают на стандартные переменные Job CDJE DevTools.

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

Централизованный вариант развертывания:

Централизованный вариант (c шифрованием TLS) развертывания:

Централизованный вариант (без EnvoyFilter) развертывания:

Примечание! Не создавать артефакты ClusterRole srls-role и RoleBinding srls-role-binding, указанные в подразделе «Ролевая модель централизованного варианта развертывания» раздела «Подготовка окружения» данного документа.

При необходимости включения TLS требуется дополнительно задать параметры srls.tlsEnabled и rls.tls.enable в true.

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

Выбор Key-Value хранилища:

Для отправки логов средствами, встроенными в RL Operator и RL Service, необходимо дополнительно установить параметр шаблонизации:

srls.logSenderEnabled: true

Установить значения у следующих стендозависимых параметров:

egress.kafka.updateEfEnabled: true  // true – обновление списка egress.kafka.bootstrap; false – фиксированный набор egress.kafka.bootstrap
egress.kafka.port: 9093
egress.kafka.proxy.port: 9093
egress.kafka.proxy.resolution: DNS
egress.kafka.bootstrap:   // заполнить значение для используемого кластера kafka
  - host: kafka.test.ru
    port: 9093
    ip: 10.0.0.1
logging.senderType: kafka
logging.kafkaBootstrapServers: egressgateway-rls-svc:{egress.kafka.port}
logging.kafkaTopic: rls_test_topic      // установить свой топик для отправки
logging.tls.securityProtocol: plaintext

Выбор параметров пула соединений для RL Service#

При использовании Key-Value хранилища Radish соединения до сервера Radish хранятся в пуле для повторного использования. Переиспользование соединений позволяет повысить производительность SRLS, так как создание соединений является «дорогостоящей» операцией, особенно при использовании istio-sidecar (и особенно при включенном шифровании трафика между istio-sidecar). Пул соединений Radish может быть:

• статический – количество соединений фиксированное, новые соединения создаются только при отказе открытых ранее соединений;

• динамический – количество соединений может варьироваться от минимального до максимального значений, новые соединения создаются и сохраняются при необходимости, динамически созданные соединения закрываются с течением времени.

Использование пула большого размера позволяет снизить накладные расходы на отправку запросов, но увеличивает нагрузку на инфраструктуру (istio-sidecar на стороне RL Service и Radish), замедляет старт подов RL Service (ввиду необходимости создания большого количество соединений при запуске), замедляет процесс становления нового master (при выборе нового master все экземпляры RL Service пересоздают соединения). Динамический пул позволяет снизить накладные расходы во время более высокой нагрузки, но не испытывать негативных последствий большого количества соединений во время более низкой нагрузки.

Для использования статического пула значение параметра rls.radishPoolMaxSize не должно превышать значение параметра rls.radishPoolMinSize. Если же rls.radishPoolMaxSize превышает rls.radishPoolMinSize, то будет использован динамический пул. Добавление новых соединений в динамический пул происходит при необходимости использования соединения, когда в пуле нет доступных соединений. Поведение динамического пула можно описать следующим образом:

• при создании пула открывается rls.radishPoolMinSize соединений;

• если rls.radishPoolMinSize соединений достаточно для обработки входящей нагрузки, то новые соединения не создаются;

• если при повышении нагрузки rls.radishPoolMinSize соединений становится недостаточно (пул опустошается), то создаются новые соединения, но не более (rls.radishPoolMaxSize-rls.radishPoolMinSize) штук;

• после снижения нагрузки запускается механизм удаления динамически созданных соединений, со временем в пуле остается rls.radishPoolMinSize соединений.

Динамически созданные соединения удаляются из пула с интервалом кратным rls.radishPoolShrinkThresholdSeconds секунд по rls.radishPoolShrinkValue штук за итерацию.

Установка EnvoyFilter для SRLS#

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

Ограничение: текущая реализация шаблонов EnvoyFilter совместима с версиями Envoy 1.25 (Istio 1.17, SSM 3.9) и выше (версии ниже не поддерживаются).

Список параметров для настройки артефактов EnvoyFilter при развертывании по агентской схеме:

После установки в namespace (limits.srlsConfig.namespace) появится:

1. EnvoyFilter «Cluster» с именем {limits.srlsConfig.namespace}-rls-cluster;

2. на каждый endpoint, указанный в поле endpoints, EnvoyFilter «Endpoint» с именем {limits.srlsConfig.namespace}-{ednpoint.shortname}.

Ручная установка сервиса#

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

1. Разархивировать дистрибутив.

2. Открыть консоль и перейти в папку package/conf/helm/application/srls дистрибутива.

3. Запустить установку в namespace командой:

helm upgrade srls .

Сборка образов для компонента SRLS из дистрибутива#

1. Разархивировать дистрибутив.

2. Открыть консоль и перейти в папку package/ дистрибутива.

3. Собрать образы, выполнив команды:

docker build -f docker/operator/Dockerfile . -t {registry}/{registry_path}/srls/operator:{version}

docker build -f docker/rls/Dockerfile . -t {registry}/{registry_path}/srls/rls:{version}

docker build -f docker/radish/Dockerfile . -t {registry}/{registry_path}/srls/radish:{version}

docker build -f docker/redis/Dockerfile . -t {registry}/{registry_path}/srls/redis:{version}

docker build -f docker/sentinel/Dockerfile . -t {registry}/{registry_path}/srls/sentinel:{version}

Здесь:

• registry – ссылка до registry;

• registry_path – базовый путь до каталога с образами;

• version – версия дистрибутива (например, 2.6).

4. Отправить образы в хранилище, выполнив команды:

docker push {registry}/{registry_path}/srls/operator:{tag}

docker push {registry}/{registry_path}/srls/rls:{tag}

docker push {registry}/{registry_path}/srls/radish:{tag}

docker push {registry}/{registry_path}/srls/redis{tag}

docker push {registry}/{registry_path}/srls/sentinel{tag}

Здесь:

• registry – ссылка до registry;

• registry_path – базовый путь до каталога с образами;

• tag – тег собранного образа, например, версия дистрибутива.

Предварительная настройка Deploy Tools#

*Важно!

Для корректной установки необходимо использовать компонент CDJE Deploy Tools продукта Platform V DevOps Tools (DOT) версии 1.3 и выше.

При обновлении на версию 3.11 в связи с переходом на установку при помощи Helm Chart для корректного обновления манифестов требуется удалить все ресурсы компонента SRLS из namespace (label proj: synapse-rls) и запустить установку новой версии.

В файле environment.json в блоке playbooks_fpi должны присутствовать сценарии HELM_DEPLOY и HELM_UNDEPLOY. Если их нет, то необходимо добавить:

{
   "playbooks_fpi": {
      "HELM_DEPLOY": {
         "id": 97
      },
      "HELM_UNDEPLOY": {
         "id": 98
      }
   }
}

Автоматизированная установка сервиса с использованием Deploy Tools#

Важно!

Для корректной установки необходимо выполнить шаг «Предварительная настройка Deploy Tools», описанный выше.

1. Настроить Job (дистрибутив собран с поддержкой Deploy Tools).

   Примечание — настройка заключается в указании для job параметров, описанных в разделе «Параметры установки» в таблицах «Параметры шаблонизации» и «Список и описание параметров».

2. Запустить миграцию конфигурационных файлов — набор сценариев MIGRATION_FP_CONF.

3. Скорректировать значения параметров шаблонизации и стендозависимых параметров.

   Примечание — значение параметра srls.deployToK8s определяет платформу контейнеризации для запуска компонентов сервиса (для установки Kubernetes и Platform V DropApp значение True).

4. Запустить установку — сценарий HELM_DEPLOY.

Автоматизированная установка сервиса по агентской схеме с использованием Deploy Tools#

Важно!

Для корректной установки необходимо выполнить шаг «Предварительная настройка Deploy Tools», описанный выше.

Данный вариант развертывания позволяет одновременно с установкой дистрибутива бизнес-приложения или технологического сервиса произвести автоматическую установку компонента SRLS и создать артефакт GlobalRateLimit. Возможен вариант только с созданием артефакта GlobalRateLimit без установки компонента SRLS.

1. Настроить Job бизнес-приложения или технологического сервиса.

   • В схему справочника конфигураций развертывания (subsystem.json) добавить секцию agents для определения конфигураций развертывания из дистрибутива SRLS:

     agents: {
       "SRLS_agent": {
           "groupId": "",
           "artifactId": "",
           "version": "",
           "fpi-name": "",
           "classifier": "",
           "packaging": "",
           ...
       }
   }
   

2. Запустить миграцию конфигурационных файлов, указав в поле параметров Job COMPONENTS сконфигурированный агент — набор сценариев MIGRATION_FP_CONF.

   • Настроечные параметры из дистрибутива SRLS будут подгружены в пространство конфигурирования бизнес-приложения или технологического сервиса.

3. Скорректировать значения параметров шаблонизации и стендозависимых параметров.

   • Для создания артефакта GlobalRateLimit необходимо выставить значение True параметра шаблонизации srls.deployLimits и заполнить параметры шаблонизации endpoints и bodySizesEntries в соответствии с разделом «Параметры установки» настоящего документа.

   • Если требуется установить артефакты EnvoyFilter, необходимо настроить соответствующие параметры, описанные в разделе «Установка EnvoyFilter для SRLS» данного документа.

   • Если требуется установить дистрибутив в децентрализованном варианте развертывания SRLS, необходимо настроить соответствующие параметры, описанные в разделах «Параметры установки» и «Параметры установки, специфичные для выбранного варианта развертывания» настоящего документа.

   • Если установка не требуется, необходимо выставить значение False параметров шаблонизации srls.deployCentr, srls.deployDecentr.

4. Запустить установку бизнес-приложения или технологического сервиса, указав в поле параметров Job COMPONENTS сконфигурированный агент — набор сценариев HELM_DEPLOY.

Автоматизированная установка сервиса с использованием Synapse Installer#

1. Скачать необходимую версию дистрибутива.

2. Получить из дистрибутива конфигурационный файл: <дистрибутив>/package/conf/helm/application/srls/values.yaml.

3. Поместить полученный в пункте выше файл в git-репозиторий со стендозависимыми параметрами.

   Важно!

   Для корректной установки файл должен быть помещен по следующему пути: <git-репозиторий>/<namespace>/package/conf/helm/srls/values.yaml.

4. Скорректировать значения параметров шаблонизации и стендозависимых параметров.

   Примечание — значение параметра srls.deployToK8s определяет платформу контейнеризации для запуска компонентов сервиса (для установки Kubernetes и Platform V DropApp значение True).

5. Запустить job с указанием git-репозитория с параметрами и указанием места установки.

Сбор метрик с сервиса#

Для сбора метрик с помощью Unimon необходимо добавить в ConfigMap name: opm.unimon.unimon-agent.conf параметр unimon-agent.sidecar.istio.exclude.outbound.ports: '2112,8081'.

Для сбора метрик с помощью GATM необходимо добавить задание srls-pods в файл scrape.yml конфигурации ConfigMap.

Пример ConfigMap (<дистрибутив>/package/conf/k8s/base/other/configmaps/synapse-metrics-cm.yaml):

kind: ConfigMap
apiVersion: v1
metadata:
  name: synapse-metrics-agent-scrapeconfig
  namespace: ${srls.namespace}
data:
  scrape.yml: |

    global:
      scrape_interval: 1m
      scrape_timeout: 1m
      external_labels:
        cluster: apps.ocp.syn-dev.solution.test
    scrape_configs:

    - bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      job_name: srls-pods
      scrape_interval: 15s     //интервал сбора метрик с Pod компонентов SRLS
      kubernetes_sd_configs:
      - role: pod
        namespaces:
          own_namespace: true
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [ __meta_kubernetes_pod_container_port_name]
        action: keep
        regex: metrics-(.+)
      - source_labels: [__meta_kubernetes_pod_label_proj]
        action: keep
        regex: synapse-rls
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: (.+):(?:\d+);(\d+)
        replacement: ${1}:${2}
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: kubernetes_pod_name
      scheme: http

Более подробно о параметрах конфигурации смотрите в документации на соответствующий компонент.

Установка dashboard в программном компоненте Indicator (INDA) программного продукта Platform V Monitor (OPM)#

В поставку дистрибутива входят следующие dashboard:

• SRLS.json — метрики работы сервиса srl;

• SRLS Go Metrics.json — метрики потребления ресурсов srl;

• SRLS Operator.json – метрики работы оператора RL Operator;

• SRLS Operator Go Metrics.json — метрики потребления ресурсов RL Operator;

• SRLS Client Metrics.json – метрики для биллинга потребителей;

• SRLS Radish.json — метрики работы Radish;

• SRLS Radish Go Metrics.json — метрики потребления ресурсов Radish.

Место хранения:

• Объединенный мониторинг Unimon — папка package/conf/other/dashboard.

• Сбор и анализ метрик GATM — папка package/conf/other/dashboard/GATM.

Для корректной работы Dashboard необходимо знать название таблицы в базе данных Druid, в которую осуществляется загрузка метрик от RL Service и RL Operator (узнать название таблицы можно у администраторов Platform V Monitor).

Для установки dashboard необходимо:

1. Выполнить вход в Indicator Platform V Monitor.

2. Перейти на вкладку «Dashboards» → «Manage» (1).

3. Нажать на кнопку «Import» (2).

   

Рисунок. Вкладка «Dashboards» компонента Indicator Platform V Monitor

4. Нажать на кнопку «Upload JSON file» (3).

   

Рисунок. Экран компонента Indicator Platform V Monitor, кнопка «Upload JSON file»

5. В появившемся окне выбрать файл с dashboard.

6. В окне выбрать источник базы данных для получения метрик «Indicator-Abyss» из выпадающего списка (4).

7. В поле «druidtable» изменить название (srlsunimon) таблицы в базе данных Druid на требуемое (5).

   

Рисунок. Экран компонента Indicator Platform V Monitor для настройки загруженного dashboard

8. Нажать на кнопку «Import».

Примеры dashboard:

Рисунок. Dashboard SRLS.json

Рисунок. Dashboard SRLS Operator.json

Рисунок. Dashboard SRLS Go Metrics.json, SRLS Operator Go Metrics.json, SRLS Radish Go Metrics.json

Рисунок. Dashboard SRLS Client Metrics.json

Рисунок. Dashboard SRLS Radish.json

Dashboard «SRLS Client Metrics» позволяет выбрать namespace, в котором развернут компонент SRLS, и уникальное название метрики (ratelimiterservice_rate_limit_*key*_over_limit), сформированное из CRD GlobalRateLimit в этом namespace. Для синхронизации данных с метриками, полученными в namespace с различных Pod компонентов SRLS, в dashboard используется параметр «rounding time» — период агрегации данных (1M,2M,5M,15M,30M,1H,2H).

Первая панель на dashboard отображает набор метрик, общих для всех потребителей. График Over limit indicators отображает набор лимитов и окрашивает в красный цвет соответствующий шестигранник при превышении установленной квоты за выбранный период отображения. График Soft limit events отображает события превышения установленных soft-квот. Графики Requests to SRLS и Requests to Endpoint '$key' отображают количество всех (красным) и одобренных SRLS (зеленым) запросов соответственно на весь SRLS и на endpoint (endpoint определяется на основе выбранной метрики ratelimiterservice_rate_limit_*key*_over_limit).

Панель «Request» отображает количество запросов за выбранный период агрегации для выбранной метрики ratelimiterservice_rate_limit_*key*_over_limit (график Requests to Consumer '$key'). Также на панели дополнительно отображаются значение и единица измерения квоты, соответствующие выбранной метрике.

Панель «Limit Status» отображает графики метрик следующих типов: near limit (превышение уровня 80% от установленной квоты), over limit (превышение установленной квоты) и soft limit (превышение установленной soft-квоты). Для каждого из типов лимитов представлены графики, соответствующие выбранной метрике ratelimiterservice_rate_limit_*key*_over_limit: Total $type limit — общее число запросов свыше соответствующей квоты; Delta $type limit — приращение числа запросов свыше соответствующей квоты за период агрегации данных.

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

Ниже описана интеграция с компонентами MONA и LOGA рекомендованного АО «СберТех» продукта Platform V Monitor, с компонентом GATM рекомендованного АО «СберТех» продукта Platform V Synapse Service Mesh и Системой управления секретами Secret Management System. На усмотрение пользователя могут быть настроены интеграции с аналогичными по функциональности продуктами от других производителей.

1. Интеграция с программным компонентом Объединенный мониторинг Unimon (MONA) реализована в соответствии с требованиями MONA: компонент публикует метрики в формате Prometheus. Для артефактов Service RL Operator, RL Service, Radish добавлены необходимые аннотации Prometheus:

• prometheus.io.path;

• prometheus.io.port;

• prometheus.io.scrape.

2. Интеграция с программным компонентом Сбор и анализ метрик (GATM) реализована в соответствии с требованиями GATM: компонент публикует метрики в формате Prometheus. Для артефактов Deployment RL Operator, RL Service, Radish добавлены необходимые аннотации:

• metrics.synapse.sber/path;

• metrics.synapse.sber/port;

• metrics.synapse.sber/scrape.

3. Интеграция с программным компонентом Журналирование (LOGA) реализована в соответствии с требованиями сервиса журналирования: используется FluentBit sidecar для компонентов RL Operator и RL Service.

При установке должна быть включена опция:

srls.fluentBitSidecarEnabled = true и заполнены соответствующие поля «ufs-logger» (см. раздел «Параметры установки»).

4. Интеграция с Системой управления секретами Secret Management System реализована установкой значения true стендозависимого параметра srls.vaultAgentEnabled (см. раздел «Параметры установки» данного документа).