Lexicon
Kubernetes monitoring
Kubernetes monitoring covers clusters, nodes, workloads, pods, and the apps inside them. How the layers fit together and where cardinality bites hardest.
Definition
Kubernetes monitoring is observability applied to Kubernetes clusters: the nodes, workloads, pods, and containers that run modern applications, plus the control plane that orchestrates them. It spans several layers at once, because in Kubernetes a single symptom can originate in any of them.
What it means in observability
Kubernetes is the dominant runtime for cloud native software, and it complicates observability in exactly the ways it simplifies operations. Workloads move, pods are replaced constantly, and the mapping between an application problem and the node underneath it changes by the minute. Good Kubernetes monitoring keeps the layers connected: cluster capacity, node health, workload state, pod lifecycle, container resource usage, and the application telemetry emitted from inside, all navigable as one picture rather than five.
How it works in practice
Collection typically runs an OpenTelemetry Collector as a DaemonSet on every node, gathering container and node metrics from the kubelet, plus cluster level receivers watching workload state and Kubernetes events. The connective tissue is metadata: Kubernetes resource attributes for namespace, workload, pod, and container, stamped onto application telemetry per the semantic conventions, which is what lets you pivot from a slow service to the pod it ran in to the node that was struggling.
Where it gets hard
Pod churn is a cardinality engine, since every replacement pod mints new attribute values, and platforms priced per series or per host turn that churn into invoice growth. Multi cluster estates multiply everything, including the question of where the monitoring itself should live. And the layer hopping is where tools fail in practice: if application, workload, and node views do not share metadata, engineers become the join layer during incidents.
Where Tsuga fits
Tsuga provides Kubernetes inventory across clusters, workloads, and pods, connected to application telemetry through standard OpenTelemetry metadata. Per GB pricing makes pod churn economically boring, and the platform runs inside your own cloud account, right beside the clusters it observes.
Related terms
- CardinalityCardinality is the number of distinct values, or distinct value combinations, that an attribute or set of attributes can take.
- eBPFeBPF is a Linux kernel technology that runs small, verified programs inside the kernel itself, attached to events like system calls, network packets, and scheduler activity.
- Infrastructure monitoringInfrastructure monitoring is the practice of tracking the health, performance, and capacity of the layer applications run on: hosts, virtual machines, containers, Kubernetes clusters, and managed cloud services.
- OpenTelemetry CollectorThe OpenTelemetry Collector is a standalone process that receives telemetry from applications and infrastructure, transforms it, and exports it to one or more destinations.
- Semantic conventionsSemantic conventions are OpenTelemetry's standard vocabulary: the agreed names, types, and values for the attributes that describe telemetry.