баг репорт и графифай

DEVOPS.md

@@ -98,8 +98,9 @@ graph TD
   * Для связи с Ingress настроен ClusterIP-сервис на порту 8080.
   
 * **Ingress (`ingress.yaml`)**:
-  * В роли Ingress-контроллера выступает стандартный для K3s **Traefik**.
-  * Мной настроены строгие правила маршрутизации по доменным именам (например, `magistr.zuev.company` для тестового окружения, `n8n.zuev.company` и т.д.). Маршрутизация по путям разделяет трафик: запросы к API (`/api`) проксируются на бэкенд-сервис, а запросы к статическим ресурсам и страницам (`/`) — на фронтенд-сервис.
+  * В роли Ingress-контроллера выступает встроенный **Traefik** (`kube-system/traefik`).
+  * Он доступен извне через Klipper Service LoadBalancer (DaemonSet), который прокидывает порты 80/443 (hostPort) на внешние IP адреса нод кластера (`192.168.1.104`, `192.168.1.105`, `192.168.1.106`).
+  * Мной настроены строгие правила маршрутизации по доменным именам (например, `magistr.zuev.company` и `n8n.zuev.company`). Запросы к API (`/api`) проксируются на бэкенд, а к корню (`/`) — на фронтенд.
 
 ### 3.2 Реализация динамической мультитенантности через K8s API
 Одним из наиболее сложных этапов проектирования стала организация бесшовного добавления новых университетов без перезапуска бэкенда и изменения исходного кода приложения.
@@ -199,19 +200,16 @@ graph TD
 4. **Build & Push**: Параллельная сборка Docker-образов для бэкенда и фронтенда с тегом `latest` и отправка их в приватный реестр.
 
 ### 5.2 Доставка в кластер (CD)
-Для авторизации нод K3s в приватном реестре Gitea мной был создан секрет типа `docker-registry` в пространстве имен `magistr`:
+Для авторизации нод K3s в приватном реестре Gitea мной был создан секрет `gitea-registry` типа `docker-registry` в пространстве имен `magistr`. Этот секрет ассоциирован со спецификациями деплоев через директиву `imagePullSecrets`.
+
+Непосредственно Gitea Actions Runner работает как демон `act_runner` внутри изолированного LXC контейнера (CTID 107). В пайплайне шаг развертывания (`deploy-to-k8s`) динамически генерирует `kubeconfig` из секрета, устанавливает утилиту `kubectl` и выполняет императивное обновление релизов без использования тяжеловесных GitOps операторов:
+
 ```bash
-kubectl create secret docker-registry gitea-registry \
-  --docker-server=gitea.zuev.company \
-  --docker-username=Zuev \
-  --docker-password=${ZUEV_TOKEN} \
-  --namespace=magistr
-```
-Этот секрет ассоциирован со спецификациями деплоев в `backend.yaml` и `frontend.yaml` через директиву `imagePullSecrets`. Обновление приложений в кластере после завершения сборки образов выполняется путем контролируемого перезапуска подов:
-```bash
-kubectl rollout restart deployment backend -n magistr
-kubectl rollout restart deployment frontend -n magistr
+kubectl rollout restart deployment backend frontend -n magistr
+kubectl rollout status deployment/frontend -n magistr --timeout=120s
+kubectl rollout status deployment/backend -n magistr --timeout=300s
 ```
+Поскольку манифесты используют `imagePullPolicy: Always` и тег `:main`, поды автоматически скачивают свежие слои собранных образов.
 
 ---
 
@@ -226,23 +224,35 @@ kubectl rollout restart deployment frontend -n magistr
 * Полноценной поддержке протокола HTTP/3 «из коробки».
 
 ### 6.2 Конфигурация балансировки
-Внешний Caddy-сервер принимает запросы ко всем поддоменам `*.zuev.company` и перенаправляет их на ноды кластера K3s, выполняя роль внешнего балансировщика нагрузки (L4/L7 Load Balancer):
+Внешний Caddy-сервер развернут в изолированном LXC контейнере (CTID 101) и обрабатывает запросы ко всем поддоменам проекта. Он перенаправляет их на ноды кластера K3s, выполняя роль внешнего балансировщика, а также проксирует телеметрию с фронтенда напрямую в сборщик OTel:
+
 ```caddyfile
-*.zuev.company {
-    reverse_proxy 192.168.1.104:80 192.168.1.105:80 192.168.1.106:80 {
-        lb_policy round_robin
-        lb_try_duration 5s
-        lb_try_interval 250ms
-    }
+(otel_proxy) {
+  handle_path /otel/* { reverse_proxy 192.168.1.100:4318 }
 }
+
+(k8s_nodes) {
+  handle {
+    reverse_proxy 192.168.1.104:80 192.168.1.105:80 192.168.1.106:80 {
+      lb_policy round_robin
+      lb_try_duration 5s
+      lb_try_interval 250ms
+    }
+  }
+}
+
+magistr.zuev.company { import otel_proxy; import k8s_nodes }
+n8n.zuev.company { import otel_proxy; import k8s_nodes }
 ```
-Сетевые запросы распределяются по нодам K3s по алгоритму Round-Robin. В случае недоступности одной из нод, Caddy временно исключает ее из пула, обеспечивая отказоустойчивость инфраструктуры на сетевом уровне.
+Сетевые запросы к приложениям распределяются по 3 физическим нодам K3s. Благодаря сниппетам, добавление нового тенанта в инфраструктуре Caddy требует всего двух строчек конфигурации.
 
 ---
 
 ## РАЗДЕЛ 7. СКВОЗНОЙ МОНИТОРИНГ И ОБСЕРВАБИЛИТИ (SigNoz + OpenTelemetry)
 
-Для контроля здоровья системы и оперативного выявления аномалий мной была спроектирована и внедрена централизованная система мониторинга на базе APM-платформы **SigNoz** и стандартов **OpenTelemetry (OTel)**.
+Для контроля здоровья системы и оперативного выявления аномалий мной была спроектирована и внедрена централизованная система мониторинга на базе APM-платформы **SigNoz** (с хранилищем **ClickHouse**) и стандартов **OpenTelemetry (OTel)**. 
+
+Платформа SigNoz вынесена в отдельный LXC контейнер (CTID 100) по адресу `192.168.1.100` и развернута через `docker-compose`. Данные ClickHouse и SQLite метаданные персистентно хранятся в Docker volumes хоста для обеспечения сохранности при рестартах.
 
 ### 7.1 Сбор телеметрии Backend
 Java-приложение бэкенда запускается с подключением агента OpenTelemetry (`opentelemetry-javaagent.jar`). Это позволяет без изменения кода собирать: