為什么 Top node、Free、Grafana 的數據對不上，你知道嗎？
1. top 節點資源使用率超過 100%
kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master-1 995m 16% 13760Mi 118%
master-2 827m 13% 10672Mi 92%
master-3 889m 14% 10244Mi 88%這是由于在計算使用率時，默認使用的是可分配的資源，排除了 Kubelet 保留的部分。在 kubectl 源碼中可以看到:
for _, n := range nodes {
if !o.ShowCapacity {
availableResources[n.Name] = n.Status.Allocatable
} else {
availableResources[n.Name] = n.Status.Capacity
}
}如果需要查看節點總的資源使用情況，可添加 --show-capacity 參數:
kubectl top node --show-capacity
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master-1 1161m 14% 13822Mi 87%
master-2 998m 12% 10640Mi 67%
master-3 877m 10% 10298Mi 65%實際上 Allocatable 和 Capacity 在節點對象上可以直接看到:
kubectl get node master-1 -oyaml
...
status:
allocatable:
cpu: "6"
ephemeral-storage: "284333649859"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 11877928Ki
pods: "110"
capacity:
cpu: "8"
ephemeral-storage: 308521756Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 16174632Ki
pods: "110"在 Kubelet 的配置文件 /var/lib/kubelet/config.yaml 或者啟動命令參數 --system-reserved=cpu=1,memory=2Gi --kube-reserved=cpu=1,memory=2Gi 可以查看具體的資源預留額度。詳情可以參考 https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/ 。
Allocatable = Capacity - Reserved - Evicted Threshold(驅逐容忍度)，其中 Evicted Threshold 根據不同資源，通常為一個很小的數值或比例。
2. top node 與 Grafana 數據不一致
2.1 free 與 node_memory_Mem 同源
使用 free 查看節點資源使用情況如下:
free -h
total used free shared buff/cache available
Mem: 503Gi 62Gi 243Gi 12Gi 198Gi 426Gi
Swap: 0B 0B 0BGrafana 節點資源使用情況如下:
圖片
使用的 PromQL 為:
- 總內存, node_memory_MemTotal_bytes{instance=~\"$node\"}
- 已用, node_memory_MemTotal_bytes{instance=~\"$node\"} - node_memory_MemAvailable_bytes{instance=~\"$node\"}
從數值上看，free 與 Grafana 數據基本一致。
因為 Grafana 使用的 Node Exporter 采集的 node_memory_Mem 這些指標來自主機的 /proc/meminfo 與 free -h 的數據同源。
2.2 top 使用的是 metrics-server 采集的指標
top 查看節點資源使用情況
kubectl top node my-node-name
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
my-node-name 4809m 8% 132883Mi 25%模擬 top 命令向 metrics-server 請求數據:
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes/my-node-name
{
"kind": "NodeMetrics",
"window": "10.292s",
"usage": {
"cpu": "5094380203n",
"memory": "136278224Ki"
}
}這里的內存使用量約 130 Gi，130 / 503 = 25.8% 與 kubectl top node 基本一致。
2.3 metrics-server 的數據來自 Kubelet
從 metrics-server 的源碼可以看到，其在請求 Kubelet 的數據。
func (kc *kubeletClient) GetMetrics(ctx context.Context, node *corev1.Node) (*storage.MetricsBatch, error) {
port := kc.defaultPort
path := "/metrics/resource"
nodeStatusPort := int(node.Status.DaemonEndpoints.KubeletEndpoint.Port)
if kc.useNodeStatusPort && nodeStatusPort != 0 {
port = nodeStatusPort
}
if metricsPath := node.Annotations[AnnotationResourceMetricsPath]; metricsPath != "" {
path = metricsPath
}
addr, err := kc.addrResolver.NodeAddress(node)
if err != nil {
return nil, err
}
url := url.URL{
Scheme: kc.scheme,
Host: net.JoinHostPort(addr, strconv.Itoa(port)),
Path: path,
}
return kc.getMetrics(ctx, url.String(), node.Name)
}模擬 metrics-server 向 Kubelet 請求數據
kubectl get --raw /api/v1/nodes/my-node-name/proxy/metrics/resource |grep node_
# HELP node_cpu_usage_seconds_total [ALPHA] Cumulative cpu time consumed by the node in core-seconds
# TYPE node_cpu_usage_seconds_total counter
node_cpu_usage_seconds_total 1.2683530100816046e+08 1721957059813
# HELP node_memory_working_set_bytes [ALPHA] Current working set of the node in bytes
# TYPE node_memory_working_set_bytes gauge
node_memory_working_set_bytes 1.39524251648e+11 1721957059813符合預期，請求 metrics-server 與 Kubelet API 提供的監控數據相同。
2.4 node_memory_working_set_bytes 指標有什么不同
- top 使用的是 node_memory_working_set_bytes，是 Kubelet 提供的指標
包括當前正在使用的內存，活躍的緩存，不包括可以被立即回收的緩存、緩沖區，主要是非活躍的文件緩存，其數據來源于 /sys/fs/cgroup。
- Grafana 使用的是 node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes，是 Node Exporter 提供的指標
包括當前正在使用的內存，但不包括緩存，其數據來源于 /proc/meminfo。
前面可以看到 top 看到的內存使用量大約為 130 Gi，而 Grafana 看到的內存使用量大約是 77 Gi，相差 53 Gi 內存存儲的就是一些不能立即被回收的緩存。但由于這兩種方式的數據源不同，無法對 53 Gi 進行更詳細的分析。
2.5 Kubelet limit 使用的是 container_memory_working_set_bytes
對于 Pod 來說，通過 top 和 Grafana 看到的內存使用量可能是相同的，因為，大部分 Grafana 面板繪制 Pod 內存使用量用的是 container_memory_working_set_bytes，這與 top 的計算方式是一致的。
這里需要重點關注的是 Kubelet 會以哪個指標驅逐 Pod? 答案是，container_memory_working_set_bytes 。
container_memory_working_set_bytes 更能代表容器的真實內存使用量。
下面這張圖體現的是 container_memory_working_set_bytes (大約 18GiB) 與 container_memory_usage_bytes (大約 33GiB) 的區別。
圖片
3. 總結
本文采集數據的主機內核版本為 5.4.0-48-generic，主要內容如下:
- 因為 Kubelet 預留資源，top node 資源使用率可能超過 100%，使用 --show-capacity 可以看到總的資源使用情況
- 常用的節點資源使用率(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)/ node_memory_MemTotal_bytes ，因為忽略了活躍的緩存資源，所以使用率會比 top node 看到的低一些。上面例子大約是 Grafana 15% 使用率，top node 28% 的區別
- Kubelet 對 Pod 驅逐使用的是 container_memory_working_set_bytes，與 top pod 看到的內存使用量相同
