![containerd 1.4.9 Не реализовано desc = unknown service runtime.v1alpha2.RuntimeService](https://rvso.com/image/769308/containerd%201.4.9%20%D0%9D%D0%B5%20%D1%80%D0%B5%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BE%20desc%20%3D%20unknown%20service%20runtime.v1alpha2.RuntimeService.png)
Я установил containerd 1.4.9
на сервер CentOS Steam 8.
на основе этого документаhttps://containerd.io/docs/getting-started/. Я создал файл конфигурации по умолчанию, containerd config default > /etc/containerd/config.toml
вот такой.
после перезапуска containerd, когда я запускаю crictl ps
его выдает ошибку ниже
FATA[0000] listing containers failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService
Как исправить эту ошибку? После исправления я хочу присоединить этот узел к кластеру Kubernets 1.21.3
с помощью systemd
cfgroup.
Спасибо, SR
решение1
Сегодня при обновлении kubelet на рабочих узлах возникла та же ошибка. Проблема была в конфигурации по умолчанию. Обратите внимание, что containerd будет работать нормально без какой-либо конфигурации. В моем случае я просто хотел включить systemd_cgroup.
ctr plugin ls
показал, что плагин cri находится в состоянии ошибки с конфигурацией по умолчанию
Для меня проблема была решена только пустой конфигурацией с systemd_cgroup:
cat > /etc/containerd/config.toml <<EOF
[plugins."io.containerd.grpc.v1.cri"]
systemd_cgroup = true
EOF
systemctl restart containerd
решение2
Фоновый контекст Об ошибке:
Отgitlab.cncf.ci/containerd crictl.md документы
«Возможно, вы используете неправильную конфигурацию containerd (возможно, из установки Docker). Вам необходимо обновить конфигурацию containerd до экземпляра containerd, который вы запускаете».
- Я сам установил docker, затем yum установил crictl, чтобы исследовать различия в синтаксисе команд, и столкнулся с этим.
- Команда разрешения, размещенная в связанном документе, работает только при запуске от имени пользователя root, поэтому вот более общая версия.
# 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
решение3
Эта проблема связана с ошибками в плагинах CRI. Вы можете проверить статус плагина CRI
ctr plugin ls
Раньше у меня возникала та же проблема из-за неполадок с devmapper, поскольку devmapper настроен как средство создания снимков CRI по умолчанию, CRI также получал ошибку.
TYPE ID PLATFORMS STATUS
io.containerd.snapshotter.v1 devmapper linux/amd64 error
io.containerd.grpc.v1 cri linux/amd64 error
Проблема исчезла после того, как я перенастроил devmapper snapshotter.
Удаление конфигурации (/etc/containerd/config.toml) тоже работает, но containerd работает с конфигурацией по умолчанию, а это не то, что мне нужно.
решение4
Кстати, с моей стороны правильный параметр containerd для установки был не systemd_cgroup
таким:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
#[...]
SystemdCgroup = true
которыйявляетсядругая настройка в файле конфигурации.
ИЭто фактическая настройка, которую официальная документация Kubernetes предписывает установить как true:https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd-systemd