Eco²

Як насправді з’єднані 24 вузли, по одному потоку за раз.

Самокерований Kubernetes, зібраний за допомогою kubeadm. Карта розміщує 24 фізичні вузли й робочі навантаження на них у п’яти шарах із README і з’єднує їх фактичними зв’язками. Оберіть потік, і буде підсвічено лише цей шлях із пронумерованими кроками.

Він розпізнає відходи на фото й пояснює, як їх утилізувати, а в розмові викликає інструменти для місць, погоди, цін на вторсировину та вебпошуку й генерує зображення. У цьому командному проєкті я почав із кластера й основи розгортання, а потім розширив свою зону до доменного бекенду, асинхронної обробки, розмовного агента й верифікації.

Від розробки для конкурсу до посилення бекенду й експлуатації

Сервіс завершив роботу; записане демо й технічний звіт показують його в дії.

Карта зв’язків кластера · накреслено заново за маніфестами й кодом на коміті a072127

Запит Scan → доставка наживо

Запит на аналіз фото стає роботою в черзі, а події її поступу повертаються в той самий браузер.

БраузерDNS-запит: DNS-запитRoute 53
З записів Route 53 визначається лише ім’я. Запити через DNS не проходять.
Браузерпотік даних: HTTPS 443AWS ALB
TLS завершується на ALB.
AWS ALBпотік даних: HTTP · NodePortIstio ingress Envoyk8s-ingress-gateway
Передається в Istio ingress Envoy через NodePort цілі-інстансу EC2.
Istio ingress Envoyk8s-ingress-gatewayпотік даних: VirtualServiceScan APIk8s-api-scan
Маршрутизується до Scan API, який ставить роботу в чергу й одразу повертає job_id; на запит результату він відповідає 202, доки завдання не завершиться.
Scan APIk8s-api-scanпотік даних: Завдання CeleryRabbitMQk8s-rabbitmq
Завдання Scan іде в RabbitMQ.
RabbitMQk8s-rabbitmqпотік даних: consumescan-workerk8s-worker-ai · k8s-worker-ai-2
scan-worker (Celery · gevent) у пулі AI бере його й виконує Vision → Rule → Answer → Reward. Чотири етапи — це завдання Celery, з’єднані в ланцюжок, а не вузли.
Пул AIk8s-worker-ai · k8s-worker-ai-2потік даних: HTTPSLLM API
Воркери scan і chat викликають API OpenAI і Google.
scan-workerk8s-worker-ai · k8s-worker-ai-2потік даних: XADD scan:eventsStreamsk8s-redis-streams
Події поступу записуються в один із чотирьох шардів Streams.
Streamsk8s-redis-streamsпотік даних: XREADGROUPEvent Routerk8s-event-router
Event Router читає їх як consumer group і після обробки виконує XACK; pending і reclaim забезпечують доставку at-least-once.
Event Routerk8s-event-routerпотік даних: SETEX stateState KVk8s-redis-streams
Він записує останній стан і маркер повторної обробки в State KV на тому самому вузлі Redis.
Event Routerk8s-event-routerпотік даних: PUBLISHPub/Subk8s-redis-pubsub
Доставляється в реальному часі каналом завдання в шардованому Pub/Sub.
Pub/Subk8s-redis-pubsubпотік даних: SUBSCRIBESSE Gatewayk8s-sse-gateway
SSE Gateway підписується через один спільний listener на процес і розсилає кожному підключеному браузеру.
SSE Gatewayk8s-sse-gatewayпотік даних: Потік SSEБраузер
З’єднання, відкрите тим самим шляхом через ALB та ingress. Доставка at-least-once; дублікати обробляються ідемпотентно.
State KVk8s-redis-streamsпотік даних: Відновлення після перепідключенняSSE Gatewayk8s-sse-gateway
Під час перепідключення з Last-Event-ID State KV і збережені Streams заповнюють пропущені події.

Chat · токени й зберігання

Токени Chat ідуть тим самим шляхом подій, що й Scan; контрольні точки й повідомлення зберігають два різні робочі навантаження.

