Просмотр кода страницы Контейнеризированные, автоматически масштабируемые частные синтетические локации в Kubernetes


= Контейнеризированные, автоматически масштабируемые частные синтетические локации в Kubernetes =
Ключ-АСТРОМ версия 1.264+

Контейнеризированные, автоматически масштабируемые частные синтетические среды в '''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 с постоянным уровнем громкости и поддержкой <code>kubectl</code>.

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

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

* Запросы на использование ЦП и ОЗУ относятся к ресурсам, резервируемым подами при их создании.
* Ограничения по ЦП и ОЗУ указывают на максимальное потребление ресурсов на один под.
* Если локация контролируется ЕдинымАгентом или другим решением для глубокого мониторинга, требования к оперативной памяти ('''RAM''') возрастут.
* В режиме '''FIPS''' для бесбраузерного пода предъявляются те же требования, что и для обычного бесбраузерного пода.

{| class="wikitable"
!Компонент
!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''' — <code>v1beta1.external.metrics.k8s.io</code>.

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

'''Определение API-сервиса в шаблоне адаптера метрик'''<pre>
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
</pre>Адаптер синтетических метрик также изменяет существующий ресурс в своем шаблоне — объект <code>horizontal-pod-autoscaler</code> '''ServiceAccount''' в пространстве имен <code>kube-system</code>.

'''Изменение существующих ресурсов в шаблоне адаптера метрик'''<pre>
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
</pre>

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

= Установите контейнерную локацию =

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

# Перейдите в раздел '''Синтетический мониторинг''' > '''Частные локации''' > '''Новые частные локации''' > '''Kubernetes''' или '''OpenShift'''.
# Укажите название локации на ваш выбор.
# Выберите географическую локацию, например, '''San Francisco, California, United States'''. (Обратите внимание, что вы не сможете сохранить изменения, пока не укажете название и локацию.)
# В разделе '''АктивныеШлюзы''':
#* Укажите минимальное и максимальное количество АктивныхШлюзов для вашей локации. Эти параметры используются для автоматического масштабирования горизонтального пода.
#* Выберите размер нода АктивногоШлюза ('''XS''', '''S''', или '''M'''). См. также разделы «Требования» и «Рекомендации и предостережения».
#* При необходимости включите режим '''FIPS'''. Вы можете выбрать между режимом '''FIPS''' без привязки к серверу и режимом '''FIPS''' с корпоративным прокси. В качестве альтернативы вы можете включить режим '''FIPS''' через '''API'''.
# Только '''Kubernetes''': Если ваша реализация '''Kubernetes''' основана на более поздней версии, чем 1.21–1.25, включите параметр '''Использовать Kubernetes версии 1.26+'''.
#* Если вы измените этот параметр после загрузки шаблона локации, вам потребуется повторить процедуру развертывания.
# (Необязательно) Вы можете включить тип запроса '''ICMP''' для выполнения мониторов доступности сети.
# (Необязательно) Вы можете отключить поддержку браузерных мониторов. В этом случае нод АктивногоШлюза будет рассматриваться как не использующий браузер.
# (Необязательно) Включите оповещение о состоянии в частной локации. Это позволит сгенерировать сообщение о проблеме и отправить оповещение, когда все АктивныеШлюзы в частной локации отключатся.
# Выберите '''Далее'''.

== 2. Разверните локацию ==

# Укажите имя АктивногоШлюза или используйте имя по умолчанию. Это имя используется в качестве префикса для АктивныхШлюзов, развернутых в рамках указанной локации. Первый АктивныйШлюз называется <code>&#x3C;prefix&#x3E;-0</code>, второй — <code>&#x3C;prefix&#x3E;-1</code>, и так далее. Это имя также используется в качестве имени '''StatefulSet'''.
# Укажите имя пространства имен '''Location''' или используйте имя по умолчанию.
# Выберите '''Скачать synthetic.yaml'''. Это файл шаблона для указания локации. Вы можете переименовать файл в соответствии с вашей локацией для удобства идентификации.
# Скопируйте загруженный шаблон локации в свой кластер '''Kubernetes'''.
# Сгенерируйте команды развертывания.
# Выполните следующие команды в терминале:
#* Команда для создания пространства имен и секретов для реестра '''Docker''' и АктивногоШлюза.
#* Команда для развертывания АктивногоШлюза.
# Выберите '''Готово''' или продолжите развертывание адаптера метрик.

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

* Адаптер синтетических метрик необходимо развернуть всего один раз для каждого кластера '''Kubernetes'''.
* Для установки адаптера синтетических метрик требуется роль суперпользователя '''Kubernetes''' для создания ролей '''ClusterRoles''' и '''ClusterRoleBindings'''.

