Spezielles Herdgedächtnis und OOM Killer-Intervention

Hallo nochmal! Die Übersetzung des nächsten Artikels wurde speziell für Studenten des Kubernetes-basierten Infrastructure Platform- Kurses vorbereitet, der diesen Monat beginnt. Beginnen wir.



In den letzten Tagen sind einige meiner Pods ständig abgestürzt und haben im Betriebssystemprotokoll einen Hinweis hinterlassen, dass OOM Killer den Containerprozess zerstört hat. Ich beschloss herauszufinden, warum dies geschieht.

Speicherlimit für Herd und Speichereinstellungen für Gruppen

Testen wir die K3s-Distribution. Wir erstellen unter mit einer charakteristischen Speichergrenze von 123 MiB (123 Mi).

kubectl run --restart=Never --rm -it --image=ubuntu --limits='memory=123Mi' -- sh If you don't see a command prompt, try pressing enter. root@sh:/# 

Finden Sie in einer anderen Konsole die uid Herdes heraus.

 kubectl get pods sh -o yaml | grep uid uid: bc001ffa-68fc-11e9-92d7-5ef9efd9374c 

Auf dem Server, unter dem es ausgeführt wird, ermitteln wir die cgroup Parameter, indem wir die uid gewünschten Pods uid .

 cd /sys/fs/cgroup/memory/kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c cat memory.limit_in_bytes 128974848 

128974848 ist genau 123 MiB (123 * 1024 * 1024). Die Situation klärt sich auf. Es stellt sich heraus, dass in Kubernetes das Speicherlimit über cgroup festgelegt wird. Sobald mehr als das zugewiesene Speicherlimit erreicht ist, leitet cgroup die Zerstörung des Containerprozesses ein.

Stresstest

Lassen Sie uns Dienstprogramme zum Stresstest des Herdes über eine offene Befehlskonsolensitzung installieren.

 root@sh:/# apt update; apt install -y stress 

Gleichzeitig verfolgen wir Syslog-Einträge mit dem dmesg -Tw .

Führen Sie zunächst das Stresstest-Dienstprogramm aus und weisen Sie 100 MB Speicher zu. Der Prozess wurde erfolgreich gestartet.

 root@sh:/# stress --vm 1 --vm-bytes 100M & [1] 271 root@sh:/# stress: info: [271] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd 

Jetzt werden wir den zweiten Stresstest durchführen.

 root@sh:/# stress --vm 1 --vm-bytes 50M stress: info: [273] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd stress: FAIL: [271] (415) <-- worker 272 got signal 9 stress: WARN: [271] (417) now reaping child worker processes stress: FAIL: [271] (451) failed run completed in 7s 

Der Start führte zur sofortigen Zerstörung des Prozesses des ersten Stresstests (PID 271) bei Signal 9.

In der Zwischenzeit wurden folgende Einträge im Systemprotokoll angezeigt:

