☰

containerd 1.4.9 Desc não implementado = serviço desconhecido runtime.v1alpha2.RuntimeService

tag-icon • tag-icon kubernetes containerd
containerd 1.4.9 Desc não implementado = serviço desconhecido runtime.v1alpha2.RuntimeService

Eu instalei containerd 1.4.9no servidor CentOS Steam 8.

com base neste documentohttps://containerd.io/docs/getting-started/. Eu criei um arquivo de configuração padrão containerd config default > /etc/containerd/config.tomlcomo este.

depois de reiniciar o containerd, quando executo crictl pso erro abaixo

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

Como corrigir esse erro? depois de corrigir isso, quero ingressar neste nó no cluster Kubernets 1.21.3usando systemdcfgroup.

Obrigado Sr.

Responder1

Ocorreu o mesmo erro hoje ao atualizar o kubelet nos nós de trabalho. O problema estava na configuração padrão. Observe que o containerd funcionará bem sem qualquer configuração. No meu caso, eu só queria habilitar o systemd_cgroup.

ctr plugin lsmostrou que o plugin cri estava em estado de erro com configuração padrão

Apenas uma configuração em branco com systemd_cgroup corrigiu o problema para mim:

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

Responder2

Contexto de fundo sobre o erro:
Degitlab.cncf.ci/containerd crictl.md documentos

"Pode ser que você esteja usando uma configuração de containerd incorreta (talvez de uma instalação do Docker). Você precisará atualizar sua configuração de containerd para a instância de containerd que está executando."

  • Eu mesmo instalei o docker, então o yum instalou o crictl para investigar diferenças de sintaxe de comando e me deparei com isso.
  • O comando de resolução postado no documento vinculado só funciona se for executado como root, então aqui está uma versão mais genérica.
# 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

Responder3

Este problema está relacionado a erros em plug-ins CRI. Você pode verificar o status do plugin CRI

ctr plugin ls

No passado eu tive o mesmo problema devido ao problema do devmapper, já que o devmapper está configurado como snapshotter CRI padrão, o CRI também obteve erro.

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

O problema desapareceu depois que reconfigurei o snapshotter do devmapper.

Remover a configuração (/etc/containerd/config.toml) também funciona, mas o containerd roda com configuração padrão, o que não era o que eu queria.

Responder4

FWIW, da minha parte, o parâmetro correto do containerd para definir não era, systemd_cgroupmas:

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

qualéuma configuração diferente no arquivo de configuração.

Eesta é a configuração real que os documentos oficiais do Kubernetes dizem para definir como verdadeira:https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd-systemd

informação relacionada