Контейнеризированные, автоматически масштабируемые частные синтетические местоположения в Kubernetes

Материал из Документация Ключ-АСТРОМ
Версия от 03:39, 30 июля 2026; IKuznetsov (обсуждение | вклад) (Новая страница: « = Контейнеризированные, автоматически масштабируемые частные синтетические местоположения в Kubernetes = Контейнеризированные, автоматически масштабируемые частные синтетические среды в '''Kubernetes''' и его коммерческом дистрибутиве '''OpenShift''' являются альте...»)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)

Контейнеризированные, автоматически масштабируемые частные синтетические местоположения в Kubernetes

Контейнеризированные, автоматически масштабируемые частные синтетические среды в Kubernetes и его коммерческом дистрибутиве OpenShift являются альтернативой развертыванию АктивногоШлюза с поддержкой синтетических тестов на отдельных хостах или виртуальных машинах и последующему назначению их частным средам для выполнения синтетических мониторов.

В отличие от отдельных АктивныхШлюзов с поддержкой синтетического моделирования, которые развертываются и назначаются частным локациям (а затем отслеживаются с помощью метрик использования), контейнеризированные локации развертываются как единое целое, при этом минимальное и максимальное количество АктивныхШлюзов являются необходимыми входными параметрами.

Kubernetes и OpenShift — это не просто дополнительные поддерживаемые платформы АктивногоШлюза наряду с Windows и Linux; благодаря этому предложению, контейнеризированные частные синтетические среды:

  • Масштабируются автоматически (на основе показателей использования и указанного максимального/минимального количества АктивныхШлюзов).
  • Просты в управлении и обслуживании.
  • Обеспечивают поддержку синтетического мониторинга облачных решений, требующих разработки приложений на основе контейнеров.
  • Возможно ускоренное развертывание с минимальным временем простоя.
  • Автоматически отслеживается использование ресурсов в рамках операций автоматического масштабирования.

Вы можете управлять расположениями Kubernetes/OpenShift через веб-интерфейс Ключ-АСТРОМ и существующий API Synthetic - Locations, nodes, and configuration API v2. Дополнительные конечные точки раннего доступа в этом API упрощают развертывание расположений Kubernetes; новые конечные точки помогают генерировать команды, которые необходимо выполнить в кластере Kubernetes.

В контейнеризированных средах можно запускать как запланированные, так и запускаемые по запросу сценарии всех типов синтетических мониторов.

Архитектура

Контейнеризированные частные синтетические ячейки развертываются как единое целое.

В каждом местоположении настроено несколько АктивныхШлюзов с поддержкой синтетических вычислений, представленных в виде подов. Минимальное и максимальное количество АктивныхШлюзов указывается при настройке местоположения.

Объект StatefulSet рассматривается как местоположение.

В каждом пространстве имен может быть одно или несколько местоположений. См. раздел «Требования, рекомендации и оговорки» ниже.

В каждом кластере Kubernetes может быть одно или несколько автоматически масштабируемых местоположений.

Масштабирование местоположений осуществляется автоматически путем регулирования количества АктивныхШлюзов на каждое местоположение с помощью следующих дополнительных элементов контейнеризированной архитектуры местоположений.

Адаптер синтетических метрик запрашивает и получает метрики использования контейнеризированных АктивныхШлюзов от кластера Ключ-АСТРОМ.

  • В каждом кластере Kubernetes используется один адаптер синтетических метрик.
  • Метрический адаптер настроен для связи с одной средой Ключ-АСТРОМ.
  • Для установки адаптера синтетических метрик в Kubernetes требуются роли суперпользователя — см. раздел «Установка контейнеризированного местоположения» ниже.

Горизонтальный автоматический масштабировщик подов масштабирует местоположение, регулируя количество АктивныхШлюзов на основе данных об использовании, получаемых от адаптера синтетических метрик.

На каждом объекте установлен один горизонтальный автоматический масштабировщик подов.

Требования

Контейнерные частные синтетические местоположения поддерживаются с помощью Ключ-АСТРОМ версии 1.264+ на Kubernetes 1.22-1.25 с постоянным уровнем громкости и поддержкой kubectl.

  • Дополнительная поддержка для Kubernetes 1.26+ доступна в процессе установки.
  • Поддерживаются все виды реализаций Kubernetes, как облачные, так и локальные (например, облачные сервисы Kubernetes или Minikube).
  • Поддерживаются версии OpenShift, совместимые с поддерживаемыми версиями Kubernetes.
  • Для доступа к общедоступным репозиториям, где доступны образы Docker для АктивногоШлюза с поддержкой синтетических метрик и адаптера синтетических метрик, требуется подключение к Интернету. Ссылки на эти образы указаны в соответствующих файлах шаблонов — см. разделы «Установка контейнеризированного расположения» и «Обновление контейнеризированного расположения» ниже.

Таблица размеров

