Skip to content

Kubernetes platform notes

How the agent runs on Kubernetes. For installation, see the Kubernetes installation guide. For the shared model, see Architecture.

On Kubernetes, a whole cluster appears in KloudMate as one agent, not one per node. It runs as a few pods:

  • Fleet manager: a single pod that applies your configuration to the cluster and reports each collector’s status back to KloudMate.
  • Collector pods: a DaemonSet (one per node) collects per-node metrics and pod logs and, where the kernel supports it, runs eBPF monitoring — the network topology map and metrics, plus application traces for any workload you set to eBPF mode (see Application APM on Kubernetes). A Deployment (a single replica) collects cluster metrics and events and acts as the OpenTelemetry (OTel) gateway.

The Kubernetes view shows real per-node collector health. If a collector pod goes down, its node’s status reflects that, so you can see exactly which node is affected.

Self-logs are shipped per node, from both the collector pods and the fleet manager, so you can see errors such as an invalid configuration without running kubectl logs. See Agent self-logs.

The collectors read their configuration from ConfigMaps that the agent manages.

Typical usage per component (CPU in millicores, where 1000m is one core):

ComponentRunsCPUMemory
Collector (DaemonSet)one per node3 to 10m165 to 210 MiB
Collector (Deployment)one per cluster12 to 16mabout 256 MiB
Fleet managerone per cluster1 to 2mabout 11 MiB
Operatorone per clusterabout 2mabout 30 MiB

Memory grows with the volume of metrics, traces, and logs the collectors handle. CPU stays low.

The Helm chart ships these defaults, set above typical usage so there is headroom for real load:

ComponentRequestLimit
Collector (DaemonSet)100m / 256Mi2 CPU / 1Gi
Collector (Deployment)150m / 384Mi2 CPU / 1Gi
Fleet manager100m / 128Mi500m / 512Mi

Raise them for very large or high-traffic clusters.