# Разверните адаптер развертывания метрик.
# Укажите имя пространства имен адаптера метрик или используйте имя по умолчанию.
# Выберите '''Скачать synthetic-adapter.yaml'''. Это файл-шаблон для адаптера синтетических метрик.
# Скопируйте загруженный шаблон адаптера метрик в свой кластер '''Kubernetes'''.
# Сгенерируйте команды развертывания.
# Выполните следующие команды в терминале:
#* Команда для создания пространства имен и секретов для реестра '''Docker''' и АктивногоШлюза.
#* Команда для развертывания АктивногоШлюза.
# Выберите '''Завершить'''.

= Установка контейнеризированной локации, поддерживающей стандарт FIPS, через API =
Установите режим '''FIPS''' для данной локации.

Установите свойство <code>fipsMode</code> в '''JSON'''-запросе, используя '''REST API'''.

* Для создания новой локации используйте '''POST'''-запрос.
* Для обновления существующей локации используйте вызов '''PUT''' location.

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

=== Поддерживается браузерами ===
Предоставьте сертификат для повторной подписи '''HTTPS'''-запросов:<pre>
kubectl -n $NAMESPACE create secret tls synthetic-fips-proxy-cert --cert=squid.crt --key=squid.key
</pre>

=== Поддержка браузеров с использованием корпоративного прокси ===
Предоставьте сертификат для повторной подписи '''HTTPS'''-запросов:<pre>
kubectl -n $NAMESPACE create secret tls synthetic-fips-proxy-cert --cert=squid.crt --key=squid.key
</pre>Предоставьте '''Squid''' конфигурацию корпоративного прокси:<pre>
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'
</pre>Укажите конфигурацию корпоративного прокси-сервера для АктивногоШлюза. Подробности см. в разделе «Конфигурация прокси-сервера».

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

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

= Обновление локации контейнера или его АктивныхШлюзов =
Для внесения любых изменений в локацию необходимо повторно загрузить файл шаблона локации и применить изменения с помощью команды <code>kubectl</code>.

# Перейдите в раздел '''Синтетический мониторинг''' > '''Частные локации'''.
# Выберите свою локацию в разделе '''Частные синтетические локации'''.
# Перейдите на вкладку развертывания в частной локации.
# Повторно введите имя АктивногоШлюза и пространство имен '''Location''', которые вы указали при развертывании локации.
# Выберите '''Загрузить synthetic.yml''', чтобы загрузить новый файл шаблона локации.
# Переименуйте файл в соответствии с вашей локацией для удобства идентификации.
# Скопируйте файл шаблона в свой кластер '''Kubernetes'''.
# Выполните следующую команду, чтобы применить изменения в вашем кластере '''Kubernetes'''. Убедитесь, что вы используете имя файла шаблона, расположенного в вашем регионе, вместо synthetic.yaml. Выполните эту команду из того же места, где находится файл шаблона.
<pre>
kubectl apply --server-side --force-conflicts -f ./synthetic.yaml
</pre>

* <code>--server-side</code>: Используется серверное применение (server-side apply), которое отслеживает права собственности на поля на сервере '''API''' '''Kubernetes'''. Это рекомендуемый подход для сложных определений ресурсов, таких как шаблон локации, и позволяет избежать ограничений по размеру, присущих клиентскому применению.
* <code>--force-conflicts</code>: Этот флаг гарантирует применение обновления даже при наличии конфликтов владения полями — например, если поле ранее управлялось другим менеджером полей, таким как предыдущий <code>kubectl apply</code> запуск или контроллер '''Kubernetes'''. Без этого флага вам потребуется разрешить конфликты вручную, прежде чем обновление сможет продолжиться.

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

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

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

= Удаление адаптера локации или метрик в Kubernetes =
Фрагменты кода для удаления адаптера локации и метрики можно найти на соответствующих вкладках ('''Развертывание частной локации''' или '''Развертывание адаптера метрики''') в сведениях о локации. Вы можете скопировать и сохранить эти команды для дальнейшего использования.

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

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

== Удалить локацию ==

# Перейдите в раздел '''Синтетический мониторинг''' > '''Частные локации'''.
# Выберите свою локацию в разделе '''Частные синтетические локации'''.
# Перейдите на вкладку развертывания в частной локации.
# Разверните команду '''Удалить''' (необязательно), затем скопируйте и выполните предоставленную команду удаления.

Данная процедура удаляет только частную локацию '''Synthetic''', но не удаляет ее пространство имен.

== Удалить адаптер синтетической метрики ==

# Перейдите в раздел '''Синтетический мониторинг''' > '''Частные локации'''.
# Выберите свою локацию в разделе '''Частные синтетические локации'''.
# Перейдите на вкладку развертывания адаптера метрик.
# Разверните команду '''Удалить''' (необязательно), затем скопируйте и выполните предоставленную команду удаления.

