为什么GKE节点在没有豆荚的情况下一开始就有这么高的负载平均值？
我们有一个带有3个节点的GKE云(2个节点n1-s1和其他一个n1-s2)，让我们调用它们(A、B和C)，在昨天运行versión "v1.14.10-gke.27“之后，我们开始挖掘问题的原因，并在虚拟机节点(A)和(B)中发现了一个高负载平均值.(C)是为移动DB吊舱而创建的。
嗯，在我们的检查(kubectl顶部节点)和(kubectl -n MYNAMESPACE顶部吊舱)中，我们发现节点中使用的CPU /内存是60%的CPU和70%的内存。
好的，我们做了这个测试。我们耗尽节点A并重新启动虚拟机。通过这样做：
kubectl drain --ignore-daemonsets
gcloud compute ssh A
sudo reboot在重新启动虚拟机节点(A)并等待大约15分钟后，我们再次连接，并看到以下内容：
gcloud compute ssh A
top显示平均负载约为1.0 (0.9 - 1.2) .但是这台机器(一个核心和3.5GB内存)里面没有POD。我检查了机器大约30分钟，GKE的核心linux系统总是在1.0附近的平均负载
为什么？
然后我又查了一遍。在节点(B)中，只有一个SFTP服务器(CPU使用量约为3 millis)。我做了同样的测试：
gcloud compute ssh B
top这就是所显示的：
top - 19:02:48 up 45 days, 4:40, 1 user, load average: 1.00, 1.04, 1.09
Tasks: 130 total, 1 running, 129 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.4 us, 1.3 sy, 0.0 ni, 95.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3697.9 total, 1383.6 free, 626.3 used, 1688.1 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2840.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1065 root 20 0 924936 117608 66164 S 1.7 3.1 1356:05 kubelet
1932 root 20 0 768776 82748 11676 S 1.0 2.2 382:32.65 ruby
1008 root 20 0 806080 90408 26644 S 0.7 2.4 818:40.25 dockerd
183 root 20 0 0 0 0 S 0.3 0.0 0:26.09 jbd2/sda1-8
1 root 20 0 164932 7212 4904 S 0.0 0.2 17:47.38 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.09 kthreadd
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq但是：
kubectl -n MYNAMESPACE top pods | grep sftp
sftp-7d7f58cd96-fw6tm 1m 11MiCPU占用仅1m，RAM 11 1m。
为什么这么高的负荷平均值？
我对此很担心，所以这个平均负载可能会影响集群节点中吊舱的性能。
另一方面，我在office安装了一个带有Debian VM节点的测试自kubernetes集群，并安装了一个节点(2核4 GB内存)，但是运行Zammad和Jira的PODs显示了这个负载平均值: OFFICE KUBERNETES CLOUD。
ssh user@node02
top
top - 21:11:29 up 17 days, 6:04, 1 user, load average: 0,21, 0,37, 0,21
Tasks: 161 total, 2 running, 159 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2,4 us, 1,0 sy, 0,0 ni, 96,3 id, 0,3 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 3946,8 total, 213,4 free, 3249,4 used, 483,9 buff/cache
MiB Swap: 0,0 total, 0,0 free, 0,0 used. 418,9 avail Mem在办公室的节点，负荷平均，运行舱大约是0.21-0.4 .这是更现实的，类似于它是什么。
另一个问题是，当我通过ssh连接到GKE节点(A、B或C)时，没有像iostat这样的监视硬驱动程序/存储的工具，所以我不知道为什么基本的KDE节点具有如此高的平均负载，没有安排吊舱计划。
今天，在关键时刻，这是GKE云状态：
kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-n1-s1-A 241m 25% 1149Mi 43%
gke-n1-s1-B 81m 8% 1261Mi 47%
gke-n1-s2-C 411m 21% 1609Mi 28%但是节点B中的一个顶部显示
top - 11:20:46 up 45 days, 20:58, 1 user, load average: 1.66, 1.25, 1.13
Tasks: 128 total, 1 running, 127 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.0 us, 2.3 sy, 0.0 ni, 91.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3697.9 total, 1367.8 free, 629.6 used, 1700.6 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2837.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1065 root 20 0 924936 117608 66164 S 3.3 3.1 1376:27 kubelet
1008 root 20 0 806080 90228 26644 S 1.3 2.4 829:21.65 dockerd
2590758 root 20 0 136340 29056 20908 S 0.7 0.8 18:38.56 kube-dns
443 root 20 0 36200 19736 5808 S 0.3 0.5 3:51.49 google_accounts
1932 root 20 0 764164 82748 11676 S 0.3 2.2 387:52.03 ruby
1 root 20 0 164932 7212 4904 S 0.0 0.2 18:03.44 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.09 kthreadd
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.0 0.0 14:55.03 ksoftirqd/0编辑1:最后一次测试：
1.-创建一个具有1个节点的池
gcloud container node-pools create testpool --cluster MYCLUSTER --num-nodes=1 --machine-type=n1-standard-1
NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION
testpool n1-standard-1 100 1.14.10-gke.362.-释放节点并检查节点状态
kubectl drain --ignore-daemonsets gke-MYCLUSTER-testpool-a84f3036-16lr
kubectl get nodes
gke-MYCLUSTER-testpool-a84f3036-16lr Ready,SchedulingDisabled <none> 2m3s v1.14.10-gke.363.-重新启动机器，等待和顶部
gcloud compute ssh gke-MYCLUSTER-testpool-a84f3036-16lr
sudo reboot
gcloud compute ssh gke-MYCLUSTER-testpool-a84f3036-16lr
top
top - 11:46:34 up 3 min, 1 user, load average: 1.24, 0.98, 0.44
Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.1 us, 1.0 sy, 0.0 ni, 95.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3697.9 total, 2071.3 free, 492.8 used, 1133.9 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2964.2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1066 root 20 0 895804 99900 65136 S 2.1 2.6 0:04.28 kubelet
1786 root 20 0 417288 74176 11660 S 2.1 2.0 0:03.13 ruby
1009 root 20 0 812868 97168 26456 S 1.0 2.6 0:09.17 dockerd
1 root 20 0 99184 6960 4920 S 0.0 0.2 0:02.25 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
5 root 20 0 0 0 0 I 0.0 0.0 0:00.43 kworker/u2:0
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.0 0.0 0:00.08 ksoftirqd/0
8 root 20 0 0 0 0 I 0.0 0.0 0:00.20 rcu_sched
9 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh
10 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
11 root rt 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
14 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
17 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback1.24平均负荷无角果荚？
编辑2谢谢@。我试着使用“工具箱”，运行“顶层”和"iotop“命令。我没有看到任何异常，但平均负荷是(1-1.2)。如您所见，CPU“什么也不做”，IO操作几乎为零。以下是研究结果：
iotop
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd noresume noswap cros_efi
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
2591747 be/4 nobody 0.00 B/s 0.00 B/s 0.00 % 0.00 % monitor --source=kube-proxy:http://local~ng.googleapis.com/ --export-interval=120s
4 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
3399685 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sudo systemd-nspawn --directory=/var/lib~/resolv.conf:/etc/resolv.conf --user=root
6 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [mm_percpu_wq]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
10 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
11 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
12 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/0]
13 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kdevtmpfs]
14 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [netns]
15 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khungtaskd]
16 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [oom_reaper]
17 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [writeback]
18 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kcompactd0]
19 be/7 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khugepaged]
20 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [crypto]
21 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kintegrityd]
22 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kblockd]
23 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ata_sff]
24 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdogd]
2590745 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % containerd-shim -namespace moby -workdir~runtime-root /var/run/docker/runtime-runc
atop
PRC | sys 14h12m | user 41h11m | #proc 140 | #trun 1 | #tslpi 544 | #tslpu 1 | #zombie 0 | clones 118e5 | #exit 0 |
CPU | sys 2% | user 5% | irq 0% | idle 93% | wait 0% | steal 0% | guest 0% | curf 2.30GHz | curscal ?% |
CPL | avg1 1.17 | avg5 1.17 | avg15 1.17 | | csw 669768e4 | | intr 26835e5 | | numcpu 1 |
MEM | tot 3.6G | free 221.1M | cache 2.1G | buff 285.2M | slab 313.3M | shmem 2.2M | vmbal 0.0M | hptot 0.0M | hpuse 0.0M |
SWP | tot 0.0M | free 0.0M | | | | | | vmcom 6.4G | vmlim 1.8G |
PAG | scan 54250 | steal 37777 | stall 0 | | | | | swin 0 | swout 0 |
LVM | dm-0 | busy 0% | read 6747 | write 0 | KiB/r 36 | KiB/w 0 | MBr/s 0.0 | MBw/s 0.0 | avio 2.00 ms |
DSK | sda | busy 0% | read 19322 | write 5095e3 | KiB/r 37 | KiB/w 8 | MBr/s 0.0 | MBw/s 0.0 | avio 0.75 ms |
DSK | sdc | busy 0% | read 225 | write 325 | KiB/r 24 | KiB/w 13315 | MBr/s 0.0 | MBw/s 0.0 | avio 1.75 ms |
DSK | sdb | busy 0% | read 206 | write 514 | KiB/r 26 | KiB/w 10 | MBr/s 0.0 | MBw/s 0.0 | avio 0.93 ms |
NET | transport | tcpi 69466e3 | tcpo 68262e3 | udpi 135509 | udpo 135593 | tcpao 4116e3 | tcppo 2797e3 | tcprs 738077 | udpie 0 |
NET | network | ipi 222967e3 | ipo 216603e3 | ipfrw 1533e5 | deliv 6968e4 | | | icmpi 74445 | icmpo 6254 |
NET | vethf6a 0% | pcki 40168e3 | pcko 39391e3 | sp 10 Gbps | si 15 Kbps | so 43 Kbps | erri 0 | erro 0 | drpo 0 |
NET | veth046 0% | pcki 8800433 | pcko 9133058 | sp 10 Gbps | si 2 Kbps | so 4 Kbps | erri 0 | erro 0 | drpo 0 |
NET | vethe89 0% | pcki 10923 | pcko 23560 | sp 10 Gbps | si 0 Kbps | so 0 Kbps | erri 0 | erro 0 | drpo 0 |
NET | veth647 0% | pcki 2583709 | pcko 2845889 | sp 10 Gbps | si 0 Kbps | so 0 Kbps | erri 0 | erro 0 | drpo 0 |
NET | veth6be 0% | pcki 374054 | pcko 448480 | sp 10 Gbps | si 0 Kbps | so 0 Kbps | erri 0 | erro 0 | drpo 0 |
NET | eth0 ---- | pcki 12094e4 | pcko 11533e4 | sp 0 Mbps | si 103 Kbps | so 56 Kbps | erri 0 | erro 0 | drpo 0 |
NET | cbr0 ---- | pcki 98061e3 | pcko 92356e3 | sp 0 Mbps | si 36 Kbps | so 71 Kbps | erri 0 | erro 0 | drpo 0 |
NET | lo ---- | pcki 9076898 | pcko 9076898 | sp 0 Mbps | si 5 Kbps | so 5 Kbps | erri 0 | erro 0 | drpo 0 |
*** system and process activity since boot ***有人能帮我吗？
我能做些什么？
这种行为在没有豆荚的GKE节点中是否正常？
我应该换另一家Kubernetes供应商吗？
提前谢谢。
回答 1
Stack Overflow用户
发布于 2020-06-12 07:10:34
在将消息与google支持交叉后，这似乎是google稳定发布版本的一个问题。
最新的官方稳定版本是v1.14.10-gke.36。
从1.14.10-gke.27版本开始，我们就检查了糟糕的负载性能(我们不会更早地进行)。
我们正在等待谷歌产品工程师对此的回应。我们检查了今天可用的最后一个版本"1.16.9-gke.2"，负载平均值在空闲时间是正常的，大约是0.15和更低，但这不是一个“稳定”的版本。
如果使用gcloud命令创建集群，它将给出最后一个“稳定”(v1.14.10-gke.36)，因此使用"v1.14.10-gke.X“的每个人都会遇到这个问题。
解决办法是..。
( a)等待谷歌产品工程师的正式回应。
( b)移动/更新到其他版本的集群/节点(可能不稳定)。
编辑2020/06/24。谷歌的回应
1-我已经将你的反馈通知了我们的GKE产品工程团队，他们能够在gke版本1.14.10-gke-36中复制这个问题，在cos和cos_containerd中，但是平均负载ubuntu和ubuntu_containerd有较低的平均负载。因此，我们的GKE产品工程师建议快速解决方法，将集群和节点池升级到1.15。对于永久修复，我们的GKE产品团队正在工作，但我没有任何ETA共享到现在。
2-如何升级集群:作为最佳实践，我找到了一个document1，这样您就可以在没有停机时间的情况下升级集群。请注意，当主(集群)升级时，工作负载不会受到影响，但我们将无法到达api服务器。因此，在升级过程中，我们不能部署新的工作负载或进行任何更改或监视状态。但是，我们可以将集群变成具有多个主节点的区域集群。另外，本文还提出了两种方法来升级节点池滚动更新和用节点池进行迁移。现在，为了解决PV和PVC问题，我已经在我的项目中进行了测试，并在节点池升级期间发现，PVC没有被删除，因此PV没有被删除(尽管回收策略被定义为Delete)。但是我建议使用磁盘的备份(与PV相关联)，然后按照document2重新创建PV。
最后，为什么1.14.10-gke.36是默认版本？默认版本是逐步设置和更新的，上一次设置为1.14.10-gke-36的document3是在5月13日，这可以在任何下一个更新中更改。但是我们可以手动定义gke集群版本。
如果你有疑问或者觉得我漏掉了什么，请告诉我。对于1.14.10-gke-36的更新，你可以期待我在周五(2020年6月26日) 16:00美国东部时间更新。
2- https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/preexisting-pd
3- https://cloud.google.com/kubernetes-engine/docs/release-notes#new_default_version
https://stackoverflow.com/questions/62150980
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号