Ниже приведены требования к оборудованию АктивногоШлюза, сгруппированные по размерам.

  • Запросы на использование ЦП и ОЗУ относятся к ресурсам, резервируемым подами при их создании.
  • Ограничения по ЦП и ОЗУ указывают на максимальное потребление ресурсов на один под.
  • Если местоположение контролируется ЕдинымАгентом или другим решением для глубокого мониторинга, требования к оперативной памяти (RAM) возрастут.
  • В режиме FIPS для бесбраузерного пода предъявляются те же требования, что и для обычного бесбраузерного пода.
Компонент XS S M Браузерный под Бесбраузерный под Браузерный под с FIPS Браузерный под с FIPS и корпоративным прокси
АктивныйШлюз
Синтетический движок
Рабочий браузер -
FIPS-прокси - - - - -
FIPS-партнер - - - - - -
Контейнеры 14 2 15 16 1 12 12
Запросы ЦП 7.15 vCPU 1.15 vCPU 7.65 vCPU 7.8 vCPU 0.3 vCPU 1 vCPU 12 × 0.5 vCPU
Ограничения ЦП 20.3 vCPU 2.3 vCPU 21.8 vCPU 22.1 vCPU 0.3 vCPU 2 vCPU 12 × 1.5 vCPU
Запросы на ОЗУ 14.25 ГиБ 2.25 ГиБ 14.5 ГиБ 14.75 ГиБ 0.25 ГиБ 2 ГиБ 12 × 1 ГиБ
Ограничения ОЗУ 29 ГиБ 5 ГиБ 29.5 ГиБ 30 ГиБ 1 ГиБ 4 ГиБ 12 × 2 ГиБ
Временное хранение 2.5 ГиБ 1.3 ГиБ 2.6 ГиБ 2.7 ГиБ 1.2 ГиБ 0.1 ГиБ 12 × 0.1 ГиБ
Постоянное хранение 12 ГиБ 12 ГиБ 12 ГиБ 12 ГиБ - - -
ОЗУ-диск 4 ГиБ - 4 ГиБ 4 ГиБ - - -

Рекомендации и предостережения

АктивныеШлюзы

  • Мы рекомендуем использовать АктивныйШлюз размера S и как минимум два АктивныхШлюза на одно местоположение.
  • При выборе размера узла учитывайте возможные ограничения, специфичные для используемой вами службы Kubernetes.
  • Все АктивныеШлюзы в пределах одной территории всегда имеют одинаковый размер.
  • После указания размера АктивногоШлюза для местоположения изменить его невозможно, поскольку размер постоянного хранилища изменить нельзя.
  • В отношении местоположений Kubernetes действуют те же правила, что и в отношении других местоположений: АктивныйШлюз нельзя добавить одновременно в несколько местоположений.
  • Нельзя объединять АктивныйШлюз в контейнере и без контейнера в одном и том же месте.
  • Образ для АктивногоШлюза с поддержкой синтетического моделирования находится в общедоступном реестре; на это местоположение образа ссылается файл шаблона.

Местоположения

  • Мы рекомендуем устанавливать каждый раздел в отдельном пространстве имен.
  • При развертывании более одного местоположения в рамках одного пространства имен используйте разные имена для соответствующих ресурсов АктивногоШлюза — см. раздел «Установка контейнеризированного местоположения» ниже.
  • Для обеспечения автоматического масштабирования местоположения, использующее одно и то же пространство имен Kubernetes, должно быть подключено к той же среде Ключ-АСТРОМ, что и адаптер синтетических метрик. Например, предположим, что местоположение A и адаптер метрик настроены для среды X. Однако местоположение A использует то же пространство имен, что и местоположение B, настроенное для среды Y. В таком случае местоположение A масштабируется автоматически; местоположение B — нет.
  • Если вы хотите установить компонент в том же пространстве имен, что и другие ресурсы Ключ-АСТРОМ, такие как Оператор Ключ-АСТРОМ, имейте в виду, что для контейнеризированных АктивныхШлюзов с поддержкой Synthetic требуются более высокие аппаратные и системные ресурсы.

Синтетический метрический адаптер

  • Наилучшей практикой является развертывание адаптера синтетических метрик в собственном пространстве имен для каждого кластера Kubernetes. Адаптер синтетических метрик может использовать то же пространство имен, что и местоположение. Однако развертывание адаптера метрик в собственном пространстве имен гарантирует, что он не будет удален при отключении местоположения.
  • Метрический адаптер может взаимодействовать только с одной средой Ключ-АСТРОМ, поэтому автоматическое масштабирование по местоположению работает только для этой среды.
  • Образ адаптера синтетической метрики находится в общедоступном реестре; на это местоположение образа ссылается файл шаблона.

Особенности автоматического масштабирования

Для целей автоматического масштабирования адаптеру синтетических метрик необходим доступ к API Kubernetes и его расширение за счет указания новой службы APIv1beta1.external.metrics.k8s.io.

Данная служба API определена в шаблоне адаптера синтетических метрик — см. раздел «Установка и развертывание контейнеризированного местоположения» ниже.