Данная процедура удаляет только метрический адаптер, но не удаляет его пространство имен.

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

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

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

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

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

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

# Используйте следующую команду, чтобы узнать, в какой зоне развернут каждый нод:
<pre>
kubectl get nodes --show-labels
</pre>

# Найдите метку <code>failure-domain.beta.kubernetes.io/zone</code>, например, <code>failure-domain.beta.kubernetes.io/zone=us-east-1a</code>.
# Используйте команду <code>kubectl label</code>, чтобы установить пользовательскую метку для нода:
<pre>
kubectl label nodes node name label=value
</pre>Пример:<pre>
kubectl label nodes ip-10-179-202-73.ec2.internal zone=us-east-1a
</pre>

# Добавьте пользовательскую метку нода в <code>nodeSelector</code> раздел шаблона синтетического развертывания. Например:
<pre>
spec:
   nodeSelector:
     zone: us-east-1a
</pre>

# Сохраните изменения.
# Примените шаблон.

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

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

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

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

# Заполните шаблон синтетического развертывания аналогично приведенному ниже примеру:
<pre>
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: "/"
</pre>

# Измените раздел <code>volumeClaimTemplates</code> шаблона аналогично приведенному ниже примеру:
<pre>
volumeClaimTemplates:
  - metadata:
      name: persistent-storage
    spec:
      storageClassName: efs-test
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 3Gi
</pre>

# Сохраните изменения.
# Примените шаблон.

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

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

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

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

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

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

Полный код <code>securityContext</code> для контейнера <code>synthetic-vuc</code> с включенными мониторами доступности сети должен выглядеть следующим образом.<pre>
securityContext:
  readOnlyRootFilesystem: true
  privileged: false
  allowPrivilegeEscalation: true
  runAsNonRoot: true
  capabilities:
    drop: ["all"]
    add: ["NET_RAW"]
</pre>

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

== Создайте выделенный сервисный аккаунт (необязательно) ==
Если пользовательский '''SCC''' используется только при синтетическом развертывании, рекомендуется создать отдельную учетную запись службы.<pre>
oc -n $NAMESPACE create sa sa-astromkey-synthetic
oc -n $NAMESPACE adm policy add-role-to-user edit system:serviceaccount:$NAMESPACE:sa-astromkey-synthetic
</pre>

== Создайте пользовательское ограничение контекста безопасности ==
Файл <code>scc-astromkey-synthetic.yaml</code>:<pre>
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: scc-astromkey-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
</pre><code>priority</code> может быть установлено на любое число от 1 до 9. Если два или более '''SCC''' удовлетворяют требованиям, выбирается тот, который имеет более высокий приоритет.<pre>
oc create -f scc-astromkey-synthetic.yaml
</pre>

== Добавьте новый SCC в учетную запись службы ==
<pre>
oc -n $NAMESPACE adm policy add-scc-to-user scc-astromkey-synthetic system:serviceaccount:$NAMESPACE:default
</pre>Если был создан сервисный аккаунт <code>sa-astromkey-synthetic</code>, замените им <code>default</code>:<pre>
oc -n $NAMESPACE adm policy add-scc-to-user scc-astromkey-synthetic system:serviceaccount:$NAMESPACE:sa-astromkey-synthetic
</pre>

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

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

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

* Прокси-сервер используется для подключения к кластеру Ключ-АСТРОМ и тестируемым ресурсам.
* Пространство имен (<code>namespace: astromkey</code>) должно совпадать с пространством имен локации.
<pre>
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
---
</pre>Добавьте следующий код в <code>spec.template.spec.volumes:</code>.<pre>
- name: ag-custom-volume
  configMap:
    name: ag-custom-configmap
    items:
    - key: custom.properties
      path: custom.properties
</pre>Добавьте следующий код в конфигурацию контейнера АктивногоШлюза в разделе <code>volumeMounts:</code>.<pre>
- name: ag-custom-volume
  mountPath: /var/lib/astromkey/gateway/config_template/custom.properties
  subPath: custom.properties
</pre>

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

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

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

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

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

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

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

* Значение <code>browser</code> устанавливается для переменной среды <code>DT_SYNTHETIC_UNSUPPORTED_MONITORING_MODULES</code> в контейнере <code>synthetic-vuc</code> в разделе <code>env</code>:
<pre>
- name: DT_SYNTHETIC_UNSUPPORTED_MONITORING_MODULES
  value: "browser"
</pre>

* Контейнеры <code>synthetic-vuc-worker</code> не включены.
* Том <code>chromium-cache</code> не указан и не установлен.

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

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

