Implantei uma instância do Gitlab 12.10 no microk8s 1.18 em meu servidor Ubuntu 19.10. Tenho notado repetidamente que alguns pods entram em status CrashBackoffLoopou Init:CrashBackoffLoopcom mensagens de erro como as seguintes:
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
Infelizmente, não tenho certeza se esse problema é específico do Gitlab ou um problema geral com meu cluster microk8s. Nem sempre é o mesmo componente que trava, os que parecem falhar com mais frequência são gitlab-runner, sidekiqe unicorn, mas também vi outros com um erro semelhante "nenhum arquivo ou diretório" de tempos em tempos.
Quando eu excluo um pod com falha, o novo que é criado inicia sem problemas, então tudo parece funcionar por um tempo até que um ou mais pods travem novamente.
Alguma ideia do que pode estar causando isso?
Responder1
Eu tive o mesmo problema; inicialmente, uma reinicialização completa do servidor corrigiu o problema, mas depois retornou de forma intermitente.
Encontrando
Finalmente, acabou sendo um problema de permissão com os arquivos secretos "brutos" (como
/var/snap/microk8s/common/var/lib/kubelet/pods/<pod_guid>/volume-subpaths/task-runner-secrets/task-runner/<file_no>) para os três pods principais (sidekick, unicorn e task-runner) - todas as outras entradas do arquivo de mapa secreto e de configuração tinham
r--r-----permissões, com
root:<grupo de usuários>propriedade - mas esses arquivos secretos também tinham
r--r-----, mas pelo
<usuário>:<grupo de usuários>, que significa "não legível para ninguém, exceto <usuário>" - o que às vezes funciona (se o microk8s for iniciado no contexto do usuário), mas às vezes falha (não tenho ideia sobre a lógica do micro8ks aqui)
Solução
raiz chown:<grupo de usuários>para esses arquivos corrige o problema