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

В руководстве приведены инструкции по установке компонента Synapse Rate Limiter (SRLS) продукта Synapse Enterprise Integration (SEI).

Термины и определения#

Системные требования#

Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются клиентом при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.

Системное программное обеспечение#

Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.

Здесь и далее поддерживаемой системой приложений-контейнеров является Kubernetes (использование Red Hat OpenShift – опционально). В именах и параметрах системы, в названиях переменных, настроек могут встречаться названия (в т.ч. сокращения) систем контейнеризации, которые одинаково применимы для обеих сред контейнеризации.

Примечание:

*

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

• Нет — категория ПО необязательна для функционирования сервиса (это означает, что сервис может выполнять свои основные функции без установки данной категории ПО).

**

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

Платформенные зависимости#

Для настройки, контроля и функционирования компонента реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех»:

Примечание:

***

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

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

**** Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».

Аппаратные требования#

Для установки компонента требуется следующая конфигурация аппаратного обеспечения:

1. Квота для установки централизованного варианта SRLS:

   1. количество ядер процессора — 5 ядер;

   2. объем оперативной памяти — 10 ГБ.

2. Квота для установки централизованного варианта SRLS c TLS-шифрованием:

   1. количество ядер процессора — 6 ядер;

   2. объем оперативной памяти — 12 ГБ.

3. Квота для установки децентрализованного варианта SRLS:

   1. количество ядер процессора — 3 ядра;

   2. объем оперативной памяти — 8 ГБ.

Для работы программного компонента в среде контейнеризации Kubernetes или Red Hat OpenShift 4.8 (опционально) необходимы следующие ресурсы:

• для компонента RL Operator (на 1 Pod, без учета fluent-bit sidecar и istio sidecar):

• для компонента RL Service (на 1 Pod, без учета fluent-bit sidecar и istio sidecar):

• для Redis (на 1 Pod):

• для Egress Gateway (на 1 Pod) — при централизованном варианте SRLS c TLS-шифрованием:

Методика расчета сайзинга#

Оценить производительность программного компонента SRLS можно по результатам нагрузочного тестирования. Были проведены тесты. Результаты:

На промежутке TPS, который был выбран для тестирования, отличие от линейной функции будет незначительное, поэтому по полученным результатам тестирования на основе линейной функции (x*a+b) аппроксимировали следующие формулы для расчета требуемых ресурсов CPU и Memory для Ingress и RLS в зависимости от интенсивности нагрузки (TPS):

CPU

• Ingress (с включенным SRLS) = Целевой TPS*0,7+69;

• Ingress (с выключенным SRLS) = Целевой TPS*0,565+18,5;

• RLS= Целевой TPS*0,371+60,3.

Memory — значения не изменяются (рост памяти не звафиксирован при изменении TPS):

• Ingress = 700;

• RLS = 150.

Необходимые ресурсы для компонента SRLS:

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

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

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

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

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

• автоматическая установка по агентской схеме;

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

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

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

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

