Ubuntu 19.10 サーバーの microk8s 1.18 に Gitlab 12.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 つ以上のポッドが再びクラッシュするまで、すべてがしばらくは正常に動作するように見えます。
この原因は何だと思いますか?
答え1
私も同じ問題を抱えていました。最初はサーバーを完全に再起動すると問題は解決しましたが、その後は断続的に再発しました。
発見
最終的に、それは「生の」シークレットファイル（例えば
/var/snap/microk8s/common/var/lib/kubelet/pods/<pod_guid>/volume-subpaths/task-runner-secrets/task-runner/<file_no>）は3つのメインポッド（サイドキック、ユニコーン、タスクランナー）用です。他のすべてのシークレットおよび構成マップファイルのエントリは
r--r-----権限、
root:<ユーザーグループ>所有権はあったが、これらの秘密ファイルには
r--r-----、しかし、
<ユーザー>:<ユーザーグループ>これは「<user> 以外には読み取れない」という意味です。これは時々機能しますが (microk8s がユーザー コンテキストで起動された場合)、失敗することもあります (ここでは micro8ks のロジックについてはわかりません)。
解決
chown root:<ユーザーグループ>これらのファイルでは問題が修正されます