Core Concepts

This page introduces the ideas Tantilium Cloud Runner (TCR) is built on and the vocabulary used throughout the documentation. The rest of the docs assume you know these terms.

Why Tantilium Cloud Runner exists

Running Kubernetes well usually means assembling and maintaining a toolchain: a provisioning tool, a GitOps controller, a metrics stack, a log stack, a tracing stack, a cost tool, a security scanner, an incident tool, and a lot of glue. Each works; together they are a second system to operate.

TCR is built on Kubernetes' own primitives and on proven open-source tools such as Flux, Prometheus, Loki, Jaeger, Karpenter and vCluster, and wires them into one platform with one data model, one API and one UI. On top of that foundation it adds an AI layer that can reason about everything the platform sees.

Design principles

Event-driven by default

Services talk to each other through RabbitMQ topic exchanges. When telemetry is collected, the services that care about it receive it immediately and act. There is no polling between services and no central coordinator. New capabilities are added by subscribing to existing events, without changing the services that publish them.

Autonomous, with humans in control

TCR can restart pods, cordon nodes and scale workloads on its own. Every automated action is governed by an approval rule (AutoApprove), logged with its reason, and measured afterwards. You decide which actions run automatically and which wait for a person to approve them.

A closed loop, not a one-way pipe

Detection → decision → action → feedback. After every automated action TCR checks whether cluster health actually improved, and feeds that result back into detection. Over time each cluster gets thresholds tuned to its own behaviour: fewer false alarms where actions don't help, faster alerts where they do.

AI as a first-class operator

Reasoning agents built on Claude use live, typed tools to inspect clusters, correlate signals and propose action, or take it when permitted. They can be launched by a person, by another service, or automatically when risk rises.

Transparent AI

Every step an agent takes, from its reasoning to each tool call and its result, is streamed to the UI as it happens and stored for later review.

Declarative and GitOps-native

Applications, tenants and clusters are described as Kubernetes custom resources and reconciled by controllers. Application manifests land in Git and are delivered by Flux, so every change is reviewable, auditable and revertible.

Building blocks

Concept	What it is
Host cluster	A Kubernetes cluster that TCR manages. It runs tenant virtual clusters and application workloads.
Management plane	The TCR services themselves (APIs, controllers, agents), running in the kubeopera-* namespaces.
Tenant	An organization or team using TCR. Each tenant is isolated from the others.
CloudSpace / vCluster	A tenant's own virtual Kubernetes cluster, running inside a host cluster, with its own API server and quotas.
KubeOperaApp	The custom resource that describes an application. The app-controller turns it into manifests in Git that Flux deploys.
Telemetry snapshot	A point-in-time record of a cluster's health, resource usage and failures, collected every 30 seconds.
Decision	A proposed remediation (scale, restart, cordon, notify) produced by analysis, with an approval rule.
Feedback signal	The measured outcome of an action, reinforcement if it helped and correction if it didn't, used to tune detection.
Agent run	One session of a reasoning agent working on a goal, with its full reasoning and tool-call history.
Recommendation	A structured, prioritized suggestion (cost, reliability, security, performance) generated by AI.

Key capabilities

TCR's foundation is multi-cluster management: provisioning, registering and operating clusters across AWS, GCP and on-premises from one UI. On top of it, multi-tenancy gives each tenant isolated virtual clusters with quotas and RBAC, and application delivery generates manifests from a schema and deploys them through GitOps, from source or from an image.

To keep those workloads healthy, observability correlates health scores, metrics, logs, traces, SLOs and APM per workload. Anomaly detection watches it with statistical checks over rolling windows and adaptive, per-cluster thresholds, and self-healing responds with automated restarts, cordons and scale-outs, each measured for effect. Predictive scaling looks ahead, forecasting load with confidence bands and offering one-click scaling approvals.

The remaining areas cover the business side of running a platform: cost intelligence (real-time cost per namespace and workload, forecasts and right-sizing), security posture (continuous scanning, RBAC analysis and compliance scoring) and incident management (correlated incidents, runbooks, notifications and reliability metrics). Running through all of them is agentic AI: reasoning agents with live tools, streamed as they work and fully audited.

Technology stack

Layer	Technology	Why
Dashboard	Next.js, TypeScript, Tailwind CSS	Server components, streaming UI, a server-side proxy for every backend call.
Services	Go, hexagonal architecture	Fast, small, single-binary services with clear boundaries.
Messaging	RabbitMQ topic exchanges	Fan-out without coupling producers to consumers.
Storage	PostgreSQL, Redis	Durable state and fast caching.
AI	Claude via the Anthropic Go SDK	Tool use, streaming and extended thinking.
Forecasting	Holt-Winters, implemented in Go	Accurate short-term forecasts with no ML framework dependencies.
Delivery	Flux v2 via controller-runtime	Declarative, Kubernetes-native reconciliation.
Tenancy	vCluster	Strong isolation without a cluster per team.
Nodes	Karpenter	Fast, cost-aware node provisioning, including spot capacity.

Next steps

• Architecture: see how the layers and services fit together.
• Components: a tour of every major component and what it is responsible for.
• AI Agents: how the autonomous loop and reasoning agents work.