Установка#

Важно!

С версии 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 GRL.

• для артефактов типа LocalRateLimit необходимо добавить следующий CRD: артефакт CRD LRL.

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

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

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

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

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

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

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

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

При интеграции с сервисом журналирования и/или установке SRLS в режиме NЦОД необходимо подготовить сертификаты для 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-rloperator-secret. Секрет может быть создан с помощью инструмента командной строки или через файл манифеста Secret.

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

   kubectl create secret generic egress-rloperator-secret \
                --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-rloperator-secret \
                --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-rloperator-secret
  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

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

При установке SRLS в режиме NЦОД необходимо подготовить сертификаты для Ingress Gateway (ca-root.pem, ingress.key, ingress.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 (опционально) секрет ingress-rloperator-secret. Секрет может быть создан с помощью инструмента командной строки или через файл манифеста Secret.

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

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

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

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

   oc create secret generic ingress-rloperator-secret \
                --from-file=ca-root.pem=ca-root.pem \
                --from-file=ingress.key=ingress.key \
                --from-file=ingress.pem=ingress.pem

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

kind: Secret
apiVersion: v1
metadata:
  name: ingress-rloperator-secret
  namespace: ${srls.namespace}
data:
  ca-root.pem: >-

  egress.key: >-

  egress.pem: >-

type: Opaque

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

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

base64 -w 0 ca-root.pem

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

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

Использование Synapse Service Mesh/Istio для шифрования трафика#

При использовании механизма Synapse Service Mesh/Istio для шифрования трафика дополнительных действий не требуется — управлением сертификатов занимается контрольная панель Synapse Service Mesh/Istio.

Использование собственных сертификатов для шифрования трафика#

Важно! Целевым вариантом является использование сертификатов Synapse Service Mesh/Istio для шифрования трафика, поддержка собственных сертификатов для шифрования трафика планируется к удалению. При использовании собственных сертификатов не доступна функциональность белых списков (whitelist).

При использовании собственных сертификатов необходимо подготовить сертификаты для 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/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:
      - localratelimits
      - globalratelimits
  - verbs:
      - get
      - list
      - watch
      - update
      - patch
    apiGroups:
      - ratelimit.service
    resources:
      - localratelimits/status
      - localratelimits/finalizers  
      - 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/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:

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

• 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:

Параметры readiness проб для Egress Gateway:

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

Параметры readiness проб для Ingress Gateway:

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

Параметры readiness и liveness проб для RL Operator:

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

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

Параметры readiness и liveness проб для RL Service:

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

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

Параметры readiness и liveness проб для Radish:

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

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

Параметры readiness и liveness проб для Redis:

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

Параметры readiness и liveness проб для Redis Sentinel:

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

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

Параметры включения распределения Pod по разным Node среды исполнения:

Параметры для настройки взаимодействия с компонентом SYND:

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

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

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

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

Централизованный вариант (c шифрованием TLS с помощью Synapse Service Mesh/Istio) развертывания:

Централизованный вариант (c шифрованием TLS с помощью собственных сертификатов) развертывания:

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

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

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

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

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

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

srls.logSenderEnabled: true

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

egress.kafka.updateBootstrapServersEnabled: true  // true – обновление списка egress.kafka.bootstrap; false – фиксированный набор egress.kafka.bootstrap
egress.kafka.port: 19093
egress.kafka.proxy.port: 9093
egress.kafka.proxy.resolution: DNS
egress.kafka.bootstrap:   // заполнить значение для используемого кластера kafka
  - host: kafka.test.ru
    port: 9093
    ip: { IP_ADDRESS }  // указать фактический IP адрес брокера
logging.senderType: kafka
logging.kafkaBootstrapServers: egress-kafka-rls-svc.<srls.namespace>.svc.cluster.local:19093
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:

1. Автоматизированное создание компонентом RL Operator:

   • создание артефактов средствами Kubernetes;

   • применение конфигурации, созданной на основе артефактов EnvoyFilter, с использованием компонента SYND.

2. Ручное добавление:

   • самостоятельное создание артефактов;

   • развертывание артефактов с использованием Deploy Tools.

Выбор конкретного варианта зависит от значения стендозависимого параметра operator.envoyFilterCreationMode (см. раздел «Параметры установки» данного документа).

При выборе автоматизированного варианта артефакты EnvoyFilters создаются для версий Envoy 1.25 (Istio 1.17, SSM 3.9) и выше (версии ниже не поддерживаются)

Автоматизированное создание артефактов EnvoyFilter средствами Kubernetes#

Для автоматизированного создания артефактов EnvoyFilter в процессе обработки артефакта GlobalRateLimit средствами Kubernetes необходимо установить значение k8s стендозависимого параметра operator.envoyFilterCreationMode.

Применение конфигурации с использованием компонента SYND#

Для применения конфигурации с использованием компонента SYND необходимо установить значение synd стендозависимого параметра operator.envoyFilterCreationMode.

При выборе этого способа до установки SRLS должен быть установлен SYND, а также значение стендозависимого параметра srls.peerAuthMode должно быть STRICT.

Применение конфигурации происходит не чаще заданного в артефакте DiscoveryExport периода (см. стендозависимый параметр synd.requestRate в разделе «Параметры установки» данного документа).

Самостоятельное создание артефактов EnvoyFilter#

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

Данный вариант работы с артефактами EnvoyFilter является вариантом по-умолчанию.

Развертывание артефактов EnvoyFilter с использованием Deploy Tools#

Если автоматическое создание артефактов EnvoyFilter отключено (для стендозависимого параметра operator.envoyFilterCreationMode установлено значение manual), можно так же воспользоваться развертыванием артефактов EnvoyFilter с использованием Deploy Tools. Для этого необходимо параметры в секции 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 с использованием Deploy Tools» данного документа.

   • Если требуется установить дистрибутив в децентрализованном варианте развертывания 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/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_metrics_synapse_sber_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_metrics_synapse_sber_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_metrics_synapse_sber_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

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

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

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

• 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.

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

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

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. В появившемся окне выбрать файл с дашбордом.

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

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

   

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

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

Примеры дашбордов:

Рисунок. Дашборд SRLS.json

Рисунок. Дашборд SRLS Operator.json

Рисунок. Дашборд SRLS Go Metrics.json, SRLS Operator Go Metrics.json, SRLS Radish Go Metrics.json

Рисунок. Дашборд SRLS Client Metrics.json

Рисунок. Дашборд SRLS Radish.json

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

Первая панель на дашборде отображает набор метрик, общих для всех потребителей. График 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 (см. раздел «Параметры установки» данного документа).

5. Интеграция с компонентом SYND реализована установкой значения synd стендозависимого параметра operator.envoyFilterCreationMode (см. раздел «Параметры установки» данного документа).

6. Интеграция с Сервисом интеграции и оркестрации микросервисов в облаке (Istio или Platform V Synapse Service Mesh) реализована по умолчанию указанием в шаблонах артефактов аннотации sidecar.istio.io/inject: 'true', для этого namespace должен быть подключен к Istio (см. раздел «Подготовка окружения» данного документа).

7. Интеграция с брокером сообщений (Kafka или программным компонентом KFKA) реализована только для интеграции с программным компонентом Журналирование (LOGA) без FluentBit sidecar.

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

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