☰

Rasperry Pi（运行 k8s）系统性能很差 - 如何调试？

tag-icon • tag-icon kubernetes raspbian iostat
Rasperry Pi（运行 k8s）系统性能很差 - 如何调试？

概括

我在 2-Pi4 集群上运行了一个精简版家庭实验室（带有少量 pod、Gitea、Drone、Docker Registry 和 NFS 共享的 Kubernetes 集群），系统性能很差。我注意到控制器节点的文件系统看起来非常慢 - 我不确定这是其他症状的原因还是由其他症状引起的。我将在新的 SD 卡上重新映像并重新安装控制器节点，希望这样可以解决问题 - 但与此同时，我正在寻找其他方法来调试此问题。

情况

我在自己的硬件上搭建了一个最小的 Kubernetes 集群，主要遵循以下原则本指南有一些变化：

  • 我只有两个 Pi4（1 个 8Gb RAM，1 个 4Gb），所以我的集群稍微小一些（8Gb 是控制平面，4Gb 是工作平面）。
  • 在发现 Ubuntu Server 有点慢且响应迟钝后（并与其他 Pi 爱好者验证了这一印象以确保这不仅仅是我的看法/硬件问题），我改用 64 位 Raspbian 操作系统。
    • 这意味着我的cmdline.txt改变稍微不一样- 当我使用那篇文章中的 Ubuntu 版本时，Pi 无法从重启中恢复
  • 该集群尚未（尚未）在其自己的私有网络上 - 它们只是通过我的主要家庭网络进行通信。
  • 控制节点有一个通过 USB3 连接的硬盘，并通过 NFS 共享以供 k8s pod 使用。
  • 我也安装了fail2ban、Gitea、Drone 以及基本的 Docker 容器注册表（以及前面提到的 NFS 共享）在控制器节点上 - 我认为最好独立于 k8s 集群托管 CI/CD 和组件，因为它们是依赖项的它（很高兴收到关于此的反馈，但我认为这与这个问题无关）。

问题

集群已启动并运行，我已经能够在其上运行一些部署（Kubernetes Dashboard、jellyfin、grafana 以及我的一个基于 nginx 的小型部署Hugo 搭建的博客）。这（以及前面提到的 CI/CD 组件和 NFS 共享）似乎对集群来说应该是一个非常小的负载（我向那篇文章) - 我之前已经在单个 4Gb Pi4 上运行了所有这些（减去 Kubernetes 开销）以及更多内容，没有任何问题。但是，系统非常慢且无响应：

  • 简单的 shell 命令（例如man ln，，df）uptime将需要大约 10 秒才能完成；apt-et install或者pip3 install命令很多比平时慢（两位数分钟）
  • Gitea 的 UI 中加载了大量简单页面（例如) 可能需要 10 秒到 1 分钟的时间。
  • 简单搭建博客（Gitea 链接， 或者GitHub 镜像如果不可用）则需要 20 多分钟。
  • 创建一个简单的 pod 可能需要几分钟的时间
  • Kubernetes 仪表板通常会在填充信息之前显示窗格/页面的旋转图标约 20 秒。
  • 当使用kubectl proxy查看仪表板时，有时浏览器会显示包含消息的 JSON 负载，而不是页面error trying to reach service: dial tcp <IP> connect: connection refused。如果我改用kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard 8443:443，则会在终端中收到以下错误：
Forwarding from 127.0.0.1:8443 -> 8443
Forwarding from [::1]:8443 -> 8443
Handling connection for 8443
E0520 22:03:24.086226   47798 portforward.go:400] an error occurred forwarding 8443 -> 8443: error forwarding port 8443 to pod a8ef295e1e42c5c739f761ab517618dd1951ad0c19fb517849979edb80745763, uid : failed to execute portforward in network namespace "/var/run/netns/cni-cfc573de-3714-1f3a-59a9-96285ce328ca": read tcp4 127.0.0.1:45274->127.0.0.1:8443: read: connection reset by peer
Handling connection for 8443
Handling connection for 8443
E0520 22:03:29.884407   47798 portforward.go:385] error copying from local connection to remote stream: read tcp4 127.0.0.1:8443->127.0.0.1:54550: read: connection reset by peer
Handling connection for 8443
E0520 22:05:58.069799   47798 portforward.go:233] lost connection to pod