* Область <code>EXAMPLE.COM</code> используется в аутентификации '''Kerberos'''.
* Домен <code>example.com</code> используется в аутентификации '''Kerberos'''.
* Имя хоста центра распространения ключей: <code>kerberos.example.com</code>.
* Пространство имен (<code>namespace: astromkey</code>) должно совпадать с пространством имен локации.
<pre>
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
---
</pre>Добавьте следующий код в <code>spec.template.spec.volumes:</code>.<pre>
- name: krb5-conf
  configMap:
    name: krb-map
    items:
    - key: krb5.conf
      path: krb5.conf
</pre>Добавьте следующий код в конфигурацию каждого контейнера <code>synthetic-vuc-worker</code> в разделе <code>volumeMounts:</code>.<pre>
- name: krb5-conf
  mountPath: /etc/krb5.conf
  subPath: krb5.conf
</pre>

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

== Отключить проверку доменного сертификата ==
Добавьте следующий код в шаблон адаптера синтетической метрики в разделе <code>env</code>:<pre>
- name: TLS_SECURE
  value: "false"
</pre>Это отключает проверку сертификатов для подключения адаптера синтетических метрик к кластеру Ключ-АСТРОМ (по умолчанию она включена).

== Конфигурация прокси ==
Добавьте следующий код в шаблон адаптера синтетической метрики в разделе <code>env</code>:<pre>
- name: HTTPS_PROXY
  value: "http://proxyuser:proxypass@10.102.43.210:3128"
- name: NO_PROXY
  value: "172.20.0.0/16" # не перенаправлять внутренние вызовы в кластер Kubernetes
</pre>Более подробную информацию об этих переменных среды см. в документации пакета '''Go httpproxy'''.

Способ получения '''CIDR'''-адреса сервиса зависит от дистрибутива '''Kubernetes'''; например, для облачного '''Kubernetes''' можно использовать следующую команду:<pre>
aws eks describe-cluster --name my-cluster --query 'cluster.kubernetesNetworkConfig'
</pre>

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

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

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

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

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

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

# Загрузите новый шаблон адаптера и все шаблоны синтетических локаций, использующие этот адаптер.
# Удалите предыдущий секрет <code>dynametric</code>:
<pre>
kubectl -n $adapterNamespace delete secret dynametric
</pre>

# Создайте новый секрет <code>dynametric</code>:
<pre>
kubectl -n $adapterNamespace create secret generic dynametric --from-literal=apiToken=xxx.yyy.zzz
</pre>

# Примените новый шаблон адаптера:
<pre>
kubectl apply --server-side --force-conflicts -f synthetic_metric_adapter.yaml
</pre>

# Примените новый шаблон локации:
<pre>
kubectl apply --server-side --force-conflicts -f $locationTemplateFile
</pre>

# Убедитесь, что '''HPA''' в данной локации получает новые метрики. Они должны стать доступны примерно через пять минут после развертывания.
<pre>
kubectl get hpa -n $locationNamespace
</pre>Если в поле <code>TARGETS</code> отображается какое-либо значение (кроме «Неизвестно»), значит, адаптер получает метрики.

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

# Удалите предыдущий секрет <code>dynametric</code>:
<pre>
kubectl -n $adapterNamespace delete secret dynametric
</pre>

# Создайте новый секрет <code>dynametric</code>:
<pre>
kubectl -n $adapterNamespace create secret generic dynametric --from-literal=apiToken=xxx.yyy.zzz
</pre>

# Измените параметры развертывания адаптера. Установите переменную среды <code>METRIC_3RD_GEN_ENABLED</code> в значение <code>"true"</code>:
<pre>
env:
  - name: METRIC_3RD_GEN_ENABLED
    value: "true"
</pre>

# Установите переменную среды <code>BASE_URL</code> в соответствии с URL-адресом последней версии Ключ-АСТРОМ:
<pre>
env:
  - name: BASE_URL
    value: "https://mySampleEnv.apps.astromkey.com"
</pre>

# Измените параметры развертывания синтетических локаций — измените целевую метрику в определении '''Horizontal Pod Autoscaler''':
<pre>
metrics:
- type: External
  external:
    metric:
      name: "dt.sfm.synthetic.engine_utilization:dt.entity.synthetic_location==SYNTHETIC_LOCATION-A1183B9FB2353097"
</pre>

# После применения изменений проверьте, получает ли '''HPA''' в данной локации новые метрики. Они должны стать доступны примерно через пять минут после развертывания.
<pre>
kubectl get hpa -n $locationNamespace
</pre>Если в поле <code>TARGETS</code> отображается любое значение, кроме пустого или <code>Unknown</code>, адаптер получает метрики.

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

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

Для проверки состояния автомасштабирования пода можно выполнить следующую команду. В приведенном ниже примере <code>astromkey</code> — это пространство имен локации.<pre>
kubectl describe hpa -n astromkey
</pre>Если в выходных данных <code>ScalingActive</code> установлено значение <code>false</code>, автомасштабировщик не получает данные метрик.

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

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

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