我在 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） - 所有其他 secret 和配置映射文件条目都有
唷——唷——权限，
root:<用户组>所有权——但这些秘密文件也有
唷——唷——， 但对于
<用户>:<用户组>，这意味着“除了 <user> 之外的任何人都无法读取”——这有时会有效（如果 microk8s 在用户上下文中启动），但有时会失败（这里不知道 micro8ks 的逻辑）
解决方案
chown root:<用户组>这些文件修复了这个问题