Определение API-сервиса в шаблоне адаптера метрик

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.external.metrics.k8s.io
spec:
  service:
    name: astromkey-metrics-apiserver
    namespace: {{ adapterNamespace }}
  group: external.metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

Адаптер синтетических метрик также изменяет существующий ресурс в своем шаблоне — объект horizontal-pod-autoscaler ServiceAccount в пространстве имен kube-system. Изменение существующих ресурсов в шаблоне адаптера метрик

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: hpa-controller-astromkey-metrics
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: astromkey-metrics-server-resources
subjects:
  - kind: ServiceAccount
    name: horizontal-pod-autoscaler
    namespace: kube-system

Ограничения

Обратите внимание, что в кластере Kubernetes разрешен только один внешний сервер метрик. Поэтому другие компоненты, выполняющие функцию сервера метрик (например, надстройка KEDA или адаптер Prometheus), не могут использоваться вместе с адаптером синтетических метрик.

Установите контейнерное хранилище

Настройте и управляйте контейнеризированным местоположением в веб-интерфейсе Ключ-АСТРОМ в разделе Настройки > Веб- и мобильный мониторинг > Частные синтетические местоположения.

1. Первоначальная настройка для размещения Kubernetes/OpenShift

  1. На странице Частные синтетические расположения выберите Добавить расположение Kubernetes или Добавить расположение OpenShift.
  2. Укажите название местоположения на ваш выбор.
  3. Выберите географическое местоположение, например, San Francisco, California, United States. (Обратите внимание, что вы не сможете сохранить изменения, пока не укажете название и местоположение.)
  4. В разделе ActiveGates:
    • Укажите минимальное и максимальное количество АктивныхШлюзов для вашего местоположения. Эти параметры используются для автоматического масштабирования горизонтального пода.
    • Выберите размер узла АктивногоШлюза (XS, S, или M). См. также разделы «Требования» и «Рекомендации и предостережения».
  5. Платформа развертывания выбирается автоматически в зависимости от вашего выбора между Kubernetes и OpenShift.
  6. Только Kubernetes: Если ваша реализация Kubernetes основана на более поздней версии, чем 1.21–1.25, включите параметр Использовать Kubernetes версии 1.26+. См. также разделы «Требования» и «Рекомендации и предостережения».
    • Если вы измените этот параметр после загрузки шаблона расположения, вам потребуется повторить процедуру развертывания.
  7. (Необязательно) Вы можете отключить поддержку браузерных мониторов. В этом случае узел АктивногоШлюза будет рассматриваться как не использующий браузер.
  8. (Необязательно) Включить генерацию ошибок, если все АктивныеШлюзы отключаются.
  9. Сохраните изменения, прежде чем приступать к развертыванию адаптера местоположения и метрик.

Ваше именованное местоположение отображается на странице частных синтетических местоположений с логотипом Kubernetes или OpenShift. Обратите внимание, что на данный момент к местоположению не назначены АктивныеШлюзы.

2. Разверните местоположение

Выберите свое местоположение в разделе Частные синтетические местоположения, чтобы загрузить шаблон местоположения и сгенерировать команды, которые необходимо выполнить в кластере Kubernetes.

  1. В разделе Развертывание создайте токен PaaS (Создать токен) или вставьте существующий токен. Токен PaaS необходим для генерации токенов подключения АктивногоШлюза для связи с вашей средой Ключ-АСТРОМ.
    • Существующие токены перечислены на странице Токены доступа. Обратите внимание, что токен PaaS отображается только один раз при создании, после чего он хранится в зашифрованном виде и не может быть раскрыт. Мы рекомендуем хранить ваш токен PaaS в менеджере паролей, чтобы вы могли повторно использовать его для создания дополнительных приватных местоположений в вашем кластере Kubernetes.
  2. Укажите имя АктивногоШлюза или используйте имя по умолчанию. Это имя используется в качестве префикса для АктивныхШлюзов, развернутых в рамках указанного местоположения. Первый АктивныйШлюз называется <prefix>-0, второй — <prefix>-1, и так далее. Это имя также используется в качестве имени StatefulSet.
  3. Укажите имя пространства имен Location или используйте имя по умолчанию. (Оставьте пространство имен адаптера Metric без изменений. Это поле необходимо только для генерации шаблона для адаптера синтетических метрик.)
  4. Кнопка Загрузить synthetic.yaml становится доступной после того, как вы укажете токен PaaS, имя АктивногоШлюза и имя пространства имен местоположения.
  5. Значения полей в разделе Развертывание не сохраняются. При переходе на другую страницу вам потребуется повторно ввести значения.
  6. Выберите Скачать synthetic.yaml. Это файл шаблона для указания местоположения. Вы можете переименовать файл в соответствии с вашим местоположением для удобства идентификации.
  7. Скопируйте загруженный шаблон расположения в свой кластер Kubernetes.
  8. Скопируйте и выполните сгенерированные команды в вашем кластере Kubernetes. Ваш токен PaaS будет автоматически добавлен к отображаемым командам.
  9. Выполните команды из того же места, где находится файл шаблона.
    • Если вы переименовали файл шаблона, используйте новое имя файла в командах.

