偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

為什么 Top node、Free、Grafana 的數(shù)據(jù)對(duì)不上,你知道嗎?

大數(shù)據(jù) 數(shù)據(jù)分析
對(duì)于 Pod 來說,通過 top 和 Grafana 看到的內(nèi)存使用量可能是相同的,因?yàn)椋蟛糠?Grafana 面板繪制 Pod 內(nèi)存使用量用的是 container_memory_working_set_bytes,這與 top 的計(jì)算方式是一致的。

1. top 節(jié)點(diǎn)資源使用率超過 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%

這是由于在計(jì)算使用率時(shí),默認(rèn)使用的是可分配的資源,排除了 Kubelet 保留的部分。在 kubectl 源碼中可以看到:

for _, n := range nodes {
  if !o.ShowCapacity {
    availableResources[n.Name] = n.Status.Allocatable
  } else {
    availableResources[n.Name] = n.Status.Capacity
  }
}

如果需要查看節(jié)點(diǎn)總的資源使用情況,可添加 --show-capacity 參數(shù):

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%

實(shí)際上 Allocatable 和 Capacity 在節(jié)點(diǎn)對(duì)象上可以直接看到:

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 或者啟動(dòng)命令參數(shù) --system-reserved=cpu=1,memory=2Gi --kube-reserved=cpu=1,memory=2Gi 可以查看具體的資源預(yù)留額度。詳情可以參考 https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/ 。

Allocatable = Capacity - Reserved - Evicted Threshold(驅(qū)逐容忍度),其中 Evicted Threshold 根據(jù)不同資源,通常為一個(gè)很小的數(shù)值或比例。

2. top node 與 Grafana 數(shù)據(jù)不一致

2.1 free 與 node_memory_Mem 同源

使用 free 查看節(jié)點(diǎn)資源使用情況如下:

free -h
              total        used        free      shared  buff/cache   available
Mem:          503Gi        62Gi       243Gi        12Gi       198Gi       426Gi
Swap:            0B          0B          0B

Grafana 節(jié)點(diǎn)資源使用情況如下:

圖片圖片

使用的 PromQL 為:

  • 總內(nèi)存, node_memory_MemTotal_bytes{instance=~\"$node\"}
  • 已用, node_memory_MemTotal_bytes{instance=~\"$node\"} - node_memory_MemAvailable_bytes{instance=~\"$node\"}

從數(shù)值上看,free 與 Grafana 數(shù)據(jù)基本一致。

因?yàn)?Grafana 使用的 Node Exporter 采集的 node_memory_Mem 這些指標(biāo)來自主機(jī)的 /proc/meminfo 與 free -h 的數(shù)據(jù)同源。

2.2 top 使用的是 metrics-server 采集的指標(biāo)

top 查看節(jié)點(diǎn)資源使用情況

kubectl top node my-node-name
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
my-node-name   4809m        8%     132883Mi        25%

模擬 top 命令向 metrics-server 請(qǐng)求數(shù)據(jù):

kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes/my-node-name

{
    "kind": "NodeMetrics",
    "window": "10.292s",
    "usage": {
        "cpu": "5094380203n",
        "memory": "136278224Ki"
    }
}

這里的內(nèi)存使用量約 130 Gi,130 / 503 = 25.8% 與 kubectl top node 基本一致。

2.3 metrics-server 的數(shù)據(jù)來自 Kubelet

從 metrics-server 的源碼可以看到,其在請(qǐng)求 Kubelet 的數(shù)據(jù)。

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 請(qǐng)求數(shù)據(jù)

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

符合預(yù)期,請(qǐng)求 metrics-server 與 Kubelet API 提供的監(jiān)控?cái)?shù)據(jù)相同。

2.4 node_memory_working_set_bytes 指標(biāo)有什么不同

  • top 使用的是 node_memory_working_set_bytes,是 Kubelet 提供的指標(biāo)

包括當(dāng)前正在使用的內(nèi)存,活躍的緩存,不包括可以被立即回收的緩存、緩沖區(qū),主要是非活躍的文件緩存,其數(shù)據(jù)來源于 /sys/fs/cgroup。

  • Grafana 使用的是 node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes,是 Node Exporter 提供的指標(biāo)

包括當(dāng)前正在使用的內(nèi)存,但不包括緩存,其數(shù)據(jù)來源于 /proc/meminfo。

前面可以看到 top 看到的內(nèi)存使用量大約為 130 Gi,而 Grafana 看到的內(nèi)存使用量大約是 77 Gi,相差 53 Gi 內(nèi)存存儲(chǔ)的就是一些不能立即被回收的緩存。但由于這兩種方式的數(shù)據(jù)源不同,無法對(duì) 53 Gi 進(jìn)行更詳細(xì)的分析。

2.5 Kubelet limit 使用的是 container_memory_working_set_bytes

對(duì)于 Pod 來說,通過 top 和 Grafana 看到的內(nèi)存使用量可能是相同的,因?yàn)?,大部?Grafana 面板繪制 Pod 內(nèi)存使用量用的是 container_memory_working_set_bytes,這與 top 的計(jì)算方式是一致的。

這里需要重點(diǎn)關(guān)注的是 Kubelet 會(huì)以哪個(gè)指標(biāo)驅(qū)逐 Pod? 答案是,container_memory_working_set_bytes 。

container_memory_working_set_bytes 更能代表容器的真實(shí)內(nèi)存使用量。

下面這張圖體現(xiàn)的是 container_memory_working_set_bytes (大約 18GiB) 與 container_memory_usage_bytes (大約 33GiB) 的區(qū)別。

圖片圖片

3. 總結(jié)

本文采集數(shù)據(jù)的主機(jī)內(nèi)核版本為 5.4.0-48-generic,主要內(nèi)容如下:

  • 因?yàn)?Kubelet 預(yù)留資源,top node 資源使用率可能超過 100%,使用 --show-capacity 可以看到總的資源使用情況
  • 常用的節(jié)點(diǎn)資源使用率(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)/ node_memory_MemTotal_bytes ,因?yàn)楹雎粤嘶钴S的緩存資源,所以使用率會(huì)比 top node 看到的低一些。上面例子大約是 Grafana 15% 使用率,top node 28% 的區(qū)別
  • Kubelet 對(duì) Pod 驅(qū)逐使用的是 container_memory_working_set_bytes,與 top pod 看到的內(nèi)存使用量相同
責(zé)任編輯:武曉燕 來源: 陳少文
相關(guān)推薦

2023-11-02 10:22:29

gRPC后端通信

2024-10-09 08:19:35

2020-11-17 08:30:06

LinuxSwapping 設(shè)計(jì)

2025-06-05 01:11:00

2023-12-20 08:23:53

NIO組件非阻塞

2024-04-30 09:02:48

2024-10-12 14:58:07

2025-07-01 06:27:55

2025-04-27 09:04:08

2024-10-10 16:53:53

守護(hù)線程編程

2024-04-07 00:00:03

2024-08-20 08:29:55

2024-11-08 09:48:38

異步編程I/O密集

2024-07-30 08:22:47

API前端網(wǎng)關(guān)

2024-04-07 00:02:00

2019-12-20 10:24:34

數(shù)據(jù)中臺(tái)大數(shù)據(jù)

2023-12-12 08:41:01

2025-02-18 08:11:17

2022-11-28 00:04:17

2024-01-15 12:16:37

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)