Браузерпотік даних: HTTPS 443AWS ALB
TLS завершується на ALB.
AWS ALBпотік даних: HTTP · NodePortIstio ingress Envoyk8s-ingress-gateway
Передається в Istio ingress Envoy через NodePort цілі-інстансу EC2.
Istio ingress Envoyk8s-ingress-gatewayпотік даних: VirtualServiceChat APIk8s-api-chat
Маршрутизується до Chat API.
Chat APIk8s-api-chatпотік даних: Завдання TaskiqRabbitMQk8s-rabbitmq
Завдання Chat іде в RabbitMQ.
RabbitMQk8s-rabbitmqпотік даних: consumechat-workerk8s-worker-ai · k8s-worker-ai-2
chat-worker (Taskiq · asyncio) класифікує намір за допомогою LangGraph, потім за потреби виконує vision, обрані інструменти, aggregator і за потреби підсумок, після чого відповідає. Кожен запит виконує лише потрібні йому гілки.
Пул AIk8s-worker-ai · k8s-worker-ai-2потік даних: HTTPSLLM API
Воркери scan і chat викликають API OpenAI і Google.
chat-workerk8s-worker-ai · k8s-worker-ai-2потік даних: XADD chat:eventsStreamsk8s-redis-streams
Токени й події етапів записуються в чотири шарди Streams; далі шлях доставки такий самий, як у Scan.
Streamsk8s-redis-streamsпотік даних: XREADGROUPEvent Routerk8s-event-router
Event Router читає їх як consumer group і після обробки виконує XACK; pending і reclaim забезпечують доставку at-least-once.
Event Routerk8s-event-routerпотік даних: PUBLISHPub/Subk8s-redis-pubsub
Доставляється в реальному часі каналом завдання в шардованому Pub/Sub.
Pub/Subk8s-redis-pubsubпотік даних: SUBSCRIBESSE Gatewayk8s-sse-gateway
SSE Gateway підписується через один спільний listener на процес і розсилає кожному підключеному браузеру.
SSE Gatewayk8s-sse-gatewayпотік даних: Потік SSEБраузер
З’єднання, відкрите тим самим шляхом через ALB та ingress. Доставка at-least-once; дублікати обробляються ідемпотентно.
chat-workerk8s-worker-ai · k8s-worker-ai-2потік даних: checkpointCachek8s-redis-cache
Контрольна точка LangGraph зберігається в Redis Cache.
Cachek8s-redis-cacheпотік даних: читання контрольної точкиcheckpoint-syncerk8s-worker-ai · k8s-worker-ai-2
checkpoint-syncer читає контрольну точку з Redis.
checkpoint-syncerk8s-worker-ai · k8s-worker-ai-2потік даних: синхронізація з PostgreSQLPostgreSQLk8s-postgresql
AsyncPostgresSaver асинхронно зберігає її в PostgreSQL.
Streamsk8s-redis-streamsпотік даних: chat-persistence grouppersistence consumerk8s-api-chat
persistence consumer на вузлі Chat читає події done як consumer group.
persistence consumerk8s-api-chatпотік даних: збереження повідомленьPostgreSQLk8s-postgresql
Повідомлення Chat зберігаються в PostgreSQL. Це інше робоче навантаження, ніж checkpoint-syncer.

Вхід · автентифікація

Синхронний шлях від входу в кластер до доменного API. Лише шляхи під політикою спершу перевіряють автентифікацію; трафік подів між вузлами йде через Calico VXLAN.

БраузерDNS-запит: DNS-запитRoute 53
З записів Route 53 визначається лише ім’я. Запити через DNS не проходять.
Браузерпотік даних: HTTPS 443AWS ALB
TLS завершується на ALB.
AWS ALBпотік даних: HTTP · NodePortIstio ingress Envoyk8s-ingress-gateway
Передається в Istio ingress Envoy через NodePort цілі-інстансу EC2.
Istio ingress Envoyk8s-ingress-gatewayпотік даних: ext-authz · gRPC 50051ext-authzk8s-api-auth
Лише шляхи під політикою CUSTOM спершу звертаються до Go ext-authz (тайм-аут 2 с, failOpen false). Шляхи на кшталт login, health і docs виключено.
ext-authzk8s-api-authпотік даних: перевірка чорного спискуblacklistk8s-redis-auth
Токен перевіряється за чорним списком Redis.
Istio ingress Envoyk8s-ingress-gatewayпотік даних: VirtualServiceChat APIk8s-api-chat
Маршрутизується до Chat API.
Chat APIk8s-api-chatпотік даних: gRPCimages APIk8s-api-image
Синхронний виклик chat → images, зазначений у README.
auth APIk8s-api-authпотік даних: gRPCusers APIk8s-api-users
Синхронний виклик auth → users, зазначений у README.

