CRI-O (Container Runtime)

CRI-O — это лёгкая контейнерная среда выполнения (Container Runtime), специально созданная для Kubernetes. Её основная задача — обеспечивать запуск и управление контейнерами, строго следуя интерфейсу Container Runtime Interface (CRI), который разработан в Kubernetes.

Главная идея CRI-O — минимализм и совместимость. В отличие от Docker, который включает массу дополнительных инструментов, CRI-O делает только то, что нужно Kubernetes: принимает инструкции от kubelet, разворачивает контейнеры через OCI-совместимые runtime (например,

или ), управляет образами и отслеживает жизненный цикл подов.

Ключевые особенности:

• Интеграция с Kubernetes: CRI-O разрабатывался как «нативный» runtime для Kubernetes, поэтому обновления и совместимость гарантированы.
• Поддержка OCI-стандарта: любые контейнерные образы и runtime, соответствующие спецификациям Open Container Initiative, могут использоваться без доработок.
• Безопасность и лёгкость: в составе нет лишних функций, что снижает поверхность атак и уменьшает потребление ресурсов.
• Гибкость: можно использовать разные runtime — от стандартного
  Копироватьrunc
  до изолированных сред вроде Kata Containers для запуска «супербезопасных» подов.

Чем отличается от Docker:

Раньше Kubernetes по умолчанию работал через Docker, но со временем Docker был признан избыточным для этой задачи. Docker — это целая экосистема (CLI, билд образов, демон), а CRI-O выполняет только роль «исполнителя» контейнеров. Поэтому современные Kubernetes-кластеры чаще используют CRI-O или containerd.

Пример конфигурации (фрагмент):

Копировать# Проверка используемого runtime в Kubernetes
kubectl get node -o jsonpath='{.items[*].status.nodeInfo.containerRuntimeVersion}'
# Вывод может быть: cri-o://1.28.0

Где применяется:

CRI-O особенно популярен в дистрибутивах Kubernetes, ориентированных на корпоративный сегмент и безопасность: OpenShift, OKD, K3s. Он даёт предсказуемое и стабильное поведение контейнеров при минимальных накладных расходах.

Для клиента CRI-O означает более лёгкий, быстрый и безопасный Kubernetes-кластер без лишних компонентов.

---

Сравнение CRI-O, Docker и containerd

Характеристика	CRI-O	Docker	containerd
Назначение	Лёгкий runtime для Kubernetes	Полная платформа контейнеризации (CLI, API, build, runtime)	Контейнерный runtime общего назначения
Интеграция с Kubernetes	Нативная (создан специально для CRI)	Поддержка через CRI-shim (устарело в новых версиях)	Хорошая, но менее специализированная
Стандарты OCI	Полная поддержка (образы и runtime)	Частично, больше завязано на экосистему Docker	Поддержка OCI
Функциональность	Только запуск и управление контейнерами	Построение образов, управление сетью, CLI, API	Запуск контейнеров, управление образами
Безопасность	Минимальный набор функций → меньше рисков	Большая поверхность атаки из-за множества сервисов	Умеренная, больше возможностей, чем CRI-O
Ресурсы	Лёгкий, оптимизированный под K8s	Тяжелее, так как включает лишние компоненты	Средний уровень
Где применяется	OpenShift, OKD, корпоративные K8s	Локальная разработка, CI/CD, legacy-кластеры	GKE, k3s, многие современные кластеры

---

📌 Кратко:

• CRI-O — для Kubernetes-only (минимализм, безопасность).
• Docker — «всё в одном» (но избыточен для K8s).
• containerd — компромисс: универсальный runtime, широко используемый в облаках.

---

Жизненный цикл контейнера в Kubernetes с CRI-O

Когда в Kubernetes создаётся Pod, запускается последовательность взаимодействий:

1. kubelet — агент на каждом узле — получает задание от Control Plane: поднять Pod.
2. kubelet обращается к CRI (Container Runtime Interface) — это API, через который он общается с контейнерным рантаймом.
3. CRI-O выступает как реализация CRI. Он принимает запрос от kubelet и проверяет:
   • есть ли нужный образ контейнера,
   • нужно ли его загрузить из реестра (Docker Hub, Quay, Harbor и т.п.),
   • инициализирует запуск.
4. Для непосредственного старта используется runc (или другой OCI runtime). Он создаёт изолированный процесс контейнера, настраивает namespaces, cgroups и всё окружение.
5. После запуска CRI-O сообщает kubelet, что контейнер готов. kubelet обновляет статус Pod в etcd и API-сервере.
6. Если контейнер завершится с ошибкой, CRI-O передаст информацию обратно в kubelet, который в зависимости от политики перезапустит Pod или пометит его как упавший.

---

Что важно понимать:

• CRI-O ничего не строит и не управляет сетью — только запускает контейнеры. Всё остальное (сети, тома, секреты) Kubernetes делегирует CNI и CSI-плагинам.
• Такой минимализм делает CRI-O более надёжным и безопасным, чем Docker, где было много «лишних» функций.
• Это решение стало стандартом в корпоративных Kubernetes-дистрибутивах (например, OpenShift).