KubeadaptDocsBack to site
Sign inStart free
DocsAPI ReferenceCLI
  • Introduction
  • Getting Started
  • Capabilities
    • How Kubeadapt works
    • Cost Monitoring
    • Cost Attribution
    • Optimization
    • Smart Alerting
    • Sustainability
    • Resource Efficiency
    • How costs are computed
Docs homev1ConceptsHow Kubeadapt Works

Core Concepts

How Kubeadapt works

The read-only data path from an in-cluster agent to your dashboard — what's collected, what isn't, and what runs where.


Before installing any monitoring tool, you want answers to two questions: "what does it touch in my cluster?" and "where does my data go?" This page answers both.

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 TLS with a per-cluster token.

The default interval is 60s, configurable via KUBEADAPT_SNAPSHOT_INTERVAL on the agent.

An optional eBPF agent runs as a DaemonSet on every node and captures pod-to-pod traffic for cross-AZ and egress cost visibility. See eBPF Agent.

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 network traffic content (the optional eBPF agent counts bytes between pods; it does not inspect them).
  • 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 and Azure, computed from your connected cloud account. GCP discount-program support (CUDs) is coming in June 2026.
  • 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. The dashboard can only ever read your own data, never write to it or cross into anyone else's.

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.

No third-party data sharing. No model training on your data.

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.
  • No third-party data sharing. Snapshot data stays inside Kubeadapt and is used only to serve you.

See also

  • Quick Start — install the agent in under five minutes.
  • How costs are computed — the math from instance price to workload cost.
  • Resource Efficiency — how we measure used vs requested.
  • eBPF Agent — optional network capture.

Related

  • Quick Start
  • How costs are computed
  • Configuration Overview
PreviousWhat Kubeadapt doesCapabilitiesNextCost monitoringCore Concepts

On this page

  • The data path
  • What runs in your cluster
  • What data leaves your cluster
  • What happens after the snapshot lands
  • Your data is yours
  • What Kubeadapt deliberately doesn't do
  • See also
Edit this page
Kubeadapt

Kubernetes FinOps platform. Cost visibility, rightsizing, and capacity planning that pays for itself in 30 days.

Product

  • Cost Monitoring
  • Cost Attribution
  • Workload Rightsizing
  • Recommendations
  • Smart Alerting
  • Best Practices
  • Network Cross-AZ

Resources

  • Documentation
  • Status Page
  • Feature Requests

Company

  • About Us
  • Security
  • Careers
  • Contact

© 2026 Kubeadapt. All rights reserved.

PrivacyTermsSecurity