Я развернул экземпляр 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, но я также время от времени видел и другие с похожей ошибкой "нет такого файла или каталога".
Когда я удаляю аварийно завершившийся модуль, новый созданный модуль запускается без проблем, затем все работает какое-то время, пока один или несколько модулей снова не выходят из строя.
Есть идеи, что может быть причиной этого?
решение1
У меня была та же проблема; изначально ее решила полная перезагрузка сервера, но затем она периодически возвращалась.
Нахождение
Наконец, выяснилось, что проблема была в разрешениях на доступ к «сырым» файлам секретов (например,
/var/snap/microk8s/common/var/lib/kubelet/pods/<pod_guid>/volume-subpaths/task-runner-secrets/task-runner/<file_no>) для 3 основных модулей (sidekick, unicorn и task-runner) - все остальные записи в файлах секретов и конфигурационных карт были
р--р-----разрешения, с
root:<группа пользователей>право собственности - но эти секретные файлы также имели
р--р-----, но для
<пользователь>:<группа пользователей>, что означает «недоступно для чтения никому, кроме <пользователя>» - что иногда работает (если microk8s запускается в контексте пользователя), но иногда дает сбой (понятия не имею о логике micro8ks здесь)
Решение
chown root:<группа пользователей>для этих файлов исправляет проблему