(Необязательно) Выполните следующую команду, чтобы вывести список всех подов в заданном пространстве имен (astromkey в приведенном ниже примере) и проверить их развертывание.

kubectl get pod -n astromkey

Вы также можете просмотреть поды на странице Статус развертывания > ActiveGates, отфильтровав их по парам ключ-значение Running in container: True и With modules: Synthetic.

3. Разверните адаптер синтетических метрик

Эта процедура генерирует отдельный шаблон для адаптера синтетических метрик. Затем вы выполняете сгенерированные команды в своем кластере Kubernetes для развертывания адаптера метрик.

  • Адаптер синтетических метрик необходимо развернуть всего один раз для каждого кластера Kubernetes.
  • Для установки адаптера синтетических метрик требуется роль суперпользователя Kubernetes для создания ролей ClusterRoles и ClusterRoleBindings.
  1. В разделе Развертывание создайте токен метрик (Создать токен) или вставьте существующий токен. Токен метрик — это токен доступа для получения данных об использовании из Ключ-АСТРОМ. Существующие токены перечислены на странице Токены доступа.
  2. Укажите имя пространства имен адаптера метрик или используйте имя по умолчанию. (Оставьте пространство имен Location и имя АктивногоШлюза без изменений. Эти поля необходимы только для генерации шаблона для местоположения.)
  3. Кнопка Загрузить synthetic-adapter.yaml становится активной после того, как вы укажете токен метрики и имя пространства имен адаптера метрик.
  4. Значения полей в разделе Развертывание не сохраняются. При переходе на другую страницу вам потребуется повторно ввести значения.
  5. Выберите Скачать synthetic-adapter.yaml. Это файл-шаблон для адаптера синтетических метрик.
  6. Скопируйте загруженный шаблон адаптера метрик в свой кластер Kubernetes.
  7. Скопируйте и выполните сгенерированные команды в вашем кластере Kubernetes. Ваш токен метрик будет автоматически добавлен к отображаемым командам.
  8. Выполните команды из того же места, где находится файл шаблона.
    • Если вы переименовали файл шаблона, используйте новое имя файла в командах.

Установите контейнеризированное местоположение с поддержкой FIPS

Установите для местоположения режим FIPS.

В настоящее время это возможно только с помощью REST API, путем указания соответствующего свойства fipsMode в JSON-запросе.

  • Для создания нового местоположения используйте POST-запрос для определения местоположения.
  • Для обновления существующего местоположения используйте вызов PUT location.

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

Поддержка браузеров

kubectl -n $NAMESPACE create secret tls synthetic-fips-proxy-cert --cert=squid.crt --key=squid.key

Поддержка браузеров с использованием корпоративного прокси

kubectl -n $NAMESPACE create secret generic synthetic-fips-proxy-peer --from-literal='peer.conf=cache_peer proxy.example.com parent 443 0 default no-digest proxy-only login=proxyuser:proxypass tls tls-min-version=1.2 tls-options=NO_SSLv3'

Также укажите конфигурацию корпоративного прокси для АктивногоШлюза (см. раздел «Конфигурация прокси»).

Без браузера

Дополнительная настройка не требуется.

Продолжите загрузку и развертывание шаблона YAML, как описано в разделе «Установка».

Обновите местоположение контейнера или его АктивныеШлюзы

Для внесения любых изменений в местоположение необходимо повторно загрузить файл шаблона местоположения и применить изменения с помощью команды kubectl.

Для обновления версий АктивногоШлюза:

  1. Скачайте файл шаблона местоположения.
    • Выберите свое местоположение в разделе Частные синтетические локации.
    • В разделе Развертывание повторно введите токен PaaS, имя АктивногоШлюза и имя пространства имен Location, которые вы указали при развертывании по местоположению. После этого кнопка Загрузить synthetic.yaml станет активной.
    • Выберите Загрузить synthetic.yml, чтобы загрузить новый файл шаблона местоположения.
    • Переименуйте файл в соответствии с вашим местоположением для удобства идентификации.
  2. Скопируйте файл шаблона в свой кластер Kubernetes.
  3. Выполните следующую команду, чтобы применить изменения в вашем кластере Kubernetes. Убедитесь, что вы используете имя файла шаблона, расположенного в вашем регионе, вместо synthetic.yaml. Выполните эту команду из того же места, где находится файл шаблона.
kubectl apply --server-side --force-conflicts -f ./synthetic.yaml
  • --server-side: Используется серверное применение (server-side apply), которое отслеживает права собственности на поля на сервере API Kubernetes. Это рекомендуемый подход для сложных определений ресурсов, таких как шаблон местоположения, и позволяет избежать ограничений по размеру, присущих клиентскому применению.
  • --force-conflicts: Этот флаг гарантирует применение обновления даже при наличии конфликтов владения полями — например, если поле ранее управлялось другим менеджером полей, таким как предыдущий kubectl apply запуск или контроллер Kubernetes. Без этого флага вам потребуется разрешить конфликты вручную, прежде чем обновление сможет продолжиться.

