A deep dive into how Kubernetes collects container, pod, and node metrics through kubelet, cAdvisor, and the Container Runtime Interface (CRI). Covers cgroup v1 vs v2 hierarchy differences, the systemd vs cgroupfs cgroup driver distinction, QoS-based cgroup placement, and how kubelet exposes metrics via /metrics/cadvisor, /stats/summary, and /metrics/resource endpoints. Demonstrates enabling PodAndContainerStatsFromCRI to shift metric collection from cAdvisor to the container runtime directly, with hands-on validation using crictl and kubectl. Also covers the KubeletCgroupDriverFromCRI GA feature in Kubernetes v1.34 and the deprecation of cgroup v1 in v1.35.
Table of contents
How Kubernetes Monitoring Layers Stack UpWhere Metrics Originatecgroup v1 with cgroupfs: The Legacy BaselineAt the crux of how cgroup hierarchy is shapedHow Kubernetes Creates and Manages the Cgroup HierarchyKubernetes QoS Classes and cgroup PlacementGet Gulcan Topcu ’s stories in your inboxAuto-Detecting cgroup Drivers via KubeletCgroupDriverFromCRIcAdvisor: Embedded Resource Monitoring in KubeletKubelet’s Metrics EndpointsFrom cAdvisor to CRI: How Kubelet Collects Metrics TodayValidating CRI-Based Metrics Collection in KubeletSummaryReferencesSort: