Skip to content
Start free

Core Concepts

How Kubeadapt works

The data path from the in-cluster Kubeadapt agent to your dashboard: what is collected, what the agent can access, and where data goes.

This page answers two questions: what Kubeadapt touches in your cluster, and where your data goes.

The data path

plaintext
1Browser  ←  app.kubeadapt.io
2                  │ HTTPS
3                  ▼
4            Kubeadapt Cloud
5            Receives, processes, stores, and serves your
6            cluster snapshots. The dashboard is read-only.
7                  ▲ HTTPS
8                  │ Cluster snapshot every 60s
9                  │
10              Your cluster
11              kubeadapt-agent (single pod) +
12              optional eBPF agent (DaemonSet)

The flow is always cluster → Kubeadapt. Kubeadapt never opens an outbound connection from its cloud back into your cluster.

What runs in your cluster

A single-pod agent runs in the namespace you chose at install time (typically kubeadapt). It uses the in-cluster Kubernetes service account and the standard kubelet metrics endpoints. No operator CRDs. No mutating webhooks. No proxy.

Every 60 seconds the agent:

  1. Reads pod, container, node, namespace, and workload-controller metadata from the Kubernetes API.
  2. Pulls per-container CPU, memory, and GPU usage from the kubelet and metrics-server.
  3. Captures requests, limits, and node capacity across the cluster.
  4. Sends the snapshot to Kubeadapt over HTTPS, authenticated with a per-cluster token.

The default interval is 60s, set with agent.config.snapshotInterval in your Helm values.

An optional eBPF agent runs as a DaemonSet on every node and measures traffic between workloads for cross-zone and egress cost visibility. See eBPF Agent.

What the agent can access

  • Cluster-wide, a ClusterRole grants list and watch on the resources it reads (nodes, namespaces, pods, workload controllers, volumes, autoscalers and similar), plus get on the kubelet stats endpoints.
  • In its own namespace, a Role grants get, list, create and delete on Jobs, get, list, create, update and delete on ConfigMaps, and get and list on Secrets.
  • The optional auto-upgrader, off by default, manages the Helm release Secrets and Kubeadapt's own resources in its namespace.
  • The optional eBPF agent, off by default, runs as a privileged pod (privileged: true) with hostNetwork and hostPID.

What data leaves your cluster

The snapshot payload covers everything we need to compute cost and surface optimization opportunities:

  • Pod, container, node, namespace, and workload-controller metadata (names, labels, annotations, controller kinds).
  • Per-container CPU, memory, and GPU usage, requests, and limits.
  • Per-node instance type, region/AZ, and capacity.
  • Persistent volume size, storage class, and CSI driver.
  • A handful of cluster-level fields (Kubernetes version, agent version, cluster region).

What does not leave:

  • Secret values, ConfigMap contents, or any application payload.
  • Application payloads and bodies. The optional eBPF agent records connection metadata (addresses, ports, byte counts) and, for cost attribution, reads protocol headers: HTTP method, route and status, DNS query names, and the TLS server name. It never stores request or response bodies.
  • PersistentVolume contents.

What happens after the snapshot lands

Once a snapshot reaches Kubeadapt, it joins pricing data that Kubeadapt maintains separately from your cluster:

  • On-demand instance prices for every supported instance type across all regions of AWS, Azure, and GCP.
  • Spot / preemptible prices for every instance type and availability zone.
  • Reserved Instance and Savings Plan rates for AWS, from your connected AWS account. Azure reservations and GCP committed-use discounts are not reflected yet.
  • Persistent volume rates per storage class — AWS EBS, GCP PD, Azure Disk.
  • Regional grid carbon intensity for CO₂ accounting.

All current cloud prices are kept up to date by Kubeadapt, so your cost numbers update with the market and your cluster never has to call a cloud provider's pricing API.

For the actual cost math — how a workload's spend is derived from these inputs — see How costs are computed.

Your data is yours

Every cluster snapshot you send is scoped to your organization. Kubeadapt runs in the EU (Germany) and stores your cluster data there.

Kubeadapt uses your snapshot data only to:

  1. Serve your dashboards.
  2. Generate optimization recommendations for your workloads.
  3. Power the alerts you've enabled.

To write a Kubeadapt AI summary of an alert or explain a recommendation, Kubeadapt sends a language model provider the data for that one alert or workload: names (cluster, namespace, workload and containers), CPU and memory requests and usage statistics such as percentiles, replica and restart counts, and cost figures.

What Kubeadapt deliberately doesn't do

  • No OpenTelemetry receiver. Kubeadapt doesn't accept OTLP traces or metrics. The in-cluster agent is the only data source.
  • No cloud-bill access. Kubeadapt doesn't pull your CUR (AWS), Billing Export (GCP), or Cost Management exports (Azure). Cost numbers are computed bottom-up from instance pricing × actual usage, not reconciled against the invoice.
  • No outbound connections to your cluster. Helm install, agent restart, even uninstall — everything happens through your local kubectl.

See also

Related