Если ваша конфигурация включает поля, права собственности на которые необходимо целенаправленно передать контроллеру — например, replicas HorizontalPodAutoscaler — см. раздел «Передача прав собственности» в документации Kubernetes, чтобы узнать, как безопасно скоординировать этот переход.

Любое обновление переразвертывает АктивныеШлюзы в обратном порядке по сравнению с их предыдущим развертыванием. Например, если в вашем местоположении находятся АктивныеШлюзы activegate-name-0 и activegate-name-1, activegate-name-1 сначала останавливается и переразвертывается.

Переразвернутый модуль АктивногоШлюза использует тот же постоянный том, который был развернут для обеспечения непрерывности ведения логов.

Удаление адаптера местоположения или метрик в Kubernetes

Команды, генерируемые при развертывании местоположения и адаптера синтетических метрик, также содержат фрагменты кода для их удаления в Kubernetes. Вы можете скопировать и сохранить эти команды для дальнейшего использования.

В любой момент вы можете повторно сгенерировать команды для соответствующих пространств имен.

  • Если вы переименовали файл шаблона, используйте новое имя файла в командах.
  • Приведенные ниже команды очистки не удаляют соответствующие пространства имен.

Расположение

  1. Выберите свое местоположение в разделе Частные синтетические локации.
  2. Повторно введите токен PaaS, имя АктивногоШлюза и имя пространства имен Location.
  3. Скопируйте и используйте команды очистки местоположения.

Обратите внимание, что эта процедура удаляет только ресурсы Kubernetes; она не удаляет местоположение, которое вы изначально указали в Ключ-АСТРОМ.

Синтетический метрический адаптер

  1. Выберите свое местоположение в разделе Частные синтетические локации.
  2. Повторно введите токен метрик и имя пространства имен адаптера метрик.
  3. Скопируйте и используйте команду очистки метрического адаптера.

Если адаптер синтетических метрик будет удален или перестанет работать, горизонтальные автомасштабировщики подов больше не смогут получать данные об использовании от Ключ-АСТРОМ, и ваши контейнеризированные местоположения станут немасштабируемыми.

Многозональный доступ к PVC в облачных кластерах

Использование кластера с несколькими зонами доступности (multi-AZ) и развертываниями, использующими PVC, может привести к тому, что поды будут зависать в состоянии ожидания после пересоздания. Это происходит потому, что тома хранения не реплицируются между зонами.

PVC используется совместно только узлами, расположенными в одной зоне доступности. При использовании кластера с несколькими зонами доступности, если узел пытается получить доступ к PVC из другой зоны доступности, он застрянет в состоянии ожидания и отобразит сообщение об ошибке.

В настоящее время существует два возможных решения для развертывания Kubernetes в нескольких зонах доступности:

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

Используйте параметр «Привязка узлов», чтобы ограничить размещение подов в определенной зоне

Вы можете настроить привязку узлов таким образом, чтобы для развертывания использовались только определенные зоны.

Для установки привязки узла:

  1. Используйте следующую команду, чтобы узнать, в какой зоне развернут каждый узел:
kubectl get nodes --show-labels
  1. Найдите метку failure-domain.beta.kubernetes.io/zone, например, failure-domain.beta.kubernetes.io/zone=us-east-1a.
  2. Используйте команду kubectl label, чтобы установить пользовательскую метку для узла:
kubectl label nodes node name label=value

Пример:

kubectl label nodes ip-10-179-202-73.ec2.internal zone=us-east-1a
  1. Добавьте пользовательскую метку узла в nodeSelector раздел шаблона синтетического развертывания. Например:
spec:
   nodeSelector:
     zone: us-east-1a
  1. Сохраните изменения.
  2. Примените шаблон.

Узлы с одинаковой меткой зоны будут развернуты в одной зоне доступности, и вы сможете совместно использовать PVC между ними без возникновения ошибок.

Используйте системы общего хранения данных

Каждый облачный сервис предоставляет свои собственные варианты систем общего хранения данных. Для примера использования общей файловой системы (EFS):

Предполагается, что у вас уже есть настроенная общая файловая система. Если нет, обратитесь к документации вашего облачного провайдера по настройке EFS.

Для использования класса хранения с EFS:

  1. Заполните шаблон синтетического развертывания аналогично приведенному ниже примеру:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-test
provisioner: efs.csi.aws.com
parameters:
  fileSystemId: fs-0c155dcd8425aa39d
  provisioningMode: efs-ap
  directoryPerms: "700"
  basePath: "/"
  1. Измените раздел volumeClaimTemplates шаблона аналогично приведенному ниже примеру:
volumeClaimTemplates:
  - metadata:
      name: persistent-storage
    spec:
      storageClassName: efs-test
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 3Gi
  1. Сохраните изменения.
  2. Примените шаблон.