Пул storage · асинхронний запис

Чорний список автентифікації та володіння персонажами зберігають воркери пулу storage, які беруть роботу з RabbitMQ.

blacklistk8s-redis-authпотік даних: outbox:blacklistauth-relayk8s-worker-storage · k8s-worker-storage-2
auth-relay (auth-Bus у README) читає outbox Redis.
auth-relayk8s-worker-storage · k8s-worker-storage-2потік даних: blacklist.eventsRabbitMQk8s-rabbitmq
Він повторно публікує в RabbitMQ, з повторами й DLQ.
RabbitMQk8s-rabbitmqпотік даних: blacklist.eventsauth-workerk8s-worker-storage · k8s-worker-storage-2
auth-worker отримує події чорного списку.
auth-workerk8s-worker-storage · k8s-worker-storage-2потік даних: збереження чорного спискуblacklistk8s-redis-auth
Вони зберігаються в чорному списку Redis.
RabbitMQk8s-rabbitmqпотік даних: Celery batchusers-workerk8s-worker-storage · k8s-worker-storage-2
users-worker отримує роботу з володіння персонажами пакетами.
users-workerk8s-worker-storage · k8s-worker-storage-2потік даних: UPSERTPostgreSQLk8s-postgresql
Вона застосовується до PostgreSQL.

Налаштування · масштабування · спостереження

Platform Layer — не етап, через який проходять запити; він розгортає, налаштовує, масштабує й спостерігає інші шари. Вузли — це інстанси EC2, створені Terraform, із kubeadm і Calico, встановленими через Ansible; CI лише перевіряє Terraform і ніколи не застосовує його автоматично.

GitHub Actions · Docker Hubналаштування · масштабування: образ · ревізія маніфестуArgo CD image updaterk8s-master
Argo CD узгоджує конфігурацію кластера через App-of-Apps і Sync Waves. Підтверджено лише розміщення image updater на control-plane.
ALB Controller · ExternalDNSk8s-masterналаштування · масштабування: Ingress → ALB · DNS-записиПід керуванням AWS
ALB Controller і ExternalDNS налаштовують ресурси на боці AWS. Це не шлях, яким проходять запити.
Istiodk8s-masterналаштування · масштабування: конфігурація xDSIstio ingress Envoyk8s-ingress-gateway
Istiod передає конфігурацію Gateway, VirtualService і EnvoyFilter через xDS в ingress Envoy і в Envoy sidecar кожного API.
KEDAk8s-monitoringналаштування · масштабування: кількість подівПул AIk8s-worker-ai · k8s-worker-ai-2
KEDA змінює кількість подів воркерів. Кількість вузлів не змінюється.
KEDAk8s-monitoringналаштування · масштабування: кількість подівпул storagek8s-worker-storage · k8s-worker-storage-2
Поди воркерів пулу storage масштабуються так само.
Fluent Bitспостережуваність: журналиElasticsearchk8s-logging
Fluent Bit — DaemonSet на кожному вузлі, що надсилає журнали в Elasticsearch.
Пул AIk8s-worker-ai · k8s-worker-ai-2спостережуваність: трасування запусків LLMLangSmith
Траси викликів LLM ідуть до LangSmith — зовнішнього SaaS.

Усі зв’язки однакової товщини. Оберіть потік, щоб підсвітити лише його шлях із пронумерованими кроками.

Суцільна · напрямок, яким рухаються запити, робота, події й записи
Пунктирна · DNS-запит; запити через нього не проходять
Штрихова · налаштування чи масштабування; не шлях даних
Довга штрихпунктирна · журнали й трасування запусків
Товста чорна лінія · обраний потік; номери показують порядок
Рамка · фізичний вузол, ім’я хоста в заголовку
Внутрішня плашка · робоче навантаження на цьому вузлі
Штрихова рамка · пул планування з двох вузлів
Штрихова рамка · поза кластером, не рахується як вузол
Помаранчевий контур · де вирішує модель

Control plane1 вузол
Domain API8 вузлів
Пул AI2 вузли
пул storage2 вузли
Data5 вузлів
Platform6 вузлів

