- ClickHouse 24.8 — каноническое хранилище аналитики событий и оценок (StatefulSet с постоянным томом 100Gi). Обязателен: сервер отказывается запускаться без него.
- PostgreSQL 16 — хранилище реляционных данных/метаданных для организаций, ключей API, пользователей, панелей, сохраненных запросов и аутентификации (StatefulSet с постоянным томом 50Gi)
- Redis 7.2 — опциональный общий кэш и бэкэнд ограничения скорости; сервер и панель корректно деградируют при его недоступности
- AgentEye Server — Rust API для приема событий, аналитики и управления ключами (2 реплики)
- AgentEye Dashboard — Next.js веб-интерфейс (2 реплики)
- AI помощник (сервис агента) — опциональный помощник только для чтения в панели на порту 9100; неактивен до настройки конечной точки LLM
- Traefik (public) — контроллер входящего трафика для трафика сборщика, защищенный mTLS
- Traefik (dashboard) — контроллер входящего трафика для панели, только для VPN/IP-разрешенного списка
- cert-manager — TLS сертификаты и CA для mTLS
- Резервная копия CronJob — ежедневный комбинированный дамп PostgreSQL + ClickHouse в 03:00 UTC
- Монитор обновления сертификатов — предупреждения при приближении истечения сертификатов клиента
Предварительные условия
Запустите каждую команду проверки перед началом. Каждая проверка должна пройти.| Требование | Минимум | Команда проверки | Ожидаемый результат |
|---|---|---|---|
| Кластер Kubernetes | 1.27+ | kubectl version | Server Version >= v1.27 |
| Kustomize (поставляется с kubectl) | Kustomize v1.14+ (поставляется в kubectl 1.27+) | kubectl kustomize --help | Выводит текст справки |
| Helm | v3 | helm version | Version:"v3.x.x" |
| cluster-admin RBAC | — | kubectl auth can-i create namespaces | yes |
| Класс хранилища по умолчанию | — | kubectl get storageclass | По крайней мере одна строка отмечена (default) |
| Поддержка LoadBalancer | — | Зависит от облака (EKS, GKE, AKS поддерживают по умолчанию) | — |
| GitHub PAT | — | echo $AGENTEYE_TOKEN | Не пусто (см. enterprise-docs/github-token.md) |
| openssl | — | openssl version | OpenSSL 1.x или 3.x |
| Бакет облачного хранилища | — | Для резервных копий PostgreSQL + ClickHouse (S3, GCS или Azure Blob) | — |
Запустить все проверки сразу
Форма развертывания
Конечная точка приема работает на имени хоста, которым вы управляете (например,ingest.your-company.example). cert-manager запрашивает общедоступный сертификат TLS от Let’s Encrypt через HTTP-01, поэтому сборщики проверяют сертификат сервера в системном хранилище доверия без привязки CA для каждого клиента.
Конечная точка панели работает так же: она работает на втором имени хоста, которым вы управляете (например, agenteye.your-company.example), указывающем на LoadBalancer Traefik панели, и cert-manager выпускает его сертификат Let’s Encrypt через этот LoadBalancer. Браузеры получают доверенный сертификат без предупреждения.
Выпуск сертификата и обновление проверяются через HTTP-01, поэтому оба LoadBalancer должны быть доступны из общественного интернета на порту 80. Если вам нужно ограничить IP-адреса для LoadBalancer панели, сначала согласуйте решатель DNS-01 с поддержкой — в противном случае обновления молча не срабатывают и сертификат истекает.
Получение манифестов
AGENTEYE_TOKEN.
Структура каталогов:
Мониторинг здоровья (опционально): проверка готовности сервера уже отражает здоровье Postgres + ClickHouse, и third-party/robusta/ добавляет опциональное оповещение об отказе pod в Slack на уровне Kubernetes. См. enterprise-docs/health-monitoring.md.
Этап 1 — Инфраструктура третьих лиц (~30 мин)
1.1 Установка cert-manager
cert-manager управляет TLS сертификатами для HTTPS и приватным CA, используемым для сертификатов клиента mTLS.Running — cert-manager, cert-manager-cainjector, cert-manager-webhook.
certificates.cert-manager.io, clusterissuers.cert-manager.io, issuers.cert-manager.io.
Если не удалось: Pod’ы в CrashLoopBackOff обычно означают, что CRD не были установлены. Повторно запустите с --set crds.install=true. Если pod’ы webhook не прошли проверку готовности, подождите 30 секунд и проверьте снова — они могут требовать немного времени на запуск.
1.2 Установка Traefik — контроллер входящего трафика для общественного приема
Этот экземпляр Traefik обрабатывает трафик сборщика на внешнем LoadBalancer. Он завершает TLS и обеспечивает mTLS (проверку сертификата клиента) на конечной точке приема.Running.
kubectl describe pod -n traefik-public <pod-name> на предмет ошибок извлечения образа или ограничений ресурсов.
1.3 Установка Traefik — контроллер панели
Этот экземпляр Traefik обслуживает панель на выделенном LoadBalancer, ограниченном списком разрешенных IP-адресов.Два механизма разрешения списков поставляются для этого экземпляра. Это руководство используетПеред установкой отредактируйтеvalues-dashboard.yaml, который ограничивает доступ переносимым полемservice.loadBalancerSourceRanges. Параллельныйvalues-internal.yamlтакже предоставляется для окружений AWS, которые предпочитают аннотациюservice.beta.kubernetes.io/aws-load-balancer-source-ranges. Выберите один и используйте его постоянно; шаги ниже предполагаютvalues-dashboard.yaml.
third-party/traefik/values-dashboard.yaml для установки разрешенных IP-адресов источника. Поле loadBalancerSourceRanges управляет тем, какие IP-адреса могут получить доступ к панели. По умолчанию установлено 0.0.0.0/0 (все IP-адреса); ограничьте его вашим VPN, офисом или известными IP-адресами исходящего трафика.
Разрешить один IP-адрес
Разрешить несколько IP-адресов
Добавьте одну запись для каждого IP-адреса или блока CIDR. Суффикс/32 соответствует одному адресу IPv4; блок CIDR (например, /24) соответствует диапазону. Вы можете смешивать отдельные IP-адреса и диапазоны свободно:
- Держите одну запись на строку и добавляйте краткий комментарий
#для идентификации владельца каждого IP-адреса или назначения; это то, что будущие операторы используют для определения необходимости записи. - Всегда используйте нотацию CIDR. Простой IP-адрес как
203.0.113.10отклоняется облачным поставщиком; используйте203.0.113.10/32. - Для диапазонов IPv6 используйте эквивалент
/128(один адрес) или больший CIDR, например2001:db8::1/128. Не все облачные поставщики поддерживают диапазоны источников IPv6; проверьте документацию LoadBalancer вашего поставщика. - Список это OR: трафик разрешен, если источник соответствует любой записи.
helm install ниже. Если контроллер уже установлен, запустите helm upgrade с теми же флагами или примените патч Service во время выполнения (следующий раздел).
Обновить список разрешений во время выполнения
Вы можете изменить разрешенные IP-адреса без обновления Helm, применив патч Service напрямую. Патч заменяет весь список; всегда включайте каждый IP-адрес, который вы хотите сохранить, а не только новый. Для замены списка новым набором IP-адресов:
Патчи во время выполнения не сохраняются обратно в values-dashboard.yaml. Для сохранения изменения при будущих обновлениях Helm также обновите файл значений и зафиксируйте его.
Затем установите:
Running.
1.4 Ожидание LoadBalancer’ов
Оба экземпляра Traefik нуждаются в внешних IP-адресах перед продолжением.EXTERNAL-IP (не <pending>).
Если все еще ожидание, наблюдайте за назначением:
Ctrl+C после появления IP-адреса. Назначение IP обычно занимает 2-5 минут.
Если не удалось: <pending> через 10 минут обычно означает, что облачный поставщик не может выделить LoadBalancer. Проверьте: теги подсети (EKS требует kubernetes.io/role/elb), конфигурацию VPC, квоты услуги и что правильная аннотация внутреннего LB установлена для внутреннего экземпляра.
Этап 2 — Создание секретов (~10 мин)
Все секреты создаются вручную перед развертыванием приложения. Это гарантирует, что конфиденциальные значения никогда не появляются в файлах манифестов.2.1 Создание пространства имен
Active.
2.2 Секрет для извлечения образа
Этот секрет аутентифицируется сghcr.io для извлечения контейнерных образов AgentEye. См. enterprise-docs/github-token.md для генерации PAT.
kubernetes.io/dockerconfigjson.
Проверьте это (глубоко) — убедитесь, что токен может действительно извлекать образы:
Используйте тег образа server, указанный в kustomization.yaml вашего overlay (в настоящее время v0.0.1-beta.48 в обоих поставляемом overlay acme и базовом развертывании). Замените тег ниже на тот, который вы развертываете, чтобы эта проверка не дрейфовала между выпусками:
ok выводится в логах.
Если не удалось: ErrImagePull или 401 Unauthorized означает, что PAT недействителен или не имеет области read:packages. Повторно проверьте enterprise-docs/github-token.md.
2.3 Учетные данные PostgreSQL
Важно: Мы используем-hex(не-base64) для создания пароля. Выходные данные Base64 могут содержать+,/и=, которые нарушают строку подключенияDATABASE_URL. Подробности см. в enterprise-docs/troubleshooting.md.
Сохраните POSTGRES_PASSWORD в менеджер секретов немедленно. Вам это понадобится, если вы когда-либо восстанавливаете из резервной копии или подключаетесь к базе данных напрямую.
Проверьте это:
48 (24 hex байта = 48 символов).
2.4 Ключ администратора API
Сохраните ADMIN_KEY в менеджер секретов немедленно.
Проверьте это:
2.5 Конфигурация аутентификации (вход на панель)
Панель использует электронную почту + OTP для входа пользователя. Без этого секрета сервер все еще запускается и путьADMIN_KEY API продолжает работать, но ни один пользователь не может войти через пользовательский интерфейс.
Все ключи упоминаются как optional: true в базовом манифесте, поэтому частичные секреты (или вообще отсутствие секрета) нормальны; сервер возвращается к задокументированным значениям по умолчанию. Упаковка всего в один секрет agenteye-auth держит поверхность аутентификации ротируемой в одном месте.
| Ключ | Назначение |
|---|---|
ADMIN_EMAIL | Пользователь администратора начальной загрузки. Обновляется при каждом запуске со всеми разрешениями и защищен от удаления/редактирования разрешений через панель. Без него администратор не может быть созданный начальный и первый вход невозможен. |
ALLOWED_EMAILS | Список разрешений через запятую. Поддерживает точные адреса (user@example.com) и подстановочные знаки для доменов (*@example.com). Без него ни один пользователь не может войти или быть создан. |
SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD, SMTP_FROM | Ретрансляция SMTP для отправки кодов OTP. Если SMTP_HOST не установлен, коды OTP записываются в stdout сервера вместо отправки по электронной почте (полезно для первоначальной дымовой проверки). Предоставьте все ключи SMTP вместе для реальной доставки электронной почты. |
SMTP_TLS | Один из starttls (по умолчанию), tls или none. |
DEFAULT_ORG_NAME, DEFAULT_ORG_SLUG | Опционально. Дайте встроенной организации default дружественное отображаемое имя и слаг URL, так что она находится, например, в /acme вместо /default. Применяется только при первой загрузке; после переименования org с agenteye-orgctl org rename (см. §7.6) эти параметры игнорируются. Слаг должен быть 1-40 строчных буквоцифровых символов с одиночными внутренними дефисами. Оставьте оба неустановленными, чтобы сохранить общий default. |
Сохраните учетные данные SMTP в менеджер секретов.Проверьте это:
2.6 Ключ изоляции организаций для нескольких клиентов (опционально)
Пропустите это для развертывания с одним клиентом; сервер работает на встроенной разработке по умолчанию и отлично служит одной организацииdefault. Перед созданием второй организации установите сильный, стабильный ORG_CH_SECRET: пароль ClickHouse каждой организации получается как HMAC(ORG_CH_SECRET, org_id), поэтому общедоступное значение разработки по умолчанию дало бы общедоступные производные учетные данные для каждой организации. Команда agenteye-orgctl org create (см. §7.6 Подготовка организаций) отказывается запускаться, пока сервер остается на встроенном значении разработки по умолчанию.
secretKeyRef, поэтому кластер с одним клиентом, который никогда его не создает, все еще нормально запускается. Держите значение стабильным и идентичным во всех репликах; его ротация делает недействительным пароль производного ClickHouse каждой организации до тех пор, пока переинициализация начальной загрузки не переприведет пользователей (перезагрузка с постоянным значением везде заживает его). См. deploy/base/server/secret.example.yaml.
Сохраните ORG_CH_SECRET в менеджер секретов и не ротируйте его случайно.
2.7 Проверка всех секретов
agenteye-admin-key, agenteye-auth, agenteye-image-pull, agenteye-postgres) должны присутствовать перед продолжением. agenteye-org-ch-secret требуется только для развертываний с несколькими клиентами (см. §2.6).
Этап 3 — Развертывание приложения (~5 мин)
3.1 Конфигурирование общедоступных имен хостов
cert-manager нужны имена хостов приема и панели перед запросом их сертификатов Let’s Encrypt. Скопируйте шаблон и установите оба:domain.env находится в gitignore; это остается локально для каждого развертывания. Сборка kustomize громко не срабатывает, если один из ключей отсутствует.
DNS должен сначала разрешиться. Вам не нужно указывать DNS на LB’ы сейчас (они не существуют до завершения этапа 1.2), но выпуск ACME на шаге 3.2 будет повторно пытаться до тех пор, пока каждое имя хоста разрешится на его LoadBalancer. Вы можете либо установить DNS сейчас (используя имена хостов LB, захваченные на этапе 1.4), либо продолжить и добавить записи на этапе 4.
3.2 Применение манифестов
Примените базу непосредственно для нового установления или overlay если вы его вырезали для этой среды (overlay’ы просто закрепляют теги образов, переменные среды и лимиты ресурсов; они наследуют сертификаты и маршрутизацию базы):3.3 Ожидание pod’ов
agent (AI помощник) и redis появляются рядом с ними; помощник остается неактивным до предоставления его конечной точки LLM (см. enterprise-docs/assistant.md), а Redis является кэшем, лучшего качества, поэтому ни то, ни другое не нужно готовиться для платформы для обслуживания трафика.
Проверьте это:
agent и redis также появляются и достигают Running):
| Статус Pod’а | Вероятная причина | Команда отладки |
|---|---|---|
ImagePullBackOff | Плохой секрет для извлечения образа или PAT | kubectl describe pod <name> -n agenteye |
CrashLoopBackOff | Плохие переменные среды (например, DATABASE_URL) | kubectl logs <name> -n agenteye |
Pending | Недостаточно CPU/памяти или нет узлов | kubectl describe pod <name> -n agenteye (проверьте Events) |
3.4 Проверка хранилища
Bound:
| PVC | Емкость | Основа |
|---|---|---|
postgres-data-postgres-0 | 50Gi | Хранилище реляционных данных/метаданных PostgreSQL |
clickhouse-data-clickhouse-0 | 100Gi | Хранилище аналитики событий + оценок ClickHouse |
redis-data-redis-0 (1Gi) также появляется для опционального кэша.
Если не удалось: Pending означает, что ни один StorageClass не может выделить том. Проверьте kubectl get storageclass и убедитесь, что существует по умолчанию. Для производства наложите том ClickHouse на быстрый SSD StorageClass (например, gp3 на AWS, pd-ssd на GCP); пропускная способность сжатия страдает на медленных дисках.
3.5 Проверка сертификатов
Ready: True:
| Имя | Издатель | Назначение |
|---|---|---|
mtls-ca | selfsigned | Приватный CA для выпуска сертификатов клиента mTLS (валидность 10 лет) |
ingest-tls | letsencrypt-prod | Общедоступный TLS сертификат для конечной точки приема (90 дней, автоматическое обновление) |
dashboard-tls | letsencrypt-prod | Общедоступный TLS сертификат для панели (90 дней, автоматическое обновление) |
ingest-tls или dashboard-tls не готов:
kubectl describe certificate <name> -n agenteye и прочитайте Events. Общие причины:
- DNS еще не указывает на LB. Let’s Encrypt разрешает имя хоста и попадает на порт 80 для валидации —
INGEST_DOMAINдолжен разрешиться на общественный LB,DASHBOARD_DOMAINна LB панели. До распространения CNAME/Alias заказ остаетсяpending. После правильного DNS cert-manager автоматически повторит попытку (не нужно удалять Certificate). - Имя хоста не заменено. Если
dnsNamesвсе еще читаетINGEST_DOMAIN_PLACEHOLDER/DASHBOARD_DOMAIN_PLACEHOLDER, вы пропустили шаг 3.1 — создайтеbase/certificates/domain.envи повторно примените. - Traefik панели не может обслужить вызов (только
dashboard-tls). Экземпляр Traefik панели должен быть установлен с поставляемым файлом значений (этап 1.2), который включает поставщика Ingress с областью видимости, который обслуживает решатель HTTP-01 cert-manager. Экземпляр установленный без этого оставляет вызов неуспешным и заказpendingнавечно.
mtls-ca не готов: cert-manager сам неисправен. Повторно проверьте pod’ы cert-manager из шага 1.1.
3.6 Проверка CronJob’ов
| Имя | Расписание | Назначение |
|---|---|---|
agenteye-backup | 0 3 * * * | Ежедневная резервная копия Postgres + ClickHouse в 03:00 UTC |
cert-renewal-check | 0 3,15 * * * | Предупреждения об истечении сертификата в 03:00 и 15:00 UTC |
3.7 Проверка правильного запуска сервера
POSTGRES_PASSWORD содержит символы, небезопасные для URL, которые нарушают DATABASE_URL. См. enterprise-docs/troubleshooting.md.
3.8 Проверка подключения панели к серверу
Ready в выводе без ECONNREFUSED или аналогичных ошибок.
Если не удалось: Проверьте, что Service server существует (kubectl get svc server -n agenteye) и что AGENTEYE_SERVER_URL установлена на http://server:8080 в развертывании панели.
Этап 4 — Сетевой доступ (~5 мин)
4.1 Получение адресов LoadBalancer’ов
На AWS EKS LoadBalancer’ы возвращают имя хоста вместо IP-адреса. ЗаменитеПроверьте это:.ipна.hostnameв командах выше.
4.2 Точка DNS на LoadBalancer’ы
Создайте записи DNS так, чтобы имена хостов изbase/certificates/domain.env разрешались на их LoadBalancer’ы — INGEST_DOMAIN на общественный LB Traefik, DASHBOARD_DOMAIN на LB панели Traefik:
- AWS Route 53: запись
AсAlias = Yes, цель = имя хоста LB. Не используйте простой A → IP; IP ELB ротируются. - Любой другой поставщик:
CNAMEот имени хоста к имени хоста LB.
$PUBLIC_IP и $INTERNAL_IP соответственно (или на EKS разрешаться на то же имя хоста *.elb.amazonaws.com).
После разрешения DNS cert-manager завершит ожидающие заказы ACME из этапа 3.5 в течение минуты. Повторно запустите kubectl get certificates -n agenteye пока оба ingest-tls и dashboard-tls не покажут Ready: True.
4.3 Достижение конечной точки приема
Общественная конечная точка приема обеспечивает взаимный TLS, поэтому каждый запрос (включая/health) должен представить сертификат клиента. Вы выпускаете первый сертификат клиента на этапе 5; если у вас уже есть, проверьте достижимость сейчас:
{"status":"ok"}. Не требуется -k — сертификат сервера цепляется к общедоступному CA для INGEST_DOMAIN, поэтому он проверяется в системном хранилище доверия. Достигайте конечной точки приема по ее имени хоста INGEST_DOMAIN (которое совпадает с выпущенным сертификатом), не по сырому IP/имени хоста LoadBalancer’а.
Конечная точка панели обслуживается на DASHBOARD_DOMAIN с общедоступно доверенным сертификатом и не находится за mTLS, поэтому не требуются -k и сертификат клиента:
DASHBOARD_DOMAIN, поэтому сырой адрес показывает несоответствие имени сертификата.
Если не удалось: Если curl зависает, проверьте, достижим ли LB с вашей машины (VPN, группы безопасности, правила брандмауэра). Ошибка certificate required в рукопожатии на имени хоста приема означает, что сертификат клиента не был представлен; сначала завершите этап 5. Ошибка проверки TLS на имени хоста приема означает, что сертификат сервера еще не закончил выпуск; вернитесь к этапу 3.5 и решите проблему там.
Этап 5 — Выпуск сертификатов клиента mTLS (~10 мин на кластер)
Сборщики аутентифицируются с двумя факторами: сертификатом клиента (транспортный слой, доказывает, что запрос приходит от авторизованного кластера) и ключом API (уровень приложения, доказывает, что запрос от сборщика с разрешениемevents:add). Утечка ключа бесполезна без сертификата; украденный сертификат бесполезен без действительного ключа.
5.1 Выпуск сертификата
Каждый кластер, запускающий сборщики, нуждается в своем собственном сертификате клиента. Из каталога манифестов:<cluster-name> на значимый идентификатор (например, us-east-1-prod, staging).
Проверьте это: Скрипт выводит ==> Done! и перечисляет файлы вывода.
Ready: True.
Файлы вывода в issued/<cluster-name>/:
| Файл | Назначение |
|---|---|
client.crt | Сертификат клиента (валидность 90 дней) |
client.key | Приватный ключ клиента |
ca.crt | Сертификат CA для проверки сервера |
collector-mtls-secret.yaml | Готовый к применению Kubernetes Secret для кластера сборщика |
5.1b Альтернативная доставка: AWS Secrets Manager
Если потребитель сертификата - это Kubernetes Pod’а, которому нужныclient.crt и client.key на диске — типичный случай, когда вы запускаете agenteye-collector как sidecar в pod’е приложения — отправьте пакет сертификата в AWS Secrets Manager. Pod приложения затем подключает его через Secrets Store CSI Driver с IRSA, и ротация сертификата полностью безрук.
PutSecretValue на том же секрете, поэтому ARN и имя остаются стабильными. CSI Driver подхватывает новую версию на следующей ротации опроса и переписывает файлы внутри pod’а.
Предварительные условия:
awsCLI v2 аутентифицированный для вашего аккаунта AWS.jqустановлен.- Переменная окружения
AWS_REGIONустановлена. - IAM разрешения на вашей идентификации вызывающей (область видимости
Resourceкarn:aws:secretsmanager:<region>:<account>:secret:agenteye/mtls-client/*):secretsmanager:CreateSecretsecretsmanager:DescribeSecretsecretsmanager:PutSecretValuesecretsmanager:TagResource
| Шаг | Действие |
|---|---|
| 1 | Выпускает / переизвлекает сертификат через cert-manager (то же, что режим по умолчанию). |
| 2 | Вызывает DescribeSecret на agenteye/mtls-client/<cluster-name> для решения о создании против обновления. |
| 3 | При первом запуске: CreateSecret с трехключевым JSON payload (client.crt, client.key, ca.crt), помечено AgentEyeCluster=<cluster-name>. При последующих запусках: PutSecretValue для публикации новой версии; тег обновлен через TagResource. |
| 4 | Удаляет issued/<cluster-name>/ только после успешной загрузки. При любом отказе каталог сохраняется, так что вы можете повторить попытку. |
aws secretsmanager restore-secret --secret-id agenteye/mtls-client/<cluster-name> перед повтором.
Для полной кабельной разводки pod’а (SecretProviderClass, настройка IRSA, поведение ротации, устранение неполадок) см. enterprise-docs/single-pod-deployment.md.
5.2 Проверка работы сертификата
Протестируйте выпущенный сертификат против входящего mTLS:{"status":"ok"}
Если не удалось:
| Ошибка | Причина | Исправление |
|---|---|---|
certificate required | Сертификат не представляется | Проверьте пути к файлам в команде curl |
bad certificate | Несоответствие CA | Проверьте, что mtls-ca-issuer выпустил сертификат: kubectl describe certificate mtls-client-<name> -n agenteye |
connection refused | Неправильное имя хоста или LB недостижим | Проверьте /etc/hosts или DNS |
5.3 Доставка в кластер сборщика
Отправьтеcollector-mtls-secret.yaml команде, эксплуатирующей кластер сборщика. Они применяют его:
client.crt, client.key, ca.crt).
5.4 Жизненный цикл сертификата
| Свойство | Значение |
|---|---|
| Валидность сертификата клиента | 90 дней |
| Автоматическое обновление | cert-manager обновляет за 15 дней до истечения |
| Валидность CA | 10 лет |
| Предупреждения об истечении | CronJob предупреждает за 30 дней до истечения (этап 6) |
issue-client-cert.sh и повторно примените collector-mtls-secret.yaml перед истечением старого сертификата.
Если вы используете --save-to aws-secrets-manager (см. § 5.1b), повторно запустите ту же команду. Скрипт вызывает PutSecretValue на том же секрете; pod’ы подключающие секрет через Secrets Store CSI Driver подхватывают новую версию на следующем опросе ротации (по умолчанию: каждый час), без перезагрузки pod’а.
5.5 Отзыв сертификата
Для немедленной блокировки доступа сборщика кластера:curl из шага 5.2 теперь не срабатывает с ошибкой рукопожатия TLS.
Этап 6 — Мониторинг обновления сертификата (~2 мин)
Встроенный CronJob запускается каждые 12 часов (03:00 и 15:00 UTC) и проверяет все сертификаты клиента с меткойagenteye.io/cert-type=mtls-client. Он предупреждает, когда какой-либо сертификат находится в пределах 30 дней до истечения.
6.1 Включение уведомлений Slack (опционально)
6.2 Проверка CronJob’а
get, list на ресурсах Certificate cert-manager. Проверьте с: kubectl describe role cert-renewal-check -n agenteye.
Очистите тестовое задание:
Этап 7 — Проверка end-to-end
Этот этап подтверждает, что вся конвейер работает: проверка здоровья, создание ключей, прием событий и отображение панели.Примечание: Примеры ниже достигают конечной точки приема по ее сырому адресу LoadBalancer’а (${PUBLIC_IP}) для удобства, поэтому они передают-k; сертификат сервера привязан кINGEST_DOMAIN, не к IP LB, поэтому проверка имени хоста пропускается. Конечная точка приема обеспечивает взаимный TLS на каждом пути, поэтому каждый вызов также должен представить сертификат клиента (--cert/--key). Для также проверки общедоступного сертификата целевойhttps://ingest.your-company.example/...вместо${PUBLIC_IP}и удалите-k.
7.1 Проверка здоровья
{"status":"ok"} с HTTP 200.
7.2 Создание областных ключей сборщика
Ключ администратора предназначен для начальной загрузки и управления. Создайте выделенные ключиevents:add для сборщиков:
"id", "name": "prod-collector", "permissions": ["events:add"], "created_at".
Проверьте это: Убедитесь, что ключ появляется в списке ключей:
prod-collector появляется в ответе.
Полный справочник управления ключей см. в enterprise-docs/api-keys.md.
7.3 Прием тестового события
{"accepted":1,"skipped":0} с HTTP 200.
Если не удалось:
| HTTP статус | Причина |
|---|---|
| 401 | Недействительный или отсутствующий ключ API |
| 403 | Ключу не хватает разрешения events:add |
| Ошибка рукопожатия TLS | Проблема с сертификатом клиента — см. устранение неполадок этапа 5 |
7.4 Проверка появления события на панели
Откройтеhttps://agenteye.your-company.example (ваш DASHBOARD_DOMAIN) в браузере. Сертификат общедоступно доверенный, поэтому нет предупреждения.
Если LB панели ограничен списком разрешенных IP-адресов и вы не можете подключиться, проверьте, что ваш IP разрешен:Помните, что Let’s Encrypt обновляет сертификат панели через HTTP-01 на порту 80, и диапазоны источников применяются ко всему LoadBalancer’у — перед ограничением его корпоративными диапазонами согласуйте решатель DNS-01 с поддержкой или обнов