Теперь, если под будет переразвёрнут на узле в другой зоне, PVC должен автоматически привязаться к новой зоне развертывания.

Мониторы NAM на контейнерных площадках

Мониторы доступности сети поддерживаются в контейнеризированных развертываниях АктивногоШлюза с поддержкой синтетических тестов, но для тестов ICMP требуются дополнительные разрешения.

Чтобы включить тип запроса ICMP для выполнения NAM:

  1. В Расширениях найдите раздел Настройки.
  2. В настройках найдите раздел Частные синтетические локации и выберите его.
  3. Выберите Добавить местоположение Kubernetes.
  4. Укажите ваше местоположение и обязательно включите параметр Включить тип запроса ICMP для выполнения мониторов доступности сети.

Мониторы ICMP используют исполняемый файл ping, для работы которого требуется набор прав CAP_NET_RAW, установленных для контейнера, выполняющего запросы (synthetic-vuc).

Для этого контейнера необходимо установить свойство allowPrivilegeEscalation в значение true, поскольку процесс, запускающий исполняемый файл ping, по умолчанию не обладает необходимыми привилегиями.

Полный код securityContext для контейнера synthetic-vuc с включенными мониторами доступности сети должен выглядеть следующим образом.

securityContext:
  readOnlyRootFilesystem: true
  privileged: false
  allowPrivilegeEscalation: true
  runAsNonRoot: true
  capabilities:
    drop: ["all"]
    add: ["NET_RAW"]

OpenShift

OpenShift использует Security Context Constraint (SCC) для ограничения возможностей, используемых подами. По умолчанию развернутые поды будут использовать restricted-v2 SCC, который не допускает никаких дополнительных возможностей. Рекомендуемое решение — подготовить собственный Security Context Constraint.

Создайте выделенный сервисный аккаунт (необязательно)

Если пользовательский SCC используется только при синтетическом развертывании, рекомендуется создать отдельную учетную запись службы.

oc -n $NAMESPACE create sa sa-dt-synthetic
oc -n $NAMESPACE adm policy add-role-to-user edit system:serviceaccount:$NAMESPACE:sa-dt-synthetic

Создайте пользовательское ограничение контекста безопасности

Файл scc-dt-synthetic.yaml:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: scc-dt-synthetic
allowPrivilegedContainer: false
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
runAsUser:
  type: MustRunAsRange
seccompProfiles:
- runtime/default
seLinuxContext:
  type: MustRunAs
fsGroup:
  type: MustRunAs
supplementalGroups:
  type: MustRunAs
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret
users: []
groups: []
priority: null
readOnlyRootFilesystem: true
requiredDropCapabilities:
- ALL
defaultAddCapabilities: null
allowedCapabilities:
- NET_RAW
allowPrivilegeEscalation: true

priority может быть установлено на любое число от 1 до 9. Если два или более SCC удовлетворяют требованиям, выбирается тот, который имеет более высокий приоритет.

oc create -f scc-dt-synthetic.yaml

Добавьте новый SCC в учетную запись службы

oc -n $NAMESPACE adm policy add-scc-to-user scc-dt-synthetic system:serviceaccount:$NAMESPACE:default

Если был создан сервисный аккаунт sa-dt-synthetic, замените им default:

oc -n $NAMESPACE adm policy add-scc-to-user scc-dt-synthetic system:serviceaccount:$NAMESPACE:sa-dt-synthetic

Azure RedHat OpenShift (ARO)

Если кластер OpenShift развернут как ресурс Azure Red Hat OpenShift (ARO), по умолчанию группа сетевой безопасности не разрешит трафик ICMP за пределы кластера. Группа сетевой безопасности ARO не подлежит изменению, но пользовательскую группу сетевой безопасности можно создать и импортировать во время создания кластера ARO. Запуск кластера с настройками по умолчанию позволит использовать мониторы ICMP NAM только для ресурсов внутри кластера OpenShift. Любые запросы, исходящие за пределы кластера, будут завершаться ошибкой.

Конфигурация прокси

Добавьте следующий код в начало файла шаблона местоположения, чтобы вставить ресурс ConfigMap, содержащий информацию о вашем прокси-сервере.

В приведенном ниже примере кода:

  • Прокси-сервер используется для подключения к кластеру Ключ-АСТРОМ и тестируемым ресурсам.
  • Пространство имен (namespace: astromkey) должно совпадать с пространством имен местоположения.
kind: ConfigMap
apiVersion: v1
data:
  custom.properties: |-
    [http.client]
    proxy-server = 10.102.43.210
    proxy-port = 3128
    proxy-user = proxyuser
    proxy-password = proxypass
metadata:
  name: ag-custom-configmap
  namespace: dynatrace
---

Добавьте следующий код в spec.template.spec.volumes:.

- name: ag-custom-volume

 configMap:
   name: ag-custom-configmap
   items:
   - key: custom.properties
     path: custom.properties

