Performanța sistemului Rasperry Pi (care rulează k8s) este foarte slabă - cum se depanează?

rezumat

Rulez un homelab subțire (cluster Kubernetes cu puține poduri, Gitea, Drone, Docker Registry și partajare NFS) pe un cluster 2-Pi4, iar performanța sistemului este slabă. Am observat că sistemul de fișiere al nodului controlerului arată destul de lent - nu sunt sigur dacă aceasta este cauza sau cauzată de celelalte simptome. Voi reimagina și voi reinstala nodul controlerului pe un nou card SD, în speranța că asta îl rezolvă - dar, între timp, caut și alte abordări pentru depanarea acestei probleme.

Situatie

Am configurat un cluster Kubernetes minim pe propriul meu hardware, mai ales urmând acest ghid cu cateva modificari:

• Am doar două Pi4-uri (1 8Gb RAM, 1 4Gb), așa că clusterul meu este puțin mai mic (8Gb este planul de control, 4Gb este lucrător).
• După ce am descoperit că Ubuntu Server este puțin lent și nu răspunde (și am validat această impresie cu alți entuziaști Pi pentru a mă asigura că nu era doar percepția/hardware-ul meu), am folosit sistemul de operare Raspbian pe 64 de biți.
  • Ceea ce, la rândul său, însemna că al meu cmdline.txt schimbarea a fost putin diferit - când am folosit versiunea Ubuntu din acel articol, Pi nu a revenit de la o repornire
• Clusterul nu este (încă!) pe propria sa rețea privată - ei comunică doar prin rețeaua mea principală de acasă.
• Nodul controlerului are un hard disk conectat prin USB3 și partajat prin NFS pentru a fi utilizat de pod-urile k8s.
• am instalat si eu fail2ban, Gitea, Drone și un registru de containere Docker rudimentar (precum și partajarea NFS menționată mai sus) pe nodul controlerului - am crezut că cel mai bine este să găzduiesc CI/CD-ul și componentele independent de cluster-ul k8s, deoarece sunt dependențe de it (ma bucur să primesc feedback despre asta, dar cred că este tangențial la această întrebare).

Problemă

Clusterul este activ și funcționează și am reușit să rulez câteva implementări pe el (Tabloul de bord Kubernetes, jellyfin, grafana și o mică implementare bazată pe nginx a mea Blog construit de Hugo). Acest lucru (împreună cu componentele CI/CD menționate mai sus și partajarea NFS) pare că ar trebui să fie o încărcare destul de nesemnificativă pentru cluster (și am confirmat această așteptare cu autorul acel articol) - Le-am mai rulat anterior pe toate acestea (mai puțin overheadul Kubernetes) și multe altele numai pe singurul 4Gb Pi4, fără probleme. Cu toate acestea, sistemul este foarte lent și nu răspunde:

• Comenzi shell simple (de ex. om ln , df, timpul de funcționare) va dura ~10 secunde pentru a finaliza; apt-et install sau instalare pip3 comenzile sunt mult mai lent decât de obicei (minute cu două cifre)
• O mulțime de pagini simple în interfața de utilizare a Gitea (de exemplu.) poate dura între 10 secunde și un minut.
• Simplu construiește blogul (Link Gitea, sau oglindă GitHub dacă nu este disponibil) durează peste 20 de minute.
• Crearea unui pod simplu poate dura minute de două cifre
• Tabloul de bord Kubernetes va afișa adesea o pictogramă rotativă pentru un panou/pagină timp de aproximativ 20 de secunde înainte de a completa informațiile.
• Atunci când se utilizează proxy kubectl pentru a vizualiza tabloul de bord, uneori, în loc de o pagină, browserul va afișa o sarcină utilă JSON care include mesajul eroare la încercarea de a ajunge la serviciu: dial tcp <IP> connect: conexiune refuzată. Dacă în schimb folosesc kubectl port-forward -n serviciul kubernetes-dashboard/kubernetes-dashboard 8443:443, primesc următoarea eroare în terminal:

Redirecționare de la 127.0.0.1:8443 -> 8443
Redirecționare de la [::1]:8443 -> 8443
Conexiune de manipulare pentru 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": citiți tcp4 127.0.0.1:45274->127.0.0.1:8443: citiți: resetarea conexiunii de către peer
Conexiune de manipulare pentru 8443
Conexiune de manipulare pentru 8443
E0520 22:03:29.884407 47798 portforward.go:385] eroare la copierea de la conexiunea locală la fluxul de la distanță: citiți tcp4 127.0.0.1:8443->127.0.0.1:54550: citiți: resetarea conexiunii de către egal
Conexiune de manipulare pentru 8443
E0520 22:05:58.069799 47798 portforward.go:233] s-a pierdut conexiunea la pod

Ce am incercat pana acum

Resurse de sistem

Mai întâi am verificat resursele de sistem pe toate mașinile k8s. htop a aratat:

