☰

containerd 1.4.9 Nicht implementiert desc = unbekannter Dienst runtime.v1alpha2.RuntimeService

tag-icon • tag-icon kubernetes containerd
containerd 1.4.9 Nicht implementiert desc = unbekannter Dienst runtime.v1alpha2.RuntimeService

Ich habe Steam 8 auf einem CentOS-Server installiert containerd 1.4.9.

basierend auf diesem Dokumenthttps://containerd.io/docs/getting-started/. Ich habe eine Standardkonfigurationsdatei containerd config default > /etc/containerd/config.tomlwie diese erstellt.

nach dem Neustart von containerd, wenn ich crictl pses ausführe, wird der folgende Fehler ausgegeben

FATA[0000] listing containers failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService

Wie behebe ich diesen Fehler? Nachdem ich das behoben habe, möchte ich diesen Knoten 1.21.3mithilfe von systemdcfgroup dem Kubernetes-Cluster hinzufügen.

Danke, SR

Antwort1

Hatte heute den gleichen Fehler beim Upgrade von Kubelet auf den Worker-Knoten. Das Problem lag in der Standardkonfiguration. Beachten Sie, dass Containerd ohne Konfiguration einwandfrei läuft. In meinem Fall wollte ich nur systemd_cgroup aktivieren.

ctr plugin lszeigte, dass das CRI-Plugin mit der Standardkonfiguration im Fehlerzustand war

Nur eine leere Konfiguration mit systemd_cgroup hat das Problem für mich behoben:

cat > /etc/containerd/config.toml <<EOF
[plugins."io.containerd.grpc.v1.cri"]
  systemd_cgroup = true
EOF
systemctl restart containerd

Antwort2

Hintergrundkontext zum Fehler:
Ausgitlab.cncf.ci/containerd crictl.md-Dokumente

„Dies könnte daran liegen, dass Sie eine falsche Containerd-Konfiguration verwenden (möglicherweise von einer Docker-Installation). Sie müssen Ihre Containerd-Konfiguration auf die Containerd-Instanz aktualisieren, die Sie ausführen.“

  • Ich selbst hatte Docker und dann Yum installiert, um Crictl zu installieren und die Unterschiede in der Befehlssyntax zu untersuchen, und bin dabei auf Folgendes gestoßen.
  • Der im verlinkten Dokument veröffentlichte Auflösungsbefehl funktioniert nur, wenn er als Root ausgeführt wird, hier also eine allgemeinere Version.
# Backup old containerd config (optional)
sudo mv /etc/containerd/config.toml /etc/containerd/config.bak

# Regenerate containerd config
sudo containerd config default | sudo tee /etc/containerd/config.toml

# Restart containerd
sudo systemctl restart containerd

# The above got it to work for me; but with some warnings 
# and ignorable errors that looked this this: 
sudo crictl ps
# WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock]. As the default settings are now deprecated, you should set the endpoint instead.
# ERRO[0002] connect endpoint 'unix:///var/run/dockershim.sock', make sure you are running as root and the endpoint has been started: context deadline exceeded
# WARN[0002] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock]. As the default settings are now deprecated, you should set the endpoint instead.
# ERRO[0004] connect endpoint 'unix:///var/run/dockershim.sock', make sure you are running as root and the endpoint has been started: context deadline exceeded
# CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID
# ^-- The last line represents correct output, which is why 
# I say ignorable warnings/errors, even the post command 
# exit code seeable using 'echo $?' exit code shows success

# What cleaned up the errors for me was copy pasting the following
echo """
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
""" | sudo tee /etc/crictl.yaml

docker ps
# ^-- no more errors :)

# Note others may need to run one of these instead, based on their
# system's config, keep trying docker ps until one config works
echo """
runtime-endpoint: unix:///var/run/crio/crio.sock
image-endpoint: unix:///var/run/crio/crio.sock
""" | sudo tee /etc/crictl.yaml

echo """
runtime-endpoint: unix:///var/run/dockershim.sock
image-endpoint: unix:///var/run/dockershim.sock
""" | sudo tee /etc/crictl.yaml

Antwort3

Dieses Problem betraf Fehler in CRI-Plugins. Sie können den Status des CRI-Plugins überprüfen

ctr plugin ls

In der Vergangenheit hatte ich aufgrund eines Devmapper-Problems dasselbe Problem. Da der Devmapper als Standard-CRI-Snapshotter konfiguriert ist, trat auch beim CRI ein Fehler auf.

TYPE                                  ID                       PLATFORMS      STATUS
io.containerd.snapshotter.v1          devmapper                linux/amd64    error
io.containerd.grpc.v1                 cri                      linux/amd64    error

Das Problem war behoben, nachdem ich den Devmapper-Snapshotter neu konfiguriert hatte.

Das Entfernen der Konfiguration (/etc/containerd/config.toml) funktioniert ebenfalls, aber Containerd läuft mit der Standardkonfiguration, was nicht meinen Wünschen entsprach.

Antwort4

Der richtige Parameter von containerd zum Setzen war meiner Meinung nach nicht, systemd_cgroupsondern:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            #[...]
            SystemdCgroup = true

welcheIsteine andere Einstellung in der Konfigurationsdatei.

UndDies ist die tatsächliche Einstellung, die laut der offiziellen Kubernetes-Dokumentation auf „true“ gesetzt werden soll:https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd-systemd

verwandte Informationen