Добавьте следующий код в конфигурацию контейнера АктивногоШлюза в разделе volumeMounts:.

- name: ag-custom-volume

 mountPath: /var/lib/astromkey/gateway/config_template/custom.properties
 subPath: custom.properties

Совместимость с Оператором Ключ-АСТРОМ

Если вы развертываете Оператор Ключ-АСТРОМ в том же кластере Kubernetes, что и контейнеризированное синтетическое местоположение, сгенерированный шаблон StatefulSet должен включать аннотацию пода astromkey.com/split-mounts: "true". Эта аннотация предотвращает конфликты, возникающие, когда внедрение Оператора сталкивается с образом АктивногоШлюза, который уже содержит каталог /var/lib/astromkey.

Начиная с Ключ-АСТРОМ версии 1.335 в шаблоне местоположения, сгенерированном Ключ-АСТРОМ, содержится эта аннотация. Если вы управляете манифестом StatefulSet вручную или используете более раннюю версию, убедитесь, что аннотация присутствует в разделе spec.template.metadata.annotations.

Открытые частные синтетические локации без браузера

В целом, мы рекомендуем развертывание полностью синтетических частных местоположений для поддержки выполнения всех типов синтетических мониторов (HTTP, браузерный, NAM).

Если вам не требуется запускать браузерные мониторы, рассмотрите возможность развертывания вашего местоположения в режиме без браузера. В этом режиме местоположение (или принадлежащий ему АктивныйШлюз) развертывается без браузера, что снижает требования к оборудованию. Однако браузерные мониторы не могут работать в местоположении без браузера.

Рассмотрите возможность использования местоположений без браузера в качестве альтернативы синтетическим приватным местоположениям с поддержкой мониторинга браузера, если вы сосредоточены исключительно на:

  • Примерах использования сети и инфраструктуры (с помощью мониторов NAM)
  • Мониторинге API (с использованием HTTP-мониторов)

По сравнению со стандартным шаблоном внесены следующие изменения:

  • Значение browser устанавливается для переменной среды DT_SYNTHETIC_UNSUPPORTED_MONITORING_MODULES в контейнере synthetic-vuc в разделе env:
- name: DT_SYNTHETIC_UNSUPPORTED_MONITORING_MODULES
  value: "browser"
  • Контейнеры synthetic-vuc-worker не включены.
  • Том chromium-cache не указан и не установлен.

Конфигурация аутентификации Kerberos

Добавьте следующий код в начало файла шаблона местоположения, чтобы вставить ресурс ConfigMap, содержащий информацию о вашем сервере Kerberos.

В приведенном ниже примере кода:

  • Область EXAMPLE.COM используется в аутентификации Kerberos.
  • Домен example.com используется в аутентификации Kerberos.
  • Имя хоста центра распространения ключей: kerberos.example.com.
  • Пространство имен (namespace: astromkey) должно совпадать с пространством имен местоположения.
kind: ConfigMap
apiVersion: v1
data:
  krb5.conf: |-
    [libdefaults]
      dns_lookup_realm = false
      ticket_lifetime = 24h
      renew_lifetime = 7d
      forwardable = true
      rdns = false
      pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
      spake_preauth_groups = edwards25519
      dns_canonicalize_hostname = fallback
      qualify_shortname = ""
      default_realm = EXAMPLE.COM
      default_ccache_name = /tmp/krb5cc_%{uid}
    [realms]
      EXAMPLE.COM = {
        kdc = kerberos.example.com
        admin_server = kerberos.example.com
      }
    [domain_realm]
      .example.com = EXAMPLE.COM
      example.com = EXAMPLE.COM
metadata:
  name: krb-map
  namespace: dynatrace
---

Добавьте следующий код в spec.template.spec.volumes:.

- name: krb5-conf

 configMap:
   name: krb-map
   items:
   - key: krb5.conf
     path: krb5.conf

Добавьте следующий код в конфигурацию каждого контейнера synthetic-vuc-worker в разделе volumeMounts:.

- name: krb5-conf

 mountPath: /etc/krb5.conf
 subPath: krb5.conf

Синтетический метрический адаптер: дополнительные настройки

Отключить проверку доменного сертификата

Добавьте следующий код в шаблон адаптера синтетической метрики в разделе env:

- name: TLS_SECURE
  value: "false"

Это отключает проверку сертификатов для подключения адаптера синтетических метрик к кластеру Ключ-АСТРОМ (по умолчанию она включена).

Конфигурация прокси

Добавьте следующий код в шаблон адаптера синтетической метрики в разделе env:

- name: HTTPS_PROXY
  value: "http://proxyuser:proxypass@10.102.43.210:3128"
- name: NO_PROXY
  value: "172.20.0.0/16" # не перенаправлять внутренние вызовы в кластер Kubernetes

Более подробную информацию об этих переменных среды см. в документации пакета Go httpproxy.

Способ получения CIDR-адреса сервиса зависит от дистрибутива Kubernetes.

Перенос синтетического адаптера на API запросов Хранилища данных

