Я развернул экземпляр Gitlab 12.10 на microk8s 1.18 на моем сервере Ubuntu 19.10. Я неоднократно замечал, что некоторые из модулей переходят в статус CrashBackoffLoop или Init:CrashBackoffLoop с такими сообщениями об ошибках, как:
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
К сожалению, я не уверен, является ли эта проблема специфической для Gitlab или общей проблемой с моим кластером microk8s. Не всегда выходит из строя один и тот же компонент. Чаще всего выходит из строя один и тот же компонент. gitlab-runner, sidekiq и unicorn, но я также видел других, у которых время от времени возникала похожая ошибка «нет такого файла или каталога».
Когда я удаляю сбойный модуль, новый, который создается, запускается без проблем, затем, кажется, какое-то время все работает, пока один или несколько модулей снова не выйдут из строя.
Есть идеи, что может быть причиной этого?
У меня такая же проблема; Первоначально проблема была устранена при полной перезагрузке сервера, но затем она периодически возвращалась.
Наконец, выяснилось, что проблема связана с правами доступа к "необработанным" файлам секретов (например,
/var/snap/microk8s/common/var/lib/kubelet/pods/<pod_guid>/volume-subpaths/task-runner-secrets/task-runner/<file_no>) for the 3 main pods (sidekick, unicorn & task-runner) - all other secret and config map file entries had
r--r-----permissions, with
root:<user group>ownership - but these secret files also had
r--r-----, but for
<user>:<user group>, which means "not readable for anyone but <user>" - which sometimes works (if microk8s gets started in the user context) but sometimes fails (no idea about the logic of micro8ks here)
chown root:<user group>for these files fixes the issue