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개의 기본 포드(사이드킥, 유니콘 및 작업 실행자)의 경우 - 다른 모든 비밀 및 구성 맵 파일 항목에는
r---r----권한, 와
루트:<사용자 그룹>소유권 - 하지만 이 비밀 파일에는
r---r----, 이 아니라면
<사용자>:<사용자 그룹>, 이는 "<user> 이외의 누구도 읽을 수 없음"을 의미합니다. 때로는 작동하지만(microk8s가 사용자 컨텍스트에서 시작되는 경우) 때로는 실패합니다(여기서는 micro8ks의 논리에 대해 전혀 모릅니다).
해결책
chown 루트:<사용자 그룹>이 파일의 경우 문제가 해결됩니다.