Bug 53963

Summary: Не удается обновиться с 1.30 до 1.31: crio.service не перезапускается
Product: Sisyphus Reporter: Artem Varaksa <varaksaaa>
Component: cri-o1.31Assignee: geochip <geochip>
Status: CLOSED NOTABUG QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: geochip
Version: unstable   
Hardware: x86_64   
OS: Linux   
Attachments:
Description Flags
crio.log none

Description Artem Varaksa 2025-04-23 18:40:01 MSK 
Created attachment 18281 [details]
crio.log

Шаги
====

1. Настроить кластер kubernetes1.30
2. $ kubectl drain control-plane1 --ignore-daemonsets
3. # UPDATE=1.31
4. # apt-get install kubernetes${UPDATE}-{kubeadm,kubelet,crio} cri-{o,tools}${UPDATE}
5. # systemctl daemon-reload
6. # systemctl restart crio
... (дальшейшие шаги обновления не требуются)

Фактический результат
=====================

6 шаг зависает. В journalctl выводятся сообщения вида (полный journalctl перезапуска приложен):

> ...
> kubehosta crio[7471]: time="2025-04-23 18:09:09.525651874+03:00" level=error msg="Failed to update container state for 452c4473cc4a97483daa7d4fcbd304ccab8adbdba748c59149929ea98ee41707: stdout: , stderr: "
> ...
> kubehosta crio[7471]: time="2025-04-23 18:09:19.602838047+03:00" level=warning msg="Stopping container 452c4473cc4a97483daa7d4fcbd304ccab8adbdba748c59149929ea98ee41707 with stop signal timed out. Killing..."
> kubehosta crio[7471]: time="2025-04-23 18:09:19.605332359+03:00" level=error msg="Killing container 452c4473cc4a97483daa7d4fcbd304ccab8adbdba748c59149929ea98ee41707 failed: `/usr/bin/crun --root /run/crun --systemd-cgroup kill 452c4473cc4a97483daa7d4fcbd304ccab8adbdba748c59149929ea98ee41707 KILL` failed: error opening file `/run/crun/452c4473cc4a97483daa7d4fcbd304ccab8adbdba748c59149929ea98ee41707/status`: No such file or directory\n : exit status 1"
> ...

Примечание: в данном случае ошибка в логе:

> Error loading CNI config list file /etc/cni/net.d/100-crio-bridge.conflist: error parsing configuration list: invalid character '#' looking for beginning of value

не влияет, воспроизводится и при корректной конфигурации.

Ожидаемый результат
===================

Успешный перезапуск сервиса crio.

Дополнительно
=============

Если разворачивать кластер сразу с 1.31, он запускается и работает.
В p11+378611 проверено, что успешно проходит и обновление до 1.32, так же как и 1.28 -> 1.29 -> 1.30. Проблема только с 1.30 -> 1.31.

Воспроизводимость
=================

Воспроизводится на виртуальных машинах:

[sisyphus] ALT Server 11.0 beta 20250213 x86_64
cri-o1.30-1.30.12-alt1
cri-o1.31-1.31.7-alt1

[p11+378611] ALT Server 11.0 beta 20250213 x86_64
cri-o1.30-1.30.10-alt1
cri-o1.31-1.31.5-alt1

[p11] ALT Server 11.0 beta 20250213 x86_64
cri-o1.30-1.30.5-alt1
cri-o1.31-1.31.0-alt1
Comment 1 geochip@altlinux.org 2025-05-09 04:09:06 MSK 
Это связано с тем, что в версии cri-o 1.30 по умолчанию используется runc в качестве рантайма, а версии cri-o 1.31 апстрим сменил рантайм по умолчанию на crun.

/etc/crio/crio.conf
```
...
 # default_runtime is the _name_ of the OCI runtime to be used as the default.
 # The name is matched against the runtimes map below.
-# default_runtime = "runc"
+# default_runtime = "crun"
...
-[crio.runtime.runtimes.runc]
+[crio.runtime.runtimes.crun]
 runtime_path = ""
 runtime_type = "oci"
-runtime_root = "/run/runc"
+runtime_root = "/run/crun"
+inherit_default_runtime = false
 runtime_config_path = ""
-container_min_memory = "12MiB"
+container_min_memory = "500KiB"
 monitor_path = "/usr/bin/conmon"
 monitor_cgroup = "system.slice"
...
```

Соответственно, если конфиг /etc/crio/crio.conf не менялся после установки пакета, то по умолчанию используется runc, и данные рантайма хранятся в `/run/runc`, а после обновления с 1.30 до 1.31 теперь по умолчанию используется crun и данные ожидаются в `/run/crun`.

Если перед обновлением до cri-o 1.31 зафиксировать в конфиге

```
default_runtime = "runc"
``

то crio.service запустится успешно.
Comment 2 Artem Varaksa 2025-05-16 20:23:17 MSK 
Проверил, если выполнить

# sed 's|# default_runtime = "runc"|default_runtime = "runc"|' -i /etc/crio/crio.conf

перед установкой новых пакетов на каждой ноде, обновление проходит успешно.

Если такое поведение следует считать ожидаемым, просьба закрыть ошибку.