到目前为止我尝试过的

系统资源

首先我检查了所有k8s机器上的系统资源。htop显示：

  • controller- 4 个核心的 CPU 负载均小于 10%，内存使用量约为 2G/7.6G，交换空间为 47/100M - 平均负载 11.62 10.17 7.32
  • worker- 4 个核心的 CPU 负载均小于 3%，内存使用率约为 300M/1.81G，交换空间为 20/100M -Load average 0.00 0.00 0.00

这在两个方面是奇怪的：

  • 如果平均负载如此之高（这表明 100% 利用率是“平均负载 = 核心数”，因此平均负载 11 表示这个 4 核 Pi 的容量接近 300%），为什么 CPU 使用率这么低？
  • 为什么worker显示这样的controller平均负载低？具体来说，我已确认和之间的 k8s pod 分配比例约为 50/50 worker，并确认我已设置AGENTS_ENABLED=true（參考) 在无人机服务器上。

我按照说明这里调查高系统负载和低 CPU 利用率：

  • w确认系统负载高
  • sar输出：
$ sar -u 5
Linux 5.15.32-v8+ (rassigma)    05/21/2022      _aarch64_       (4 CPU)

02:41:57 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:42:02 PM     all      2.47      0.00      1.16     96.37      0.00      0.00
02:42:07 PM     all      2.77      0.00      2.21     95.02      0.00      0.00
02:42:12 PM     all      3.97      0.00      1.01     95.02      0.00      0.00
02:42:17 PM     all      2.42      0.00      1.11     96.47      0.00      0.00
^C
Average:        all      2.91      0.00      1.37     95.72      0.00      0.00

因此，很多的 %iowait!

  • ps -eo s,user | grep "^[RD]" | sort | uniq -c | sort -nbr显示
6 D root
1 R pi

，所以这似乎不是这里的原因（文章列出了一个有数千个线程处于 D/R 状态的示例）

基于这些二问题，我将在这里包括在 上运行的各种命令的输出controller，尽管我不知道如何解释它们：

$ netstat -i 15
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
br-5bde1  1500    15188      0      0 0         15765      0      0      0 BMRU
br-68f83  1500      121      0      0 0           241      0      0      0 BMU
cni0      1450  1546275      0      0 0       1687849      0      0      0 BMRU
docker0   1500   146703      0      0 0        160569      0      0      0 BMRU
eth0      1500  5002006      0      0 0       2325706      0      0      0 BMRU
flannel.  1450   161594      0      0 0        168478      0   4162      0 BMRU
lo       65536  6018581      0      0 0       6018581      0      0      0 LRU
veth1729  1450    41521      0      0 0         59590      0      0      0 BMRU
veth1a77  1450   410622      0      0 0        453044      0      0      0 BMRU
veth35a3  1450       82      0      0 0         20237      0      0      0 BMRU
veth3dce  1500    59212      0      0 0         61170      0      0      0 BMRU
veth401b  1500       28      0      0 0          4182      0      0      0 BMRU
veth4257  1450   108391      0      0 0        173055      0      0      0 BMRU
veth4642  1500    12629      0      0 0         16556      0      0      0 BMRU
veth6a62  1450       83      0      0 0         20285      0      0      0 BMRU
veth7c18  1450    47952      0      0 0         59756      0      0      0 BMRU
veth8a14  1450       82      0      0 0         20279      0      0      0 BMRU
vethcc5c  1450   655457      0      0 0        716329      0      0      0 BMRU
vethe535  1450       17      0      0 0           769      0      0      0 BMRU
vethf324  1450   180986      0      0 0        198679      0      0      0 BMRU
wlan0     1500        0      0      0 0             0      0      0      0 BMU

