Контейнеризированные, автоматически масштабируемые частные синтетические локации в 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 с постоянным уровнем громкости и поддержкой 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 ГиБ	–	–	–

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

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. Разверните локацию

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

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

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

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

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

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

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

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

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

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

Поддерживается браузерами

Предоставьте сертификат для повторной подписи HTTPS-запросов:

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

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

Предоставьте сертификат для повторной подписи HTTPS-запросов:

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

Предоставьте Squid конфигурацию корпоративного прокси:

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.

Перейдите в раздел Синтетический мониторинг > Частные локации.
Выберите свою локацию в разделе Частные синтетические локации.
Перейдите на вкладку развертывания в частной локации.
Повторно введите имя АктивногоШлюза и пространство имен Location, которые вы указали при развертывании локации.
Выберите Загрузить 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

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

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

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

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

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

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

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

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

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

Многозональный доступ к 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-astromkey-synthetic
oc -n $NAMESPACE adm policy add-role-to-user edit system:serviceaccount:$NAMESPACE:sa-astromkey-synthetic

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

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

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

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

oc create -f scc-astromkey-synthetic.yaml

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

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

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

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

Red Hat OpenShift (ARO)

Если кластер OpenShift развернут как ресурс 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; например, для облачного Kubernetes можно использовать следующую команду:

aws eks describe-cluster --name my-cluster --query 'cluster.kubernetesNetworkConfig'

Перенос синтетического адаптера на 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 — это пространство имен локации.

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) получает команды для удаления локации в контейнере.

Аноним

Поиск

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

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

Архитектура

Требования

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

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

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

Локации

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

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

Ограничения

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

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

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

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

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

Поддерживается браузерами

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

Без браузера

Обновление локации контейнера или его АктивныхШлюзов

Удаление адаптера локации или метрик в Kubernetes

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

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

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

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

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

Мониторы NAM на контейнерных локациях

OpenShift

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

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

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

Red Hat OpenShift (ARO)

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

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

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

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

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

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

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

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

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

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

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

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

Навигация

Вики-инструменты

Инструменты для страниц