Implementé una instancia de Gitlab 12.10 en microk8s 1.18 en mi servidor Ubuntu 19.10. He notado repetidamente que algunos de los pods entran en estado CrashBackoffLoopo Init:CrashBackoffLoopcon mensajes de error como el siguiente:
Message: failed to create containerd task: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:424: container init caused \"rootfs_linux.go:58: mounting \\\"/var/snap/microk8s/common/var/lib/kubelet/pods/de572f6b-f738-4b1a-ae02-80fef062cabe/volume-subpaths/sidekiq-secrets/dependencies/2\\\" to rootfs \\\"/var/snap/microk8s/common/run/containerd/io.containerd.runtime.v1.linux/k8s.io/3ae6fc33b02192c3940af4ebc991a47b1fd0afc2533901af50ae5a5f93585d1c/rootfs\\\" at \\\"/var/snap/microk8s/common/run/containerd/io.containerd.runtime.v1.linux/k8s.io/3ae6fc33b02192c3940af4ebc991a47b1fd0afc2533901af50ae5a5f93585d1c/rootfs/srv/gitlab/config/secrets.yml\\\" caused \\\"no such file or directory\\\"\"": unknown
Desafortunadamente, no estoy seguro de si este problema es específico de Gitlab o un problema general con mi clúster microk8s. No siempre es el mismo componente el que falla, los que parecen fallar con mayor frecuencia son y gitlab-runner, pero también he visto otros con un error similar de "no existe tal archivo o directorio" de vez en cuando.sidekiqunicorn
Cuando elimino un pod bloqueado, el nuevo que se crea comienza sin problemas, luego todo parece funcionar por un tiempo hasta que uno o más pods fallan nuevamente.
¿Alguna idea de lo que podría estar causando esto?
Respuesta1
Yo tuve el mismo problema; Inicialmente, un reinicio completo del servidor lo solucionó, pero luego regresó de manera intermitente.
Hallazgo
Finalmente, resultó ser un problema de permisos con los archivos secretos "sin procesar" (como
/var/snap/microk8s/common/var/lib/kubelet/pods/<pod_guid>/volume-subpaths/task-runner-secrets/task-runner/<file_no>) para los 3 pods principales (compañero, unicornio y corredor de tareas): todas las demás entradas de archivos de mapas secretos y de configuración tenían
r--r-----permisos, con
raíz:<grupo de usuarios>propiedad - pero estos archivos secretos también tenían
r--r-----, pero para
<usuario>:<grupo de usuarios>, que significa "no legible para nadie excepto <usuario>", que a veces funciona (si microk8s se inicia en el contexto del usuario) pero a veces falla (no tengo idea de la lógica de micro8ks aquí)
Solución
raíz chown:<grupo de usuarios>para estos archivos soluciona el problema