3. Для доступа к образам из среды контейнеризации к Docker-registry требуется создать ImagePullSecret (<дистрибутив>/package/conf/k8s/base/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: ${rls_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 необходимо добавить следующий СRD: артефакт CRD.

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

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

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

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

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

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

• Вариант установки с SecMan.

Добавить необходимые сертификаты в 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"
}

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

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

Добавить в 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: ${rls_namespace}
data:
  ca-root.pem: >-

  egress.key: >-

  egress.pem: >-

type: Opaque

kind: Secret
apiVersion: v1
metadata:
  name: egress-kafka-cert
  namespace: ${rls_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 (далее SecMan).

• Вариант установки с SecMan.

Добавить необходимые сертификаты в 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"
}

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

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

Добавить в 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: ${rls_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: ${rls_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
  - verbs:
      - list
    apiGroups:
      - ''
    resources:
      - namespaces

• ClusterRoleBinding

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rloperator-crb-${rls_namespace}
subjects:
  - kind: ServiceAccount
    name: rate-limiter-service
    namespace: ${rls_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: ${rls_namespace}
  labels:
    app: rloperator
    proj: synapse-rls
    agent: srls

• Role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: srls-operator-role
  namespace: ${rls_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: ${rls_namespace}
subjects:
  - kind: ServiceAccount
    name: rate-limiter-service
    namespace: ${rls_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: ${rls_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 (в параметре disable_envoy_filter_automation установлено значение false) EnvoyFilters создаются для версии Envoy 1.25 и выше. Если в артефакте GlobaLRateLimit в параметре envoyVersion указана версия ниже 1.25, то артефакты EnvoyFilter не будут созданы и в статусе будет ошибка envoy version not supported.

Возможен вариант развертывания, при котором не производится автоматизированное создание артефактов EnvoyFilter. В этом случае необходимо выбрать соответствующий артефакт Role, установить значение true стендозависимого параметра disable_envoy_filter_automation и создать необходимые для работы артефакты 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

Установка#

Важно!

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

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

Параметры шаблонизации расположены в <дистрибутив>/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}}]}}]

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

ВАЖНО!
Названия стендозависимых параметров, начиная с версии компонента SRLS 2.6, отличаются от названий в предыдущих версиях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SRLS_LOG_SENDER_ENABLED: True

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

egress_kafka_update_ef_enabled: true  // true – обновление списка egress_kafka_bootstrap; false – фиксированный набор egress_kafka_bootstrap
egress_kafka_port: 9093
kafka_port: 9093
kafka_resolution: DNS
egress_kafka_bootstrap:   // заполнить значение для используемого кластера kafka
  - host: kafka.test.ru
    port: 9093
    ip: 10.0.0.1
log_rls_sender_type: kafka
log_kafka_bootstrap_servers: egressgateway-rls-svc:{egress_kafka_port}
log_rls_kafka_topic: rls_test_topic      // установить свой топик для отправки
log_rls_tls_security_protocol: plaintext

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

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

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/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/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 (лейбл 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. Скорректировать значения параметров шаблонизации и стендозависимых параметров.

   Примечание — значение параметра DEPLOY_TO_KUBERNETES определяет платформу контейнеризации для запуска компонентов сервиса (для установки 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 параметра шаблонизации DEPLOY_LIMITS и заполнить параметр шаблонизации endpoints в соответствии с разделом «Параметры установки» настоящего документа.

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

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

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. Скорректировать значения параметров шаблонизации и стендозависимых параметров.

   Примечание — значение параметра DEPLOY_TO_KUBERNETES определяет платформу контейнеризации для запуска компонентов сервиса (для установки 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: ${rls_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 – метрики для биллинга потребителей;

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

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

• Сбор и анализ метрик GATM — папка /k8s/base/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

Рисунок. Dashboard SRLS Client Metrics.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 — приращение числа запросов свыше соответствующей квоты за период агрегации данных.

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

Ниже описана процедура интеграции с рекомендованным АО «СберТех» продуктом Platform V Monitor. На усмотрение пользователя может быть настроена интеграция с аналогичным по функциональности продуктом от других производителей.

1. Интеграция с программным компонентом Объединенный мониторинг Unimon (MONA) реализована в соответствии с требованиями Unimon: компонент публикует метрики в формате Prometheus. Для артефактов Service rl-operator и RateLimiterService добавлены необходимые аннотации Prometheus с необходимыми значениями (см. выше):

• prometheus.io.path;

• prometheus.io.port;

• prometheus.io.scrape.

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

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

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

Обновление#

Обновление программного компонента осуществляется по одной из стратегий — Rolling или Recreate.

Стратегия Recreate:

• Удалить программный компонент согласно процедуре, описанной в разделе «Удаление».

• Установить программный компонент согласно процедуре, описанной в разделе «Установка».

Стратегия Rolling:

• Обновить артефакты согласно разделу «Установка».

Удаление#

Удаление централизованного Synapse Rate Limiter Service#

Для удаления Synapse Rate Limit необходимо удалить следующие ресурсы:

Удаление децентрализованного Synapse Rate Limiter Service#

Для удаления Synapse Rate Limit необходимо удалить следующие ресурсы:

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

1. Для проверки работоспособности необходимо включить расширенное логирование на Egress в прикладном namespace и Ingress Gateway в namespace Rate Limit. Это можно сделать с помощью: curl -XPOST localhost:15000/logging?level=debug

2. Включить LOG_LEVEL: debug у rate-limiter-service, изменив настройку в ConfigMap name: rls-config.

3. Выполнить запрос к сервису, доступ которого необходимо было ограничить, и смотреть логи rate-limiter-service и ingress.

4. Посмотреть логи Pod можно с помощью утилиты командной строки.

Пример команды для Kubernetes: kubectl logs <pod-name> -n <namespace>

Пример команды для OpenShift: oc logs <pod-name>

Здесь pod-name — уникальный идентификатор Pod, namespace — уникальное имя пространства.

Пример логов при штанной работе:

• Ingress Gateway;

• rate-limiter-service (при включенной опции LOG_LEVEL: debug) запрос сервису.

Показателем работоспособности является прохождение запроса и отображение в цепочке логов ingress-> rate-limiter-service к сервису (доступ к которому планируется ограничить).

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

Проверка работоспособности интеграции с Platform V SberLinux OS Server и Platform V DropApp#

1. Убедиться, что установка SRLS в среду контейнеризации DropApp произошла успешно.

2. Убедиться, что readiness/liveness-пробы Pods успешные и Pods по пробам периодически не перезапускаются.

3. Убедиться, что при выполнении команды cat /etc/os-release в terminal контейнера одного из Pod, поставляемого в рамках компонента SRLS, выводится информация о базовом образе SberLinux OS Server.

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

1. Убедиться, что установка SRLS произошла успешно (с параметром FLUENT_BIT_SIDECAR_ENABLED=True).

2. Убедиться, что readiness/liveness-пробы Pods успешные и Pods по пробам периодически не перезапускаются.

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

1. Убедиться, что установка SRLS произошла успешно.

2. Проверить в логах компонента Unimon-sender (часть компонента Объединенный мониторинг Unimon (MONA) продукта Platform V Monitor) наличие логов об отправке данных мониторинга SRLS в Kafka.

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

1. Убедиться, что readiness/liveness-пробы Pods RL Service (для централизованного варианта с TLS-шифрованием), Egress Gateway (при интеграции с компонентом LOGA) успешные и Pods по пробам периодически не перезапускаются.

2. Проверить в логах RL Service и Egress Gateway, что были получены секреты из хранилища SecMan.

Откат#

Откат производится развертыванием предыдущей версии SRLS, при этом должен быть выполнен откат стендозависимых параметров (если были изменения) в хранилище параметров.

Для отката необходимо удалить ресурсы текущей версии продукта (согласно разделу «Удаление» данного документа). Следуя документу «Руководство по установке», выполнить установку необходимой версии.

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

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

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

1. Namespace, в который требуется установить компонент SRLS, подключен к Istio.

2. Cоздан ImagePullSecret для доступа к образам из среды контейнеризации к Docker-registry.

3. Добавлен артефакт CustomResourceDefinition GlobalRateLimit.

4. В namespace существует ServiceAccount c именем default.

5. Параметры шаблонизации и стендозависимые параметры заполнены в соответствии с рекомендуемыми параметрами.

RL Operator:

• Следующие ресурсы доступны и отображаются в Kubernetes или Red Hat OpenShift (опционально):

• Запущено 2 Pod RL Operator.

• В логах Pod отсутствуют ошибки.

• Pods не уходят в перезапуск по результатам readiness/liveness-проб.

RL Service:

• Следующие ресурсы доступны и отображаются в Kubernetes или Red Hat OpenShift (опционально):

• Запущено 2 Pod RL Service.

• В логах Pod отсутствуют ошибки.

• Pods компонента не уходят в перезапуск по результатам readiness/liveness-проб.

Redis:

• Следующие ресурсы доступны и отображаются в Kubernetes или Red Hat OpenShift (опционально):

• Запущено 3 Pod Redis-sentinel и 3 Redis.

• В логах Pod отсутствуют ошибки.

• Pods не уходят в перезапуск по результатам readiness/liveness-проб.

При централизованном варианте SRLS Egress Gateway:

• Следующие ресурсы доступны и отображаются в Kubernetes или Red Hat OpenShift (опционально):

• Запущено 2 Pod Egress Gateway.

• В логах Pod отсутствуют ошибки.

• Pods не уходят в перезапуск по результатам readiness/liveness-проб.

6. Настроена интеграция «Клиентской части Unimon».

7. В логах компонента «Клиентской части Unimon Sender» присутствуют логи об отправке данных мониторинга SRLS в Kafka.

При успешном выполнении всех пунктов можно приступать к использованию сервиса.