Necesito algunos consejos sobre un problema al que me enfrento con k8s 1.14 y ejecuto canalizaciones de gitlab en él. Muchos trabajos arrojan errores de código de salida 137 y descubrí que significa que el contenedor se está terminando abruptamente.
Información del clúster:
Versión de Kubernetes: 1.14 Nube en uso: AWS EKS Nodo: C5.4xLarge
Después de investigar, encontré los siguientes registros:
**kubelet: I0114 03:37:08.639450** 4721 image_gc_manager.go:300] [imageGCManager]: Disk usage on image filesystem is at 95% which is over the high threshold (85%). Trying to free 3022784921 bytes down to the low threshold (80%). **kubelet: E0114 03:37:08.653132** 4721 kubelet.go:1282] Image garbage collection failed once. Stats initialization may not have completed yet: failed to garbage collect required amount of images. Wanted to free 3022784921 bytes, but freed 0 bytes **kubelet: W0114 03:37:23.240990** 4721 eviction_manager.go:397] eviction manager: timed out waiting for pods runner-u4zrz1by-project-12123209-concurrent-4zz892_gitlab-managed-apps(d9331870-367e-11ea-b638-0673fa95f662) to be cleaned up **kubelet: W0114 00:15:51.106881** 4781 eviction_manager.go:333] eviction manager: attempting to reclaim ephemeral-storage **kubelet: I0114 00:15:51.106907** 4781 container_gc.go:85] attempting to delete unused containers **kubelet: I0114 00:15:51.116286** 4781 image_gc_manager.go:317] attempting to delete unused images **kubelet: I0114 00:15:51.130499** 4781 eviction_manager.go:344] eviction manager: must evict pod(s) to reclaim ephemeral-storage **kubelet: I0114 00:15:51.130648** 4781 eviction_manager.go:362] eviction manager: pods ranked for eviction: 1. runner-u4zrz1by-project-10310692-concurrent-1mqrmt_gitlab-managed-apps(d16238f0-3661-11ea-b638-0673fa95f662) 2. runner-u4zrz1by-project-10310692-concurrent-0hnnlm_gitlab-managed-apps(d1017c51-3661-11ea-b638-0673fa95f662) 3. runner-u4zrz1by-project-13074486-concurrent-0dlcxb_gitlab-managed-apps(63d78af9-3662-11ea-b638-0673fa95f662) 4. prometheus-deployment-66885d86f-6j9vt_prometheus(da2788bb-3651-11ea-b638-0673fa95f662) 5. nginx-ingress-controller-7dcc95dfbf-ld67q_ingress-nginx(6bf8d8e0-35ca-11ea-b638-0673fa95f662)Y luego los pods se terminan, lo que da como resultado el código de salida 137s.
¿Alguien puede ayudarme a entender el motivo y una posible solución para superar esto?
Gracias :)
Fue capaz de resolver el problema.
Los nodos inicialmente tenían 20 G de volumen ebs y en un tipo de instancia c5.4xlarge. Aumenté el ebs a 50 y 100G, pero eso no ayudó porque seguía viendo el siguiente error:
"El uso del disco en el sistema de archivos de imagen es del 95 %, lo que supera el umbral alto (85 %). Intentando liberar 3022784921 bytes hasta el umbral bajo (80 %)."
Luego cambié el tipo de instancia a c5d.4xlarge, que tenía 400 GB de almacenamiento en caché y proporcionaba 300 GB de EBS. Esto resolvió el error.
Algunos de los trabajos de gitlab fueron para algunas aplicaciones Java que consumían mucho espacio de caché y escribían muchos registros.
El código de salida 137 no significa necesariamente OOMKilled. Indica falla ya que el contenedor recibió SIGKILL (alguna interrupción o 'oom-killer' [OUT-OF-MEMORY])
Si el pod se eliminó OOM, verá la línea debajo cuando describa el pod
State: Terminated Reason: OOMKilled Edite el 2/2/2022. Veo que agregó **kubelet: I0114 03:37:08.639450** 4721 image_gc_manager.go:300] [imageGCManager]: Disk usage on image filesystem is at 95% which is over the high threshold (85%). Trying to free 3022784921 bytes down to the low threshold (80%). y must evict pod(s) to reclaim ephemeral-storage del registro. Por lo general, sucede cuando los módulos de aplicaciones escriben algo en el disco, como archivos de registro. Los administradores pueden configurar cuándo (en qué porcentaje de uso del disco) realizar el desalojo.
Las causas típicas de este código de error pueden ser que el sistema no tenga RAM o que haya fallado una verificación de estado
137 significa que k8s mata el contenedor por alguna razón (puede ser que no pasó la prueba de vida)
El proceso Cod 137 es 128 + 9 (SIGKILL) fue eliminado por una señal externa
Compruebe la memoria del nodo maestro y el perfil de la CPU de Jenkins. en mi caso, era un maestro con mucha memoria y uso de CPU, y los esclavos se reiniciaban con 137.