Контейнеризированные, автоматически масштабируемые частные синтетические местоположения в Kubernetes
Контейнеризированные, автоматически масштабируемые частные синтетические местоположения в 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 и его расширение за счет указания новой службы API — v1beta1.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
- На странице Частные синтетические расположения выберите Добавить расположение Kubernetes или Добавить расположение OpenShift.
- Укажите название местоположения на ваш выбор.
- Выберите географическое местоположение, например, San Francisco, California, United States. (Обратите внимание, что вы не сможете сохранить изменения, пока не укажете название и местоположение.)
- В разделе ActiveGates:
- Укажите минимальное и максимальное количество АктивныхШлюзов для вашего местоположения. Эти параметры используются для автоматического масштабирования горизонтального пода.
- Выберите размер узла АктивногоШлюза (XS, S, или M). См. также разделы «Требования» и «Рекомендации и предостережения».
- Платформа развертывания выбирается автоматически в зависимости от вашего выбора между Kubernetes и OpenShift.
- Только Kubernetes: Если ваша реализация Kubernetes основана на более поздней версии, чем 1.21–1.25, включите параметр Использовать Kubernetes версии 1.26+. См. также разделы «Требования» и «Рекомендации и предостережения».
- Если вы измените этот параметр после загрузки шаблона расположения, вам потребуется повторить процедуру развертывания.
- (Необязательно) Вы можете отключить поддержку браузерных мониторов. В этом случае узел АктивногоШлюза будет рассматриваться как не использующий браузер.
- (Необязательно) Включить генерацию ошибок, если все АктивныеШлюзы отключаются.
- Сохраните изменения, прежде чем приступать к развертыванию адаптера местоположения и метрик.
Ваше именованное местоположение отображается на странице частных синтетических местоположений с логотипом Kubernetes или OpenShift. Обратите внимание, что на данный момент к местоположению не назначены АктивныеШлюзы.
2. Разверните местоположение
Выберите свое местоположение в разделе Частные синтетические местоположения, чтобы загрузить шаблон местоположения и сгенерировать команды, которые необходимо выполнить в кластере Kubernetes.
- В разделе Развертывание создайте токен PaaS (Создать токен) или вставьте существующий токен. Токен PaaS необходим для генерации токенов подключения АктивногоШлюза для связи с вашей средой Ключ-АСТРОМ.
- Существующие токены перечислены на странице Токены доступа. Обратите внимание, что токен PaaS отображается только один раз при создании, после чего он хранится в зашифрованном виде и не может быть раскрыт. Мы рекомендуем хранить ваш токен PaaS в менеджере паролей, чтобы вы могли повторно использовать его для создания дополнительных приватных местоположений в вашем кластере Kubernetes.
- Укажите имя АктивногоШлюза или используйте имя по умолчанию. Это имя используется в качестве префикса для АктивныхШлюзов, развернутых в рамках указанного местоположения. Первый АктивныйШлюз называется
<prefix>-0, второй —<prefix>-1, и так далее. Это имя также используется в качестве имени StatefulSet. - Укажите имя пространства имен Location или используйте имя по умолчанию. (Оставьте пространство имен адаптера Metric без изменений. Это поле необходимо только для генерации шаблона для адаптера синтетических метрик.)
- Кнопка Загрузить synthetic.yaml становится доступной после того, как вы укажете токен PaaS, имя АктивногоШлюза и имя пространства имен местоположения.
- Значения полей в разделе Развертывание не сохраняются. При переходе на другую страницу вам потребуется повторно ввести значения.
- Выберите Скачать synthetic.yaml. Это файл шаблона для указания местоположения. Вы можете переименовать файл в соответствии с вашим местоположением для удобства идентификации.
- Скопируйте загруженный шаблон расположения в свой кластер Kubernetes.
- Скопируйте и выполните сгенерированные команды в вашем кластере Kubernetes. Ваш токен PaaS будет автоматически добавлен к отображаемым командам.
- Выполните команды из того же места, где находится файл шаблона.
- Если вы переименовали файл шаблона, используйте новое имя файла в командах.
(Необязательно) Выполните следующую команду, чтобы вывести список всех подов в заданном пространстве имен (astromkey в приведенном ниже примере) и проверить их развертывание.
kubectl get pod -n astromkey
Вы также можете просмотреть поды на странице Статус развертывания > ActiveGates, отфильтровав их по парам ключ-значение Running in container: True и With modules: Synthetic.
3. Разверните адаптер синтетических метрик
Эта процедура генерирует отдельный шаблон для адаптера синтетических метрик. Затем вы выполняете сгенерированные команды в своем кластере Kubernetes для развертывания адаптера метрик.
- Адаптер синтетических метрик необходимо развернуть всего один раз для каждого кластера Kubernetes.
- Для установки адаптера синтетических метрик требуется роль суперпользователя Kubernetes для создания ролей ClusterRoles и ClusterRoleBindings.
- В разделе Развертывание создайте токен метрик (Создать токен) или вставьте существующий токен. Токен метрик — это токен доступа для получения данных об использовании из Ключ-АСТРОМ. Существующие токены перечислены на странице Токены доступа.
- Укажите имя пространства имен адаптера метрик или используйте имя по умолчанию. (Оставьте пространство имен Location и имя АктивногоШлюза без изменений. Эти поля необходимы только для генерации шаблона для местоположения.)
- Кнопка Загрузить synthetic-adapter.yaml становится активной после того, как вы укажете токен метрики и имя пространства имен адаптера метрик.
- Значения полей в разделе Развертывание не сохраняются. При переходе на другую страницу вам потребуется повторно ввести значения.
- Выберите Скачать synthetic-adapter.yaml. Это файл-шаблон для адаптера синтетических метрик.
- Скопируйте загруженный шаблон адаптера метрик в свой кластер Kubernetes.
- Скопируйте и выполните сгенерированные команды в вашем кластере Kubernetes. Ваш токен метрик будет автоматически добавлен к отображаемым командам.
- Выполните команды из того же места, где находится файл шаблона.
- Если вы переименовали файл шаблона, используйте новое имя файла в командах.
Установите контейнеризированное местоположение с поддержкой 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.
Для обновления версий АктивногоШлюза:
- Скачайте файл шаблона местоположения.
- Выберите свое местоположение в разделе Частные синтетические локации.
- В разделе Развертывание повторно введите токен PaaS, имя АктивногоШлюза и имя пространства имен Location, которые вы указали при развертывании по местоположению. После этого кнопка Загрузить synthetic.yaml станет активной.
- Выберите Загрузить synthetic.yml, чтобы загрузить новый файл шаблона местоположения.
- Переименуйте файл в соответствии с вашим местоположением для удобства идентификации.
- Скопируйте файл шаблона в свой кластер Kubernetes.
- Выполните следующую команду, чтобы применить изменения в вашем кластере 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. Вы можете скопировать и сохранить эти команды для дальнейшего использования.
В любой момент вы можете повторно сгенерировать команды для соответствующих пространств имен.
- Если вы переименовали файл шаблона, используйте новое имя файла в командах.
- Приведенные ниже команды очистки не удаляют соответствующие пространства имен.
Расположение
- Выберите свое местоположение в разделе Частные синтетические локации.
- Повторно введите токен PaaS, имя АктивногоШлюза и имя пространства имен Location.
- Скопируйте и используйте команды очистки местоположения.
Обратите внимание, что эта процедура удаляет только ресурсы Kubernetes; она не удаляет местоположение, которое вы изначально указали в Ключ-АСТРОМ.
Синтетический метрический адаптер
- Выберите свое местоположение в разделе Частные синтетические локации.
- Повторно введите токен метрик и имя пространства имен адаптера метрик.
- Скопируйте и используйте команду очистки метрического адаптера.
Если адаптер синтетических метрик будет удален или перестанет работать, горизонтальные автомасштабировщики подов больше не смогут получать данные об использовании от Ключ-АСТРОМ, и ваши контейнеризированные местоположения станут немасштабируемыми.
Многозональный доступ к PVC в облачных кластерах
Использование кластера с несколькими зонами доступности (multi-AZ) и развертываниями, использующими PVC, может привести к тому, что поды будут зависать в состоянии ожидания после пересоздания. Это происходит потому, что тома хранения не реплицируются между зонами.
PVC используется совместно только узлами, расположенными в одной зоне доступности. При использовании кластера с несколькими зонами доступности, если узел пытается получить доступ к PVC из другой зоны доступности, он застрянет в состоянии ожидания и отобразит сообщение об ошибке.
В настоящее время существует два возможных решения для развертывания Kubernetes в нескольких зонах доступности:
- Используйте параметр «Привязка узлов», чтобы ограничить размещение подов в определенной зоне.
- Используйте системы общего хранения данных.
Используйте параметр «Привязка узлов», чтобы ограничить размещение подов в определенной зоне
Вы можете настроить привязку узлов таким образом, чтобы для развертывания использовались только определенные зоны.
Для установки привязки узла:
- Используйте следующую команду, чтобы узнать, в какой зоне развернут каждый узел:
kubectl get nodes --show-labels
- Найдите метку
failure-domain.beta.kubernetes.io/zone, например,failure-domain.beta.kubernetes.io/zone=us-east-1a. - Используйте команду
kubectl label, чтобы установить пользовательскую метку для узла:
kubectl label nodes node name label=value
Пример:
kubectl label nodes ip-10-179-202-73.ec2.internal zone=us-east-1a
- Добавьте пользовательскую метку узла в
nodeSelectorраздел шаблона синтетического развертывания. Например:
spec:
nodeSelector:
zone: us-east-1a
- Сохраните изменения.
- Примените шаблон.
Узлы с одинаковой меткой зоны будут развернуты в одной зоне доступности, и вы сможете совместно использовать PVC между ними без возникновения ошибок.
Используйте системы общего хранения данных
Каждый облачный сервис предоставляет свои собственные варианты систем общего хранения данных. Для примера использования общей файловой системы (EFS):
Предполагается, что у вас уже есть настроенная общая файловая система. Если нет, обратитесь к документации вашего облачного провайдера по настройке EFS.
Для использования класса хранения с EFS:
- Заполните шаблон синтетического развертывания аналогично приведенному ниже примеру:
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: "/"
- Измените раздел
volumeClaimTemplatesшаблона аналогично приведенному ниже примеру:
volumeClaimTemplates:
- metadata:
name: persistent-storage
spec:
storageClassName: efs-test
accessModes:
- ReadWriteMany
resources:
requests:
storage: 3Gi
- Сохраните изменения.
- Примените шаблон.
Теперь, если под будет переразвёрнут на узле в другой зоне, PVC должен автоматически привязаться к новой зоне развертывания.
Мониторы NAM на контейнерных площадках
Мониторы доступности сети поддерживаются в контейнеризированных развертываниях АктивногоШлюза с поддержкой синтетических тестов, но для тестов ICMP требуются дополнительные разрешения.
Чтобы включить тип запроса ICMP для выполнения NAM:
- В Расширениях найдите раздел Настройки.
- В настройках найдите раздел Частные синтетические локации и выберите его.
- Выберите Добавить местоположение Kubernetes.
- Укажите ваше местоположение и обязательно включите параметр Включить тип запроса 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: astromkey
---
Добавьте следующий код в 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: astromkey
---
Добавьте следующий код в 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+
- Загрузите новый шаблон адаптера и все шаблоны синтетических местоположений, использующие этот адаптер.
- Удалите предыдущий секрет
dynametric:
kubectl -n $adapterNamespace delete secret dynametric
- Создайте новый секрет
dynametric:
kubectl -n $adapterNamespace create secret generic dynametric --from-literal=apiToken=xxx.yyy.zzz
- Примените новый шаблон адаптера:
kubectl apply --server-side --force-conflicts -f synthetic_metric_adapter.yaml
- Примените новый шаблон местоположения:
kubectl apply --server-side --force-conflicts -f $locationTemplateFile
- Убедитесь, что HPA в данном месте получает новые метрики. Они должны стать доступны примерно через пять минут после развертывания.
kubectl get hpa -n $locationNamespace
Если в поле TARGETS отображается какое-либо значение (кроме "Неизвестно"), значит, адаптер получает метрики.
Миграция без изменения развернутой версии АктивногоШлюза
- Удалите предыдущий секрет
dynametric:
kubectl -n $adapterNamespace delete secret dynametric
- Создайте новый секрет
dynametric:
kubectl -n $adapterNamespace create secret generic dynametric --from-literal=apiToken=xxx.yyy.zzz
- Измените параметры развертывания адаптера. Установите переменную среды
METRIC_3RD_GEN_ENABLEDв значение"true":
env:
- name: METRIC_3RD_GEN_ENABLED
value: "true"
- Установите переменную среды
BASE_URLв соответствии с URL-адресом последней версии Ключ-АСТРОМ:
env:
- name: BASE_URL
value: "https://mySampleEnv.apps.astromkey.com"
- Измените параметры развертывания синтетических местоположений — измените целевую метрику в определении Horizontal Pod Autoscaler:
metrics:
- type: External
external:
metric:
name: "dt.sfm.synthetic.engine_utilization:dt.entity.synthetic_location==SYNTHETIC_LOCATION-A1183B9FB2353097"
- После применения изменений проверьте, получает ли HPA в данном месте новые метрики. Они должны стать доступны примерно через пять минут после развертывания.
kubectl get hpa -n $locationNamespace
Если в поле TARGETS отображается любое значение, кроме пустого или Unknown, адаптер получает метрики.
Немасштабируемые контейнерные локации
Объекты, масштабируемые автоматически, перестают масштабироваться по любой из следующих причин:
- Если в StatefulSet достигнуто максимальное количество подов, а коэффициент использования местоположения превысит пороговое значение в 80%, новые поды АктивногоШлюза не будут создаваться до тех пор, пока максимальное количество АктивныхШлюзов не будет увеличено.
- Адаптер синтетических метрик перестаёт работать, и автомасштабировщики горизонтальных подов не получают метрики, необходимые для автоматического масштабирования.
Для проверки состояния автомасштабирования пода можно выполнить следующую команду. В приведенном ниже примере astromkey — это пространство имен location.
kubectl describe hpa -n astromkey
Если в выходных данных 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) получает команды для удаления местоположения в контейнере.