Определение простыми словами
CRI-O — это минималистичный контейнерный рантайм, созданный специально для Kubernetes. Его единственная задача — получать запросы от kubelet через Container Runtime Interface (CRI) и запускать контейнеры, соответствующие стандарту OCI. Никаких лишних демонов, CLI-инструментов для разработчиков или build-функциональности — только запуск и управление жизненным циклом контейнеров внутри кластера.
В отличие от containerd, CRI-O изначально проектировался как «клей» между kubelet и низкоуровневым рантаймом (runc, Kata Containers, gVisor). Проект поддерживается Red Hat, SUSE и Intel и входит в экосистему CNCF.
Сравнение
| Характеристика | CRI-O | containerd | Docker Engine (с dockershim) |
|---|---|---|---|
| Назначение | Только Kubernetes CRI | Универсальный рантайм | Полный цикл разработки |
| Потребление памяти | ~20–30 МБ | ~30–50 МБ | ~100+ МБ (daemon) |
| Поддержка сборки образов | Нет | Через плагины | Да (встроено) |
| Поддержка OCI-runtime | runc, crun, Kata, gVisor | runc, crun, Kata, gVisor | runc |
| Стандартный дистрибутив | OpenShift, Fedora CoreOS | kubeadm (с 1.24+) | Устарел (dockershim удалён) |
Кейсы использования
- Production Kubernetes-кластеры — CRI-O используется в OpenShift 4.x и RHEL-based кластерах как рантайм по умолчанию. Меньше компонентов → меньше поверхность атаки.
- Безопасные мультитенантные среды — интеграция с Kata Containers позволяет запускать контейнеры в лёгких VM-изоляторах без смены CRI-слоя.
- Edge и IoT-кластеры — минимальный footprint делает CRI-O подходящим для k3s и k0s на ресурсоограниченных узлах.
- CI/CD-узлы с жёсткими требованиями к безопасности — политики SELinux и seccomp применяются нативно, без дополнительных оберток.
Негативный пример: CRI-O не подходит для рабочих станций разработчиков — у него нет CLI для ручного запуска контейнеров (аналога docker run). Для локальной разработки используйте Podman или Docker.
Технические детали
CRI-O устанавливается как системный сервис и взаимодействует с kubelet через Unix-сокет. Конфигурация хранится в /etc/crio/crio.conf.
# Установка CRI-O на Ubuntu 22.04 (Kubernetes 1.29)
OS=xUbuntu_22.04
VERSION=1.29
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/crio.list
apt-get update
apt-get install -y cri-o cri-o-runc
systemctl enable --now crio
# Проверка статуса и версии
crio version
systemctl status crio
# Просмотр запущенных контейнеров через crictl
crictl ps
crictl pods
crictl images
# Изменить дефолтный low-level runtime (crun вместо runc)
# /etc/crio/crio.conf.d/10-runtime.conf
# [crio.runtime]
# default_runtime = "crun"
Логи CRI-O пишутся в journald: journalctl -u crio -f. Для отладки проблем с образами используйте crictl pull <image> и crictl inspect <container-id>.
🔥 Где это применяется
Частые вопросы
Чем CRI-O отличается от containerd?
CRI-O разработан исключительно для Kubernetes и не имеет собственного CLI для разработчиков. containerd более универсален — он поддерживает плагины и используется не только в Kubernetes, но и как самостоятельный рантайм. На практике оба показывают сопоставимую производительность; выбор часто определяется дистрибутивом: OpenShift использует CRI-O, большинство kubeadm-кластеров — containerd.
Можно ли использовать CRI-O без Kubernetes?
Технически да, но это лишено смысла: CRI-O не предоставляет пользовательского CLI для запуска контейнеров. Для работы вне Kubernetes используйте Podman или Docker.
Поддерживает ли CRI-O rootless-контейнеры?
Поддержка rootless-режима в CRI-O ограничена и зависит от версии ядра Linux и конфигурации namespace. Для полноценного rootless-запуска контейнеров за пределами Kubernetes лучше подходит Podman с user namespace.