CRI-O следует циклам выпуска Kubernetes относительно его второстепенных версий ( 1.xy
). Выпуски патчей ( 1.xz
) для Kubernetes не синхронизируются с релизами CRI-O, поскольку они запланированы на каждый месяц, тогда как CRI-O предоставляет их только в случае необходимости. Если выпуск Kubernetes завершается, то соответствующая версия CRI-O может рассматриваться таким же образом.
Это означает, что CRI-O также следует политике отклонения версий выпуска Kubernetes n-2
, когда дело доходит до градации, устаревания или удаления функций. Это также относится к функциям, независимым от Kubernetes. Тем не менее, резервное копирование функций в поддерживаемые ветки выпуска, независимые от Kubernetes или других инструментов, таких как cri-tools, по-прежнему возможно. Это позволяет CRI-O отделиться от цикла выпуска Kubernetes и иметь достаточную гибкость при реализации новых функций. Каждая функция, которую необходимо перенести, будет приниматься сообществом в каждом конкретном случае, при этом общая матрица совместимости не должна нарушаться.
Для получения дополнительной информации посетите Политику отклонения версий Kubernetes.
ЦНИИ-О | Кубернетес | Статус обслуживания |
---|---|---|
main филиал | master ветка | Активно реализуются функции из основного репозитория Kubernetes. |
ветка release-1.x ( v1.xy ) | ветка release-1.x ( v1.xz ) | Обслуживание осуществляется вручную, переноситься будут только исправления ошибок. |
Примечания к выпуску CRI-O создаются вручную и могут быть постоянно доступны на нашем веб-сайте GitHub.
CRI-O предназначен для обеспечения пути интеграции между средами выполнения, совместимыми с OCI, и Kubelet. В частности, он реализует интерфейс времени выполнения контейнера Kubelet (CRI), используя среды выполнения, совместимые с OCI. Объем CRI-O привязан к объему CRI.
На высоком уровне мы ожидаем, что объем CRI-O будет ограничен следующими функциями:
CRI-O — это реализация Kubernetes Container Runtime Interface (CRI), которая позволит Kubernetes напрямую запускать контейнеры Open Container Initiative (OCI) и управлять ими.
Планируется использовать проекты OCI и лучшие в своем классе библиотеки для различных аспектов:
В настоящее время он находится в активной разработке в сообществе Kubernetes посредством предложения по дизайну. Вопросы и проблемы следует поднимать в Slack-канале Kubernetes.
Дорожную карту, описывающую направление CRI-O, можно найти здесь. Проект отслеживает все текущие усилия в рамках проекта Feature Roadmap GitHub.
CI CRI-O разделен между действиями GitHub и OpenShift CI (Prow). Соответствующие образы виртуальных машин, используемые для заданий Prob, периодически создаются в заданиях:
Задания хранятся в репозитории openshift/release и определяют рабочие процессы, используемые для конкретных заданий. Фактические определения заданий можно найти в том же репозитории в разделе ci-operator/jobs/cri-o/cri-o/cri-o-cri-o-main-presubmits.yaml для main
ветки, а также соответствующие файлы для ветки выпуска. Конфигурация базового образа для этих заданий доступна в том же репозитории в разделе ci-operator/config/cri-o/cri-o.
Команда | Описание |
---|---|
крио(8) | Демон среды выполнения контейнера OCI Kubernetes |
Примерами инструментов командной строки для взаимодействия с CRI-O (или другими средами выполнения, совместимыми с CRI) являются Crictl и Podman.
Файл | Описание |
---|---|
крио.conf(5) | Файл конфигурации CRI-O |
политика.json(5) | Файл(ы) политики проверки подписи |
реестры.conf(5) | Файл конфигурации реестров |
хранилище.conf(5) | Файл конфигурации хранилища |
Процесс обеспечения безопасности для сообщения об уязвимостях описан в SECURITY.md.
Вы можете настроить CRI-O для внедрения перехватчиков OCI при создании контейнеров.
Мы предоставляем полезную информацию для передачи операций и разработок в отношении инфраструктуры, использующей CRI-O.
Для асинхронного общения и длительных обсуждений используйте задачи и запросы на включение в репозитории GitHub. Это будет лучшее место для обсуждения дизайна и реализации.
Для общения в чате у нас есть канал в Kubernetes, к которому каждый может присоединиться и поговорить о разработке.
Мы поддерживаем тщательно подобранный список ссылок, связанных с CRI-O. Нашли ли вы в сети что-нибудь интересное о проекте? Отлично, смело открывайте пиар и добавляйте его в список.
Чтобы установить CRI-O
, вы можете следовать нашему руководству по установке. Альтернативно, если вы предпочитаете собирать CRI-O
из исходного кода, ознакомьтесь с нашим руководством по установке.
Прежде чем начать, вам нужно запустить CRI-O.
Вы можете запустить локальную версию Kubernetes с CRI-O
используя local-up-cluster.sh
:
CGROUP_DRIVER=systemd
CONTAINER_RUNTIME=remote
CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/crio/crio.sock'
./hack/local-up-cluster.sh
Дополнительные инструкции по запуску CRI-O
см. на нашей странице руководства.
CRI-O по умолчанию предоставляет API gRPC для реализации интерфейса среды выполнения контейнера (CRI) Kubernetes. Помимо этого, существует дополнительный HTTP API для получения дополнительной информации о состоянии выполнения CRI-O. Имейте в виду, что этот API не считается стабильным, и в производственных сценариях его не следует использовать.
В работающем экземпляре CRI-O мы можем получить доступ к API через инструмент передачи HTTP, такой как Curl:
$ sudo curl -v --unix-socket /var/run/crio/crio.sock http://localhost/info | jq
{
"storage_driver": "btrfs",
"storage_root": "/var/lib/containers/storage",
"cgroup_driver": "systemd",
"default_id_mappings": { ... }
}
В настоящее время поддерживаются следующие точки входа API:
Путь | Тип контента | Описание |
---|---|---|
/info | application/json | Общая информация о среде выполнения, например, storage_driver и storage_root . |
/containers/:id | application/json | Выделенная информация о контейнере, такая как name , pid и image . |
/config | application/toml | Полная конфигурация TOML (по умолчанию /etc/crio/crio.conf ), используемая CRI-O. |
/pause/:id | application/json | Приостановить работающий контейнер. |
/unpause/:id | application/json | Снимите с паузы приостановленный контейнер. |
/debug/goroutines | text/plain | Распечатайте стеки горутины. |
/debug/heap | text/plain | Напишите дамп кучи. |
Подкоманду crio status
можно использовать для доступа к API с помощью специального инструмента командной строки. Он поддерживает все конечные точки API через выделенные подкоманды config
, info
containers
, например:
$ sudo crio status info
cgroup driver: systemd
storage driver: btrfs
storage root: /var/lib/containers/storage
default GID mappings (format ::):
0:0:4294967295
default UID mappings (format ::):
0:0:4294967295
См. руководство по метрикам CRI-O.
См. руководство по отслеживанию CRI-O.
Некоторые аспекты среды выполнения контейнера заслуживают дополнительных пояснений. Эти подробности изложены в специальном руководстве.
Возникла проблема? В нашем руководстве по отладке есть несколько советов и рекомендаций по отладке.
Неполный список тех, кто применяет CRI-O в производственных средах, можно найти здесь. Если вы пользователь, помогите нам завершить его, отправив запрос на включение!
Еженедельно проводится встреча для обсуждения развития CRI-O. Он открыт для всех. Подробности о присоединении к встрече можно найти на вики.
Для получения дополнительной информации о том, как управляется CRI-O, ознакомьтесь с файлом управления.