Ich habe eine Gitlab 12.10-Instanz auf microk8s 1.18 auf meinem Ubuntu 19.10-Server bereitgestellt. Mir ist wiederholt aufgefallen, dass einige der Pods in den Status CrashBackoffLoopoder Init:CrashBackoffLoopmit Fehlermeldungen wie den folgenden wechseln:
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
Leider bin ich mir nicht sicher, ob dieses Problem spezifisch für Gitlab ist oder ein allgemeines Problem mit meinem Microk8s-Cluster. Es ist nicht immer dieselbe Komponente, die abstürzt. Am häufigsten scheinen gitlab-runner, sidekiqund zu versagen unicorn, aber ich habe auch von Zeit zu Zeit andere mit einem ähnlichen Fehler „keine solche Datei oder kein solches Verzeichnis“ gesehen.
Wenn ich einen abgestürzten Pod lösche, startet der neue, der erstellt wird, ohne Probleme, dann scheint eine Zeit lang alles zu funktionieren, bis einer oder mehrere Pods erneut abstürzen.
Irgendeine Idee, was die Ursache sein könnte?
Antwort1
Ich hatte das gleiche Problem. Es wurde zunächst durch einen vollständigen Neustart des Servers behoben, danach trat es jedoch zeitweise erneut auf.
Finden
Schließlich stellte sich heraus, dass es sich um ein Berechtigungsproblem mit den "rohen" Secrets-Dateien handelte (wie
/var/snap/microk8s/common/var/lib/kubelet/pods/<pod_guid>/volume-subpaths/task-runner-secrets/task-runner/<file_no>) für die 3 Haupt-Pods (Sidekick, Unicorn und Task-Runner) - alle anderen geheimen und Konfigurations-Map-Dateieinträge hatten
r--r-----Berechtigungen, mit
root:<Benutzergruppe>Eigentum - aber diese geheimen Akten hatten auch
r--r-----, aber für
<Benutzer>:<Benutzergruppe>, was bedeutet „für niemanden außer <Benutzer> lesbar“ – was manchmal funktioniert (wenn microk8s im Benutzerkontext gestartet wird), manchmal aber fehlschlägt (keine Ahnung von der Logik von micro8ks hier)
Lösung
chown root:<Benutzergruppe>für diese Dateien behebt das Problem