[Sat Apr 27 22:56:09 2019] stress invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=939
[Sat Apr 27 22:56:09 2019] stress cpuset=a2ed67c63e828da3849bf9f506ae2b36b4dac5b402a57f2981c9bdc07b23e672 mems_allowed=0
[Sat Apr 27 22:56:09 2019] CPU: 0 PID: 32332 Comm: stress Not tainted 4.15.0-46-generic #49-Ubuntu
[Sat Apr 27 22:56:09 2019] Hardware name: BHYVE, BIOS 1.00 03/14/2014
[Sat Apr 27 22:56:09 2019] Call Trace:
[Sat Apr 27 22:56:09 2019] dump_stack+0x63/0x8b
[Sat Apr 27 22:56:09 2019] dump_header+0x71/0x285
[Sat Apr 27 22:56:09 2019] oom_kill_process+0x220/0x440
[Sat Apr 27 22:56:09 2019] out_of_memory+0x2d1/0x4f0
[Sat Apr 27 22:56:09 2019] mem_cgroup_out_of_memory+0x4b/0x80
[Sat Apr 27 22:56:09 2019] mem_cgroup_oom_synchronize+0x2e8/0x320
[Sat Apr 27 22:56:09 2019] ? mem_cgroup_css_online+0x40/0x40
[Sat Apr 27 22:56:09 2019] pagefault_out_of_memory+0x36/0x7b
[Sat Apr 27 22:56:09 2019] mm_fault_error+0x90/0x180
[Sat Apr 27 22:56:09 2019] __do_page_fault+0x4a5/0x4d0
[Sat Apr 27 22:56:09 2019] do_page_fault+0x2e/0xe0
[Sat Apr 27 22:56:09 2019] ? page_fault+0x2f/0x50
[Sat Apr 27 22:56:09 2019] page_fault+0x45/0x50
[Sat Apr 27 22:56:09 2019] RIP: 0033:0x558182259cf0
[Sat Apr 27 22:56:09 2019] RSP: 002b:00007fff01a47940 EFLAGS: 00010206
[Sat Apr 27 22:56:09 2019] RAX: 00007fdc18cdf010 RBX: 00007fdc1763a010 RCX: 00007fdc1763a010
[Sat Apr 27 22:56:09 2019] RDX: 00000000016a5000 RSI: 0000000003201000 RDI: 0000000000000000
[Sat Apr 27 22:56:09 2019] RBP: 0000000003200000 R08: 00000000ffffffff R09: 0000000000000000
[Sat Apr 27 22:56:09 2019] R10: 0000000000000022 R11: 0000000000000246 R12: ffffffffffffffff
[Sat Apr 27 22:56:09 2019] R13: 0000000000000002 R14: fffffffffffff000 R15: 0000000000001000
[Sat Apr 27 22:56:09 2019] Task in /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c/a2ed67c63e828da3849bf9f506ae2b36b4dac5b402a57f2981c9bdc07b23e672 killed as a result of limit of /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c
[Sat Apr 27 22:56:09 2019] memory: usage 125952kB, limit 125952kB, failcnt 3632
[Sat Apr 27 22:56:09 2019] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
[Sat Apr 27 22:56:09 2019] kmem: usage 2352kB, limit 9007199254740988kB, failcnt 0
[Sat Apr 27 22:56:09 2019] Memory cgroup stats for /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c: cache:0KB rss:0KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
[Sat Apr 27 22:56:09 2019] Memory cgroup stats for /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c/79fae7c2724ea1b19caa343fed8da3ea84bbe5eb370e5af8a6a94a090d9e4ac2: cache:0KB rss:48KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:48KB inactive_file:0KB active_file:0KB unevictable:0KB
[Sat Apr 27 22:56:09 2019] Memory cgroup stats for /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c/a2ed67c63e828da3849bf9f506ae2b36b4dac5b402a57f2981c9bdc07b23e672: cache:0KB rss:123552KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:123548KB inactive_file:0KB active_file:0KB unevictable:0KB
[Sat Apr 27 22:56:09 2019] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[Sat Apr 27 22:56:09 2019] [25160] 0 25160 256 1 28672 0 -998 pause
[Sat Apr 27 22:56:09 2019] [25218] 0 25218 4627 872 77824 0 939 bash
[Sat Apr 27 22:56:09 2019] [32307] 0 32307 2060 275 57344 0 939 stress
[Sat Apr 27 22:56:09 2019] [32308] 0 32308 27661 24953 253952 0 939 stress
[Sat Apr 27 22:56:09 2019] [32331] 0 32331 2060 304 53248 0 939 stress
[Sat Apr 27 22:56:09 2019] [32332] 0 32332 14861 5829 102400 0 939 stress
[Sat Apr 27 22:56:09 2019] Memory cgroup out of memory: Kill process 32308 (stress) score 1718 or sacrifice child
[Sat Apr 27 22:56:09 2019] Killed process 32308 (stress) total-vm:110644kB, anon-rss:99620kB, file-rss:192kB, shmem-rss:0kB
[Sat Apr 27 22:56:09 2019] oom_reaper: reaped process 32308 (stress), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Der Prozess mit der PID 32308 auf dem Host wurde aufgrund von Speichermangel (OOM) zerstört. Das Interessanteste verbirgt sich jedoch am Ende der Tagebucheinträge:



Hier sind die Prozesse dieses Herdes, die als Kandidaten für die Zerstörung durch die OOM Killer-Komponente markiert sind. Der oom_score_adj , in dem die Netzwerk-Namespaces oom_score_adj , erhielt eine oom_score_adj Bewertung von -998 , was -998 , dass nicht garantiert wird, dass der Prozess zerstört wird. Die verbleibenden Prozesse im Container erhielten eine oom_score_adj Bewertung von 939 . Sie können diesen Wert mithilfe der folgenden Formel aus der Kubernetes-Dokumentation überprüfen:

 min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) 

Wir ermitteln die für den Knoten verfügbare Speichermenge:

 kubectl describe nodes k3s | grep Allocatable -A 5 Allocatable: cpu: 1 ephemeral-storage: 49255941901 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 2041888Ki 

Wenn die angeforderte Speichergröße nicht angegeben wird, entspricht sie standardmäßig dem Grenzwert. Durch Ersetzen der Werte erhalten wir den folgenden oom_score_adj Wert: 1000–123*1024/2041888=938.32 , was dem im Systemprotokoll angegebenen Wert 939 sehr nahe kommt. (Ich weiß nicht, wie OOM Killer den genauen Wert von 939 erhält.)

Alle Prozesse im Container haben also den gleichen Wert für oom_score_adj. Die OOM Killer-Komponente berechnet den OOM-Wert basierend auf der Speichernutzung und passt das Ergebnis basierend auf dem oom_score_adj-Score an. Und letztendlich zerstört es den Prozess des ersten Stresstests, der den größten Teil des Speichers verschlang, 100 MB, was der Schätzung oom_score = 1718 entspricht.

Fazit

Kubernetes steuert das Speicherlimit des Herdes über die Komponenten cgroup und OOM Killer. Es ist notwendig, die Bedingungen des OOM-Betriebssystems und der OOM-Herde sorgfältig zu vereinbaren.

Wie gefällt dir das Material? Jeder, der mehr über den Kurs erfahren möchte, wird am 17. Juni zu einem kostenlosen Webinar eingeladen, in dem wir die Fähigkeiten von Kubernetes zur Organisation kontinuierlicher Bereitstellungspraktiken (CI / CD) und Ansätze für ein kleines Team mit mehreren Anwendungen sowie für eine große Organisation mit einer großen Anzahl von Systemen untersuchen.