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

Резюме

Я запускаю тонкую домашнюю лабораторию (кластер 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 без проблем. Однако система работает очень медленно и не отвечает:

• Простые команды оболочки (например, человек в , дф, время безотказной работы) займет ~10 секунд; способная установить или же pip3 установить команды много медленнее, чем обычно (минуты с двузначным числом)
• Множество простых страниц в пользовательском интерфейсе Gitea (например) может занять от 10 секунд до минуты.
• Простая сборка блога (Гитея ссылка, или же Зеркало GitHub если это недоступно) займет более 20 минут.
• Создание простого модуля может занять двузначное число минут.
• Панель инструментов Kubernetes часто отображает значок счетчика для панели/страницы в течение примерно 20 секунд перед заполнением информации.
• Когда используешь kubectl прокси для просмотра панели инструментов иногда вместо страницы браузер отображает полезную нагрузку JSON, включая сообщение ошибка при попытке связаться с сервисом: наберите tcp <IP> connect: соединение отклонено. Если я вместо этого использую kubectl port-forward -n служба kubernetes-dashboard/kubernetes-dashboard 8443:443, я получаю следующую ошибку в терминале:

Пересылка с 127.0.0.1:8443 -> 8443
Пересылка с [::1]:8443 -> 8443
Обработка соединения для 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": чтение tcp4 127.0.0.1:45274->127.0.0.1:8443: чтение: сброс соединения узлом
Обработка соединения для 8443
Обработка соединения для 8443
E0520 22:03:29.884407 47798 portforward.go:385] ошибка копирования из локального соединения в удаленный поток: чтение tcp4 127.0.0.1:8443->127.0.0.1:54550: чтение: сброс соединения узлом
Обработка соединения для 8443
E0520 22:05:58.069799 47798 portforward.go:233] потеряно соединение с модулем

Что я пробовал до сих пор

Системные ресурсы

Сначала я проверил системные ресурсы на всех машинах k8s. хтоп показал:

• контроллер - Загрузка ЦП <10 % на всех 4 ядрах, использование памяти ~2 Гб/7,6 Гб, подкачка 47/100 Мб - Средняя загрузка 11,62 10,17 7,32
• рабочий - Загрузка процессора <3% для всех 4 ядер и использование памяти ~300M/1,81G, Swap 20/100M - Средняя нагрузка 0,00 0,00 0,00

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

• если средняя нагрузка настолько высока (это предполагает, что 100%-е использование — это «средняя нагрузка = количество ядер», поэтому средняя загрузка 11 указывает на то, что этот 4-ядерный Pi имеет почти 300%-ю мощность), почему загрузка ЦП такая низкая?
• Почему рабочий показывая такой низкая средняя нагрузка? В частности, я подтвердил, что между модулями k8s примерно 50/50. контроллер и рабочийи подтвердил, что я установил АГЕНТЫ_ENABLED=истина (ссылка) на сервере Drone.

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

• ж подтверждена высокая загрузка системы
• сар вывод:

$сар -у 5
Linux 5.15.32-v8+ (rassigma) 21.05.2022 _aarch64_ (4 CPU)

14:41:57 CPU %user %nice %system %iowait %steal %idle
14:42:02 все 2,47 0,00 1,16 96,37 0,00 0,00
14:42:07 все 2,77 0,00 2,21 95,02 0,00 0,00
14:42:12 все 3,97 0,00 1,01 95,02 0,00 0,00
14:42:17 все 14.42 0.00 1.11 96.47 0.00 0.00
^ С
Среднее: все 2,91 0,00 1,37 95,72 0,00 0,00

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

• ps -eo s,пользователь | grep "^[RD]" | сортировать | уникальный -c | сортировать -nbr показал

6 D корень
1 R пи

, так что здесь это не похоже на причину (в статье приведен пример с тысячами потоков в состояниях D/R)

На основе эти два вопросы, я включу сюда вывод различных команд, запущенных на контроллер, хотя я не знаю, как их интерпретировать:

