Главный объект этой статьи не Helm chart и не values файл. Главный объект это Torque stack file. В нем описан порядок разворачивания целой fraud платформы: подготовка хоста, доступ к Kubernetes, облачное хранилище, сервисы данных, приложения, публичные проверки, batch обработка, replay и финальная верификация.
Helmfile может координировать несколько Helm релизов. Argo CD и Flux могут синхронизировать Kubernetes объекты с Git. Terraform и Pulumi могут создать инфраструктуру. Argo Workflows может запускать jobs. В этом стеке такие инструменты используются там, где они уместны, но граница стека шире. Развертывание начинается с удаленного Linux хоста, создает k3s lab на Firecracker microVM, открывает контролируемый tunnel для локального доступа к Kubernetes, создает или проверяет S3 bucket, устанавливает платформенные сервисы, разворачивает fraud workloads, запускает Spark, запускает replay и проверяет путь данных снаружи кластера.
Исходный пакет лежит в stacks/fraud-platform. В опубликованном варианте есть основной stack.yaml, production shaped entrypoint stack-packaged.yaml и profile values, например values-prod.yaml. Lab profile ожидает TORQUE_LAB_SSH для целевого хоста и TORQUE_LAB_PUBLIC_IP для публичных endpoint проверок.
Архитектура платформы
У платформы два пути данных.
Первый путь потоковый. Он начинается в payments API. Это публичный вход для событий. API принимает сгенерированные card payment events, пишет каждое raw событие в topic payments.raw в Redpanda и сохраняет raw JSON object в S3. Redpanda в этом стеке не только очередь. Он также дает schema registry с subjects для raw payment events, risk events и payment decisions. Финальная проверка читает эти subjects и проверяет backward compatibility.
Flink читает raw topic и собирает scoring request. Stream processor отделен от model service. Ray Serve держит model endpoint и возвращает score. Flink записывает decision в ClickHouse и дополнительно отправляет risk output обратно через Redpanda. ClickHouse здесь быстрый operator store. В нем можно смотреть decisions, fraud rates, merchant behavior и batch summaries без чтения lake files.
Второй путь начинается с S3. Argo запускает Spark workflow после того, как платформа доступна. Spark читает raw payment objects и risk decisions, считает aggregate fraud features, пишет curated JSON artifact обратно в S3, добавляет batch rows в ClickHouse и коммитит три Iceberg таблицы через REST catalog:
raw_paymentsrisk_eventsbatch_feature_summary
Trino выступает SQL слоем поверх двух хранилищ. Он читает ClickHouse для быстрых decisions и Iceberg для lakehouse tables. SigNoz отвечает за health surface сервисов и использует ClickHouse как telemetry store.
Kubernetes layout тоже часть архитектуры. Платформа размечает Firecracker ноды по ролям workloads: control, observability, events, processing, machine learning and batch, analytics. Redpanda работает в namespace data. Flink работает в namespace stream. Ray и Spark работают в namespace ml. API и generator работают в namespace apps. SigNoz и его ClickHouse store работают в observability. Trino и Iceberg REST вынесены на analytics node, чтобы SQL доступ был отделен от stream processing и model serving.
Структура Torque stack
Stack graph явно задает порядок операций. Хост должен существовать до того, как можно открыть tunnel. S3 должен существовать до того, как workloads получат bucket credentials. Platform services должны быть готовы до установки application workloads. Public access должен работать до batch job и финальных проверок.
nodes: - name: fc-k8s-bootstrap - name: fc-k8s-tunnel needs: [fc-k8s-bootstrap] - name: aws-s3-bootstrap needs: [fc-k8s-tunnel] - name: platform-install needs: [aws-s3-bootstrap] - name: workloads-install needs: [platform-install] - name: replay-backfill needs: [argo-spark-batch] - name: verify-e2e needs: [replay-backfill]
Каждый node может отвечать за свой тип работы. Bootstrap nodes выполняют host commands. Platform node применяет Kubernetes resources и размечает ноды для control, events, processing, batch и analytics workloads. Workload node устанавливает Redpanda, Flink, Ray, Spark, Trino, Iceberg REST, payments API и jobs для регистрации схем. Batch и replay nodes отправляют Argo workflows. Final node это программа верификации, а не пункт в runbook.
Profiles выносят различия окружений из command text. Lab profile отвечает за Firecracker host, public IP checks, NodePort exposure и generated traffic. Stage или production profile может указывать на существующий kubeconfig, pinned images, real ingress и secret references. Граф остается читаемым, а operational inputs меняются через profile.
У replay node обычный и понятный контракт:
host.command.run: command: scripts/replay-backfill.sh apply deleteCommand: scripts/replay-backfill.sh delete timeout: 20m
Replay node читает payments.raw с начала, отправляет Spark backfill workflow, записывает новый Iceberg run id и спрашивает Trino, появились ли строки. Поэтому stack полезнее, чем директория с manifests. Deploy step и data proof находятся в одном графе.
Верификация
Финальная проверка сначала читает публичные endpoints: payments API, SigNoz, Ray, Spark, Flink и Trino. Затем она выполняется внутри кластера и считает raw и curated objects в S3, делает queries к ClickHouse по decision и batch rows, проверяет Redpanda schema subjects, делает Trino queries по ClickHouse и Iceberg, а затем читает sample risk message из Redpanda.
Результат проверки был таким:
s3_raw_objects=4365s3_curated_objects=11trino_payment_decisions=632iceberg_raw_payments=1100iceberg_risk_events=1100iceberg_batch_features=108risk_high_watermark=855backfill_run_id=replay-20260524130620iceberg_backfill_batch_features=36
Эти проверки и есть release evidence. Stack не просто устанавливает сервисы. Он проверяет, что данные вошли через API, дошли до Redpanda, были оценены через Flink и Ray, попали в ClickHouse, были пересчитаны через Spark, были закоммичены в Iceberg и читаются через Trino.
В этом разница между разворачиванием chart и разворачиванием platform.
ссылка на оригинал статьи https://habr.com/ru/articles/1038700/