Системная производительность Rasperry Pi (под управлением k8s) очень низкая — как отладить?

Question

Резюме

Я запускаю тонкую домашнюю лабораторию (кластер Kubernetes с несколькими модулями, Gitea, Drone, Docker Registry и общим ресурсом NFS) на кластере 2-Pi4, и производительность системы низкая. Я заметил, что файловая система узла контроллера выглядит довольно медленно — я не уверен, является ли это причиной или вызвано другими симптомами. Я собираюсь повторно создать образ и переустановить узел контроллера на новую SD-карту в надежде, что это исправит ситуацию, но тем временем я ищу другие подходы для устранения этой проблемы.

Ситуация

Я настроил минимальный кластер Kubernetes на собственном оборудовании, в основном следуя это руководство с небольшими изменениями:

У меня только два Pi4 (1 8Gb RAM, 1 4Gb), поэтому мой кластер немного меньше (8Gb — плоскость управления, 4Gb — рабочая).
Обнаружив, что Ubuntu Server немного медленный и не отвечает (и проверил это впечатление с другими пи-тузиастами, чтобы убедиться, что это не только мое восприятие / оборудование), я вместо этого использовал 64-битную ОС Raspbian.
- Что, в свою очередь, означало, что мой cmdline.txt изменение было немного отличается — когда я использовал версию Ubuntu из этой статьи, Pi не возвращался после перезагрузки
Кластер не находится (пока!) в собственной частной сети — они просто общаются через мою основную домашнюю сеть.
Узел контроллера имеет жесткий диск, подключенный через USB3 и совместно используемый через NFS для использования модулями k8s.
я также установил fail2ban, Gitea, Drone и простейший реестр контейнеров Docker (а также вышеупомянутый общий ресурс NFS) на узле контроллера — я подумал, что лучше всего размещать CI/CD и компоненты независимо от кластера k8s, потому что они являются зависимостями из это (рад получить обратную связь по этому поводу, но я думаю, что это касается этого вопроса).

Проблема

Кластер запущен и работает, и я смог запустить на нем несколько развертываний (панель инструментов Kubernetes, jellyfin, grafana и небольшое развертывание моего приложения на основе nginx). Блог, созданный Хьюго). Это (наряду с вышеупомянутыми компонентами CI/CD и общим ресурсом NFS) кажется довольно незначительной нагрузкой для кластера (и я подтвердил это ожидание у автора статьи). эта статья) — ранее я запускал все это (за вычетом накладных расходов Kubernetes) и многое другое только на одном 4Gb Pi4 без проблем. Однако система работает очень медленно и не отвечает:

Простые команды оболочки (например, man ln , df, uptime) займет ~10 секунд; apt-et install или pip3 install команды много медленнее, чем обычно (минуты с двузначным числом)
Множество простых страниц в пользовательском интерфейсе Gitea (например) может занять от 10 секунд до минуты.
Простая сборка блога (Гитея ссылкаили Зеркало GitHub если это недоступно) займет более 20 минут.
Создание простого модуля может занять двузначное число минут.
Панель инструментов 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 — Загрузка ЦП <10 % на всех 4 ядрах, использование памяти ~2 Гб/7,6 Гб, подкачка 47/100 Мб - Средняя загрузка 11,62 10,17 7,32
worker — Загрузка процессора <3% для всех 4 ядер и использование памяти ~300M/1,81G, Swap 20/100M - Load average 0.00 0.00 0.00

Что странно в двух отношениях:

если средняя нагрузка настолько высока (это предполагает, что 100%-е использование — это «средняя нагрузка = количество ядер», поэтому средняя загрузка 11 указывает на то, что этот 4-ядерный Pi имеет почти 300%-ю мощность), почему загрузка ЦП такая низкая?
Почему worker показывая такой низкая средняя нагрузка? В частности, я подтвердил, что между модулями k8s примерно 50/50. controller и workerи подтвердил, что я установил AGENTS_ENABLED=true (ссылка) на сервере Drone.

Я следовал инструкциям здесь чтобы исследовать высокую загрузку системы и низкую загрузку ЦП:

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

Итак, много %ioподождите!

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 (оба используют SD-карты от та же партияв котором заявлена скорость записи 10 МБ/с):

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запись FS в ~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 МБ/с для «возрожденного» узла контроллера. Я установлю кластер k8s и другие инструменты и снова протестирую.
После установки всех инструментов (k8s, docker container, Drone, gitea, nfs) скорость записи файловой системы составила 17 МБ/с; после установки контейнеров на кластер k8s скорость записи составила 16,5 МБ, а %iowait от sar -u 5 было почти 0. Производительность системы отличная! Похоже, это была просто неработающая SD-карта 😀