The problem with Kubernetes monitoring is rarely too little data. It is too much, arriving all at once, before anyone has agreed what "healthy" means. Start by narrowing the question.
Start with pressure, not counters
The metrics that predict pain are about pressure: pods that cannot schedule, containers being throttled against their limits, nodes running short on memory. Raw counters are interesting later. Pressure is what wakes you up.
Requests and limits are the plot
Most container trouble traces back to requests and limits that no longer match reality. Watching actual usage against those declared values tells you where the cluster is lying to itself, and where the next incident is being quietly set up.
- Track scheduling failures and restarts before raw CPU graphs.
- Compare real usage to requests and limits, per workload.
- Roll container views up to the node and cluster you actually operate.
A cluster is not a special snowflake once you frame it this way. It is capacity, pressure and a set of promises about resources, and those are things you already know how to monitor.