$ netstat -i 15
Таблица интерфейса ядра
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
бр-5бде1 1500 15188 0 0 0 15765 0 0 0 БМРУ
бр-68ф83 1500 121 0 0 0 241 0 0 0 БМУ
cni0 1450 1546275 0 0 0 1687849 0 0 0 БМРУ
docker0 1500 146703 0 0 0 160569 0 0 0 БМРУ
eth0 1500 5002006 0 0 0 2325706 0 0 0 БМРУ
фланель. 1450 161594 0 0 0 168478 0 4162 0 БМРУ
ло 65536 6018581 0 0 0 6018581 0 0 0 LRU
veth1729 1450 41521 0 0 0 59590 0 0 0 БМРУ
veth1a77 1450 410622 0 0 0 453044 0 0 0 БМРУ
veth35a3 1450 82 0 0 0 20237 0 0 0 БМРУ
veth3dce 1500 59212 0 0 0 61170 0 0 0 БМРУ
veth401b 1500 28 0 0 0 4182 0 0 0 БМРУ
veth4257 1450 108391 0 0 0 173055 0 0 0 БМРУ
veth4642 1500 12629 0 0 0 16556 0 0 0 БМРУ
veth6a62 1450 83 0 0 0 20285 0 0 0 БМРУ
veth7c18 1450 47952 0 0 0 59756 0 0 0 БМРУ
veth8a14 1450 82 0 0 0 20279 0 0 0 БМРУ
vethcc5c 1450 655457 0 0 0 716329 0 0 0 БМРУ
vethe535 1450 17 0 0 0 769 0 0 0 БМРУ
vethf324 1450 180986 0 0 0 198679 0 0 0 БМРУ
wlan0 1500 0 0 0 0 0 0 0 0 БМУ

$ iostat -d -x
Linux 5.15.32-v8+ (rassigma) 21.05.2022 _aarch64_ (4 CPU)

Устройство r/s rkB/s rrqm/s %rrqm r_await rawq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await Darq-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,00
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

$ вмстат 15
procs -----------память---------- ---своп-- -----io---- -система-- ------процессор -----
 r b swpd бесплатный кэш баффов 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 % (от йостат вывод) наверное разумно высоко, но не проблематично-так бы я подумал?

Файловая система

Ссылка эта статья о том, как проверить (SD-карта) производительность файловой системы на контроллер и рабочий (оба используют SD-карты от та же партия, в котором заявлена ​​скорость записи 10 МБ/с):

контроллер - $ dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync
100+0 записей в
100+0 записей
104857600 байт (105 МБ, 100 МБ) скопировано, 43,2033 с, 2,4 МБ/с

рабочий - $ dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync
100+0 записей в
100+0 записей
104857600 байт (105 МБ, 100 МБ) скопировано, 5,97128 с, 17,6 МБ/с

контроллерзапись FS в ~7 раз медленнее, чем рабочийс. Я не уверен, как причинно интерпретировать это, хотя может быть, что контроллер, файловая система работает медленно, что вызывает другие симптомы, или может быть, что есть какое-то другое узкое место в пропускной способности процесса, которое вызывает как медленную файловую систему, так и другие симптомы.

Сеть

Моя домашняя сеть находится за довольно стандартным OPNSense маршрутизатор.

Проверка подключения к внешней сети с помощью Интерфейс командной строки Speedtest:

контроллер - $ speedtest
     Сервер: Tekify Fiber & Wireless — Фремонт, Калифорния (id = 6468)
        Интернет-провайдер: Sonic.net, ООО
    Задержка: 3,53 мс (дрожание 0,15 мс)
   Загрузка: 859,90 Мбит/с (используемые данные: 523,3 МБ)
     Загрузка: 932,58 Мбит/с (используемые данные: 955,5 МБ)
Потеря пакетов: 0,0%
---
рабочий - $ speedtest
     Сервер: Tekify Fiber & Wireless — Фремонт, Калифорния (id = 6468)
        Интернет-провайдер: Sonic.net, ООО
    Задержка: 3,29 мс (джиттер 1,84 мс)
   Загрузка: 871,33 Мбит/с (используемые данные: 776,6 МБ)
     Загрузка: 917,25 Мбит/с (используемые данные: 630,5 МБ)
Потеря пакетов: 0,0%

Я планировал проверить скорость внутри сети, но, учитывая, сколько времени ушло на отладку, и сильные сигналы о том, что есть проблема с контроллерSD-карта (высокая %iowait, медленный дд запись производительности), я решил перейти к замене этого, прежде чем проверять сеть.

Обновления

• После повторного создания образа на новой 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 от сар -у 5 было почти 0. Производительность системы отличная! Похоже, это была просто неработающая SD-карта :D