$ iostat -d -x
Linux 5.15.32-v8+ (rassigma)    05/21/2022      _aarch64_       (4 CPU)

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
mmcblk0          0.20     14.65     0.07  26.90 1031.31    74.40    3.33     56.68     1.64  33.04 4562.85    17.02    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00   15.40  51.07
sda              0.27     28.31     0.05  15.37   25.75   104.42    0.36     26.56     0.24  39.99   64.19    72.81    0.00      0.00     0.00   0.00    0.00     0.00    0.04   90.24    0.03   0.56

$ vmstat 15
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  3  48640 827280 129600 4607164    0    0    11    21   15   42  4  1 71 24  0
 0  5  48640 827128 129600 4607216    0    0     1    44 2213 4267  4  1 31 64  0
 0 10  48640 827660 129600 4607216    0    0     0    47 1960 3734  4  1 36 59  0
 0  5  48640 824912 129600 4607624    0    0     1   121 2615 4912  6  2 15 77  0
 2 12  48640 824416 129600 4607692    0    0     0   102 2145 4129  4  2 30 64  0
 1  7  48640 822428 129600 4607972    0    0     3    81 1948 3564  6  2 10 83  0
 0  5  48640 823312 129600 4608164    0    0     4    62 2328 4273  5  2 12 81  0
 0  7  48640 824320 129600 4608220    0    0     1   143 2433 4695  5  2  9 84  0
 ...

SD 卡的利用率为 51%（从iostat输出来看）可能是合理地高，但没有问题 - 所以我才会这么想？

文件系统

引用本文关于如何测试（SD 卡）文件系统性能controller（worker均使用同一批，宣传写入速度为 10 MB/s)：

controller - $ dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 43.2033 s, 2.4 MB/s

worker - $ dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 5.97128 s, 17.6 MB/s

controller的文件系统写入速度似乎比 的慢约 7 倍worker。不过，我不确定如何解释这种因果关系 - 可能是controller的文件系统速度慢，从而导致其他症状，也可能是存在其他进程吞吐量瓶颈，导致文件系统速度慢和其他症状。

网络

我的家庭网络落后于一个相当标准的OPNSense路由器。

使用以下方法检查外部网络连接Speedtest 命令行界面：

controller - $ speedtest
     Server: Tekify Fiber & Wireless - Fremont, CA (id = 6468)
        ISP: Sonic.net, LLC
    Latency:     3.53 ms   (0.15 ms jitter)
   Download:   859.90 Mbps (data used: 523.3 MB )
     Upload:   932.58 Mbps (data used: 955.5 MB )
Packet Loss:     0.0%
---
worker - $ speedtest
     Server: Tekify Fiber & Wireless - Fremont, CA (id = 6468)
        ISP: Sonic.net, LLC
    Latency:     3.29 ms   (1.84 ms jitter)
   Download:   871.33 Mbps (data used: 776.6 MB )
     Upload:   917.25 Mbps (data used: 630.5 MB )
Packet Loss:     0.0%

我确实计划测试网络内速度，但考虑到到达这个调试阶段需要多长时间，以及controllerSD 卡出现问题的强烈信号（高%iowait、dd写入性能慢），我选择先更换它，然后再检查网络。

更新

  • 在新的 SD 卡上重新映像后，除了 Raspbian 之外没有安装任何其他东西，dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync文件系统速度测试为“重生”的控制节点提供了 17.2 MB/s。我将安装 k8s 集群和其他工具，然后再次测试。
  • 安装完所有工具（k8s、docker 容器、drone、gitea、nfs）后，文件系统写入速度为 17MB/s；在 k8s 集群上安装容器后，写入速度为 16.5MB，读取速度%iowait几乎sar -u 5为 0。系统性能很棒！看起来只是一张坏掉的 SD 卡 :D

相关内容