Memoria de hogar dedicada e intervención OOM Killer

Hola de nuevo La traducción del siguiente artículo se preparó específicamente para los estudiantes del curso de la Plataforma de Infraestructura basada en Kubernetes , que comienza este mes.



En los últimos días, algunos de mis pods se bloquearon constantemente, dejando un registro en el registro del sistema operativo que OOM Killer destruyó el proceso del contenedor. Decidí averiguar por qué está sucediendo esto.

Configuración de límite de memoria de hogar y memoria de grupo c

Probemos en la distribución de K3s. Creamos bajo con un límite de memoria característico de 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:/# 

En otra consola, descubra el uid hogar.

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

En el servidor donde se está ejecutando, descubrimos los parámetros de cgroup especificando el uid pod deseado.

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

128974848 es exactamente 123 MiB (123 * 1024 * 1024). La situación se está aclarando. Resulta que en Kubernetes, el límite de memoria se establece a través de cgroup. Tan pronto como crezca más del límite de memoria asignado, cgroup inicia la destrucción del proceso del contenedor.

Prueba de esfuerzo

Instalemos utilidades para probar el hogar mediante una sesión de consola de comandos abierta.

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

Al mismo tiempo, rastrearemos las entradas de syslog con el dmesg -Tw .

Primero, ejecute la utilidad de prueba de esfuerzo, asignando 100 MB de memoria. El proceso comenzó con éxito.

 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 

Ahora realizaremos la segunda prueba de esfuerzo.

 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 

El lanzamiento condujo a la destrucción instantánea del proceso de la primera prueba de esfuerzo (PID 271) en la señal 9.

Mientras tanto, aparecieron las siguientes entradas en el registro del sistema:

[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

El proceso con PID 32308 en el host se destruyó debido a falta de memoria (OOM). Pero lo más interesante está oculto al final de las entradas del diario:



Aquí están los procesos de este hogar que están marcados como candidatos para la destrucción por el componente OOM Killer. El proceso de pause base, que almacena los espacios de nombres de la red, recibió una calificación de -998 de -998 , lo que significa que no se garantiza que el proceso sea destruido. Los procesos restantes en el contenedor recibieron una puntuación oom_score_adj de 939 . Puede verificar este valor utilizando la fórmula de la documentación de Kubernetes a continuación:

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

Descubrimos la cantidad de memoria disponible para el nodo:

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

Si no se especifica el tamaño de memoria solicitado, de forma predeterminada será igual al límite. Sustituyendo los valores, obtenemos el siguiente valor oom_score_adj : 1000–123*1024/2041888=938.32 , que está muy cerca del valor 939 especificado en el registro del sistema. (No sé cómo OOM Killer obtiene el valor exacto de 939).

Por lo tanto, todos los procesos en el contenedor tienen el mismo valor oom_score_adj. El componente OOM Killer calcula el valor OOM en función del uso de memoria y ajusta el resultado en función de la puntuación oom_score_adj. Y, en última instancia, destruye el proceso de la primera prueba de esfuerzo, que consumió la mayor parte de la memoria, 100 MB, que corresponde a la estimación oom_score = 1718.

Conclusión

Kubernetes controla el límite de memoria del hogar a través de los componentes cgroup y OOM Killer. Es necesario acordar cuidadosamente las condiciones del sistema operativo OOM y los hogares OOM.

¿Cómo te gusta el material? Todos los que quieran aprender más sobre el curso están invitados a un seminario web gratuito el 17 de junio, donde estudiaremos las capacidades de Kubernetes para organizar prácticas de entrega continua (CI / CD) y enfoques para un equipo pequeño con varias aplicaciones, así como para una gran organización con una gran cantidad de sistemas.