П’ять шарів із README (смуги) й фізичні групи (відтінок заголовка кожного вузла) групують ті самі 24 вузли по-різному. State KV ділить вузол зі Streams і окремо не рахується; Route 53, ALB і сервіси поза кластером не є вузлами. Пул — це діапазон планування, а не твердження, що кожен под працює на обох вузлах.

Схема з 24 вузлів · за переліком вузлів на дашборді від January 21, 2026

24вузлів

24 = 1 control plane + 8 API + 4 worker + 5 data + 6 platform

1Control plane
role: control-plane
kube-apiserver · scheduler · controller-manager · etcd, а також контролери платформи.
1. k8s-master
8Domain API
domain: <сервіс>
Один вузол на домен. Внутрішні виклики використовують gRPC.
1. k8s-api-auth
2. k8s-api-users
3. k8s-api-scan
4. k8s-api-character
5. k8s-api-location
6. k8s-api-image
7. k8s-api-chat
8. k8s-api-info
4Execution worker
Два пули планування по два вузли. KEDA змінює кількість подів; кількість вузлів лишається тією самою.
пул storagedomain: worker-storage
1. k8s-worker-storage
2. k8s-worker-storage-2
Пул AIdomain: worker-ai
1. k8s-worker-ai
2. k8s-worker-ai-2
5Data
Redis розділено за призначенням на чотири вузли. Сховище PostgreSQL — EBS CSI · gp3.
1. k8s-postgresql
2. k8s-redis-auth
3. k8s-redis-streams
4. k8s-redis-cache
5. k8s-redis-pubsub
6Platform
Обмін повідомленнями, спостережуваність, ingress і доставка в реальному часі мають кожен свій вузол.
1. k8s-rabbitmq
2. k8s-monitoring
3. k8s-logging
4. k8s-ingress-gateway
5. k8s-sse-gateway
6. k8s-event-router

Кожен вузол: Fluent Bit · DaemonSet
Calico

Налаштовані моделі · за провайдерами

Сервіс закрито, тож це моделі, налаштовані в репозиторії, а не варіанти, доступні сьогодні. Кожну роль наведено окремо; це не список перевірених запусків.

OpenAI
Типовий провайдер Chat
Chat
- openai/gpt-5.2типово
Типова модель — gpt-5.2; якщо модель вказано в запиті, використовується вона.
Scan
- gpt-5.2типово
- gpt-5.2-pro
- gpt-5.1
- gpt-5
- gpt-5-pro
- gpt-5-mini
Моделі поза відображенням із 13 моделей відхиляються.
Відображення зображень
- gpt-image-1.5
Окремо від gpt-5.2 — моделі оркестрації Responses. Генерацію зображень типово вимкнено.
Оцінювання
- gpt-4o-miniтипово
LLM grader для оцінювання розмов, окремий від моделі Chat.
Google
Коли в Chat обрано Google
Chat
- google/gemini-3-pro-preview
- google/gemini-3-flash-preview
Якщо обрано Google, типовою є gemini-3-flash-preview.
Scan
- gemini-3-pro-preview
- gemini-3-flash-preview
- gemini-2.5-pro
- gemini-2.5-flash
- gemini-2.5-flash-lite
- gemini-2.0-flash
- gemini-2.0-flash-lite
Відображення зображень
- gemini-3-pro-image-preview

Джерелоbackend main d8840c7Публічний коміт September 29, 2026 · перевірено October 8, 2026

Як насправді з’єднані 24 вузли, по одному потоку за раз.

Запит Scan → доставка наживо

Chat · токени й зберігання

Вхід · автентифікація

Пул storage · асинхронний запис

Налаштування · масштабування · спостереження

1Control plane

8Domain API

4Execution worker

пул storage`domain: worker-storage`

Пул AI`domain: worker-ai`

5Data

6Platform

Налаштовані моделі · за провайдерами

OpenAI

Google

Eco²

Eco² vocabulary

Запит Scan → доставка наживо

Chat · токени й зберігання

Вхід · автентифікація

Пул storage · асинхронний запис

Налаштування · масштабування · спостереження

1Control plane

8Domain API

4Execution worker

пул storagedomain: worker-storage

Пул AIdomain: worker-ai

5Data

6Platform

Налаштовані моделі · за провайдерами

OpenAI

Google

пул storage`domain: worker-storage`

Пул AI`domain: worker-ai`