• controlor - Sarcina procesorului <10% pe toate cele 4 nuclee, utilizarea memoriei la ~2G/7,6G, Schimbare 47/100M - `Încărcare medie 11,62 10,17 7,32
• muncitor - Sarcina procesorului <3% pe toate cele 4 nuclee și utilizarea memoriei la ~300M/1.81G, Schimb 20/100M - Încărcare medie 0,00 0,00 0,00

Ceea ce este ciudat din două puncte de vedere:

• dacă media de încărcare este atât de mare (acest sugerează că utilizarea 100% este „Media de încărcare = numărul de nuclee”, deci media de încărcare de 11 indică faptul că acest Pi cu 4 nuclee este la o capacitate de aproape 300%), de ce este utilizarea procesorului atât de scăzută?
• De ce este muncitor arătând astfel de medie de sarcină scăzută? În special, am confirmat că există o împărțire de ~50/50 a podurilor k8s între controlor și muncitor, și a confirmat că am setat AGENTS_ENABLED=adevărat (ref) pe serverul Drone.

Am urmat instrucțiunile Aici pentru a investiga încărcarea ridicată a sistemului și utilizarea scăzută a procesorului:

• w încărcare mare a sistemului confirmată
• sar ieșire:

$ sar -u 5
Linux 5.15.32-v8+ (rassigma) 21.05.2022 _aarch64_ (4 CPU)

02:41:57 PM CPU %user %nice %system %iowait %steal %idle
02:42:02 PM toate 2.47 0.00 1.16 96.37 0.00 0.00
02:42:07 PM toate 2.77 0.00 2.21 95.02 0.00 0.00
14:42:12 toate 3.97 0.00 1.01 95.02 0.00 0.00
14:42:17 toate 2.42 0.00 1.11 96.47 0.00 0.00
^C
Medie: toate 2,91 0,00 1,37 95,72 0,00 0,00

Deci, a lot din %iowait!

• ps -eo s,utilizator | grep „^[RD]” | sortare | uniq -c | sortare -nbr a aratat

rădăcină 6 D
1 R pi

, deci nu asta pare a fi cauza aici (articolul enumeră un exemplu cu mii de fire în stări D/R)

Bazat pe aceste Două întrebări, voi include aici ieșirea diferitelor comenzi care rulează controlor, deși nu știu cum să le interpretez:

$ netstat -i 15
Tabel de interfață kernel
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
flanel. 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) 21.05.2022 _aarch64_ (4 CPU)

Dispozitiv r/s rkB/s rrqm/s %rrqm r_wait rareq-sz w/s wkB/s wrqm/s %wrqm w_wait wareq-sz d/s dkB/s drqm/s %drqm d_wait dareq-sz 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,01 0,0 0,0 0,0 0,0 0,0 0,0 0,01
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,9 0,04

$ vmstat 15
procs -----------memorie---------- ---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
 ...

51% utilizare pe cardul SD (de la iostat ieșire) este probabil rezonabil ridicat, dar nu problematic - așa că m-aș fi gândit?

Sistemul de fișiere

Referire Acest articol despre cum să testați performanța sistemului de fișiere (card SD). controlor și muncitor (ambele folosesc carduri SD de la același lot, care anunța o viteză de scriere de 10 MB/s):

controler - $ dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync
100+0 înregistrări în
100+0 înregistrări scoase
104857600 octeți (105 MB, 100 MiB) copiați, 43,2033 s, 2,4 MB/s

lucrător - $ dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync
100+0 înregistrări în
100+0 înregistrări scoase
104857600 de octeți (105 MB, 100 MiB) copiați, 5,97128 s, 17,6 MB/s

controlorScrierea lui FS pare a fi de ~7 ori mai lentă decât muncitorlui. Nu sunt sigur cum să interpretez cauzal asta, totuși - ar putea fi ca controlorSistemul de fișiere al lui este lent, ceea ce provoacă celelalte simptome sau s-ar putea să existe un alt blocaj de procesare care cauzează atât sistemul de fișiere lent, cât și celelalte simptome.

Reţea

Rețeaua mea de acasă este în spatele unui standard destul de mare OPNSense router.

Verificarea conectivității rețelei externe cu Speedtest CLI:

controler - $ speedtest
     Server: Tekify Fiber & Wireless - Fremont, CA (id = 6468)
        ISP: Sonic.net, LLC
    Latență: 3,53 ms (0,15 ms jitter)
   Descărcare: 859,90 Mbps (date utilizate: 523,3 MB)
     Încărcare: 932,58 Mbps (date utilizate: 955,5 MB)
Pierdere pachet: 0,0%
---
lucrător - $ speedtest
     Server: Tekify Fiber & Wireless - Fremont, CA (id = 6468)
        ISP: Sonic.net, LLC
    Latență: 3,29 ms (1,84 ms jitter)
   Descărcare: 871,33 Mbps (date folosite: 776,6 MB)
     Încărcare: 917,25 Mbps (date utilizate: 630,5 MB)
Pierdere pachet: 0,0%

Am plănuit să testez viteza în interiorul rețelei, dar având în vedere cât timp a durat până la acest punct de depanare și semnalele puternice că există o problemă cu controlorcardul SD al lui (înalt %ioașteaptă, încet dd scrierea performanței), am ales să trec mai întâi la înlocuirea acesteia înainte de a verifica rețeaua.

Actualizări

• După re-imaginile pe un card SD proaspăt, fără absolut nimic altceva instalat pe el, în afară de Raspbian, dd if=/dev/zero of=speedtest bs=1M count=100 conv=fdatasync Testul de viteză a sistemului de fișiere oferă 17,2 MB/s pentru nodul controler „renăscut”. Voi instala clusterul k8s și alte instrumente și voi testa din nou.
• După instalarea tuturor instrumentelor (k8s, docker container, drone, gitea, nfs), viteza de scriere a sistemului de fișiere a fost de 17MB/s; după instalarea containerelor pe cluster-ul k8s, viteza de scriere a fost de 16,5 MB și %ioașteaptă din sar -u 5 a fost aproape 0. Performanța sistemului este grozavă! Se pare că a fost doar un card SD prost :D