Этот раздел актуален для клиентов, использующих метрики Хранилища данных, включая среды Ключ-АСТРОМ, созданные после января 2026 года.

Начиная с Ключ-АСТРОМ версии 1.338+ Адаптер Synthetic Adapter поддерживает API запросов Хранилища данных для синтетических метрик. Для миграции требуется перегенерировать токен dynametric адаптера Synthetic Adapter.

Новый токен dynametric должен быть платформенным токеном, созданным в разделе Управление учетной записью. Он должен обладать следующими областями действия: storage:buckets:read, storage:metrics:read.

Существует два способа обновления до нового API:

  • Обновите всю развернутую систему до более новой версии (АктивныйШлюз версии 1.337+).
  • Обновите API самостоятельно, не обновляя всю систему целиком.

Миграция при обновлении развертывания на АктивныйШлюз версии 1.337+

  1. Загрузите новый шаблон адаптера и все шаблоны синтетических местоположений, использующие этот адаптер.
  2. Удалите предыдущий секрет dynametric:
kubectl -n $adapterNamespace delete secret dynametric
  1. Создайте новый секрет dynametric:
kubectl -n $adapterNamespace create secret generic dynametric --from-literal=apiToken=xxx.yyy.zzz
  1. Примените новый шаблон адаптера:
kubectl apply --server-side --force-conflicts -f synthetic_metric_adapter.yaml
  1. Примените новый шаблон местоположения:
kubectl apply --server-side --force-conflicts -f $locationTemplateFile
  1. Убедитесь, что HPA в данном месте получает новые метрики. Они должны стать доступны примерно через пять минут после развертывания.
kubectl get hpa -n $locationNamespace

Если в поле TARGETS отображается какое-либо значение (кроме "Неизвестно"), значит, адаптер получает метрики.

Миграция без изменения развернутой версии АктивногоШлюза

  1. Удалите предыдущий секрет dynametric:
kubectl -n $adapterNamespace delete secret dynametric
  1. Создайте новый секрет dynametric:
kubectl -n $adapterNamespace create secret generic dynametric --from-literal=apiToken=xxx.yyy.zzz
  1. Измените параметры развертывания адаптера. Установите переменную среды METRIC_3RD_GEN_ENABLED в значение "true":
       env:
         - name: METRIC_3RD_GEN_ENABLED
           value: "true"
  1. Установите переменную среды BASE_URL в соответствии с URL-адресом последней версии Ключ-АСТРОМ:
       env:
         - name: BASE_URL
           value: "https://mySampleEnv.apps.astromkey.com"
  1. Измените параметры развертывания синтетических местоположений — измените целевую метрику в определении Horizontal Pod Autoscaler:
 metrics:
 - type: External
   external:
     metric:
       name: "dt.sfm.synthetic.engine_utilization:dt.entity.synthetic_location==SYNTHETIC_LOCATION-A1183B9FB2353097"
  1. После применения изменений проверьте, получает ли HPA в данном месте новые метрики. Они должны стать доступны примерно через пять минут после развертывания.
kubectl get hpa -n $locationNamespace

Если в поле TARGETS отображается любое значение, кроме пустого или Unknown, адаптер получает метрики.

Немасштабируемые контейнерные локации

Объекты, масштабируемые автоматически, перестают масштабироваться по любой из следующих причин:

  • Если в StatefulSet достигнуто максимальное количество подов, а коэффициент использования местоположения превысит пороговое значение в 80%, новые поды АктивногоШлюза не будут создаваться до тех пор, пока максимальное количество АктивныхШлюзов не будет увеличено.
  • Адаптер синтетических метрик перестаёт работать, и автомасштабировщики горизонтальных подов не получают метрики, необходимые для автоматического масштабирования.

Для проверки состояния автомасштабирования пода можно выполнить следующую команду. В приведенном ниже примере astromkey — это пространство имен location.

kubectl describe hpa -n dynatrace

Если в выходных данных ScalingActive установлено значение false, автомасштабировщик не получает данные метрик.

API: Синтетический — API для определения местоположений, узлов и конфигурации, версия 2

Вы можете автоматизировать развертывание и управление контейнеризированными местоположениями с помощью существующего API Synthetic - Locations, nodes, and configuration API v2. В этот API добавлены конечные точки раннего доступа для упрощения развертывания местоположений Kubernetes. Новые конечные точки помогают генерировать команды, необходимые для выполнения в кластере Kubernetes.

Новые конечные точки для развертывания Kubernetes в зависимости от местоположения:

  • Конечная точка GET location YAML (/synthetic/locations/{LocationId}/yaml) получает файл шаблона местоположения на основе идентификатора местоположения, которое вы изначально настроили для развертывания в контейнере.
  • Конечная точка GET apply commands (synthetic/locations/commands/apply) получает список команд для развертывания местоположения в Kubernetes/Openshift.
  • Конечная точка GET delete commands (synthetic/locations/{LocationId}/commands/delete) получает команды для удаления местоположения в контейнере.