Where Titansama actually sits in your cluster
One read-only collector, deployed in its own namespace. It calls the Kubernetes API and collects real-time metrics across the control plane and every node — it doesn't sit in your request path, and it can't mutate anything unless you grant it that scope explicitly.
kube-apiserver
Front door for all cluster state
etcd
Cluster state store
scheduler
Places pods on nodes
controller-manager
Reconciles desired state
kubelet
Runs pods on this node
kube-proxy
Handles service networking
container runtime
containerd / CRI-O
titansama-collector
Calls the API, collects real-time metrics
Built by people who page themselves
No black box. Here's the actual shape of what runs in your cluster, what it costs in resources, and how the pieces talk to each other.
$ kubectl apply -f titansama-collector.yaml namespace/titansama-system created serviceaccount/titansama-collector created clusterrole.rbac.authorization.k8s.io/titansama-ro created deployment.apps/titansama-collector created $ titansama status connecting to control plane... ok discovering nodes... 42 found discovering namespaces... 17 found baseline established in 2m 14s # fleet.titansama.io/prod-east is now live
apiVersion: apps/v1 kind: Deployment metadata: name: titansama-collector namespace: titansama-system spec: replicas: 1 template: spec: containers: - name: collector resources: requests: memory: "96Mi" cpu: "100m" env: - name: MODE value: "read-only"
How data moves
Collector
Calls the Kubernetes API and collects real-time metrics. Nothing leaves the cluster unbatched or unencrypted.
Correlation engine
Joins metrics, logs, and events into a single timeline per workload.
Agent layer
Runs triage and cost-analysis agents against the correlated timeline.
Slack / PagerDuty / webhook
Findings and approval-gated actions land where your team already works.
Integrates with what you already run
Stop reading dashboards.
Start reading conclusions.
Titansama is in guided rollout with a limited set of platform teams.