我已經在 Ubuntu 19.10 伺服器上的 microk8s 1.18 上部署了 Gitlab 12.10 實例。我多次注意到某些 Pod 進入狀態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，但我也時不時看到其他元件出現類似的「沒有這樣的檔案或目錄」錯誤。
當我刪除一個崩潰的 Pod 時，創建的新 Pod 會毫無問題地啟動，然後一切似乎都會工作一段時間，直到一個或多個 Pod 再次崩潰。
知道是什麼原因造成的嗎？
答案1
我有同樣的問題;最初，完全重新啟動伺服器修復了該問題，但隨後又間歇性地返回。
尋找
最後，它變成了「原始」機密文件的權限問題（例如
/var/snap/microk8s/common/var/lib/kubelet/pods/<pod_guid>/volume-subpaths/task-runner-secrets/task-runner/<file_no>）對於 3 個主要 pod（sidekick、unicorn 和 task-runner）- 所有其他秘密和配置映射文件條目都有
r--r-----權限，與
root:<使用者群組>所有權 - 但這些秘密文件也有
r--r-----， 但對於
<使用者>:<使用者群組>，這意味著「除了 <user> 以外的任何人都無法讀取」 - 有時可以工作（如果 microk8s 在用戶上下文中啟動），但有時會失敗（不知道這裡的 micro8ks 邏輯）
解決方案
chown root:<用戶群組>對於這些文件修復了問題