cri o
1.31.2
CRI-O sigue los ciclos de lanzamiento de Kubernetes con respecto a sus versiones menores ( 1.xy ). Los lanzamientos de parches ( 1.xz ) para Kubernetes no están sincronizados con los de CRI-O, porque están programados para cada mes, mientras que CRI-O los proporciona solo si es necesario. Si una versión de Kubernetes llega al final de su vida útil, entonces la versión CRI-O correspondiente se puede considerar de la misma manera.
Esto significa que CRI-O también sigue la política de sesgo de la versión de lanzamiento de Kubernetes n-2 cuando se trata de graduación, desaprobación o eliminación de funciones. Esto también se aplica a funciones independientes de Kubernetes. Sin embargo, todavía es posible realizar backports de funciones a ramas de versiones compatibles, que sean independientes de Kubernetes u otras herramientas como cri-tools. Esto permite a CRI-O desacoplarse del ciclo de lanzamiento de Kubernetes y tener suficiente flexibilidad a la hora de implementar nuevas funciones. Cada característica que será respaldada será una decisión de la comunidad caso por caso, mientras que la matriz de compatibilidad general no debe verse comprometida.
Para obtener más información, visite la Política de desviación de versiones de Kubernetes.
| CRI-O | Kubernetes | Estado de mantenimiento |
|---|---|---|
rama main | rama master | Se implementan activamente funciones del repositorio principal de Kubernetes. |
rama release-1.x ( v1.xy ) | rama release-1.x ( v1.xz ) | El mantenimiento es manual, solo se respaldarán las correcciones de errores. |
Las notas de la versión de CRI-O están elaboradas a mano y se pueden recuperar continuamente desde nuestro sitio web de páginas de GitHub.
CRI-O está destinado a proporcionar una ruta de integración entre los tiempos de ejecución compatibles con OCI y Kubelet. Específicamente, implementa la interfaz de tiempo de ejecución de contenedores (CRI) de Kubelet utilizando tiempos de ejecución compatibles con OCI. El alcance de CRI-O está ligado al alcance del CRI.
A alto nivel, esperamos que el alcance de CRI-O se restrinja a las siguientes funcionalidades:
CRI-O es una implementación de Kubernetes Container Runtime Interface (CRI) que permitirá a Kubernetes lanzar y gestionar directamente contenedores Open Container Initiative (OCI).
El plan es utilizar proyectos OCI y las mejores bibliotecas para diferentes aspectos:
Actualmente se encuentra en desarrollo activo en la comunidad de Kubernetes a través de la propuesta de diseño. Se deben plantear preguntas y problemas en el canal Slack del nodo de señal de Kubernetes.
Puede encontrar una hoja de ruta que describe la dirección de CRI-O aquí. El proyecto realiza un seguimiento de todos los esfuerzos en curso como parte del proyecto Feature Roadmap GitHub.
El CI de CRI-O se divide entre acciones de GitHub y OpenShift CI (Prow). Las imágenes de máquinas virtuales relevantes utilizadas para los trabajos de proa se crean periódicamente en los trabajos:
Los trabajos se mantienen desde el repositorio de openshift/release y definen los flujos de trabajo utilizados para los trabajos particulares. Las definiciones de trabajo reales se pueden encontrar en el mismo repositorio en ci-operator/jobs/cri-o/cri-o/cri-o-cri-o-main-presubmits.yaml para la rama main , así como los archivos correspondientes para las ramas de liberación. La configuración de la imagen base para esos trabajos está disponible en el mismo repositorio en ci-operator/config/cri-o/cri-o.
| Dominio | Descripción |
|---|---|
| crio(8) | Demonio de tiempo de ejecución de contenedor OCI Kubernetes |
Ejemplos de herramientas de línea de comandos para interactuar con CRI-O (u otros tiempos de ejecución compatibles con CRI) son Crictl y Podman.
| Archivo | Descripción |
|---|---|
| crio.conf(5) | Archivo de configuración CRI-O |
| política.json(5) | Archivo(s) de política de verificación de firma |
| registros.conf(5) | Archivo de configuración de registros |
| almacenamiento.conf(5) | Archivo de configuración de almacenamiento |
El proceso de seguridad para informar vulnerabilidades se describe en SECURITY.md.
Puede configurar CRI-O para inyectar ganchos OCI al crear contenedores.
Proporcionamos información útil para operaciones y transferencia de desarrollo en lo que se refiere a infraestructura que utiliza CRI-O.
Para comunicación asíncrona y debates de larga duración, utilice problemas y solicitudes de extracción en el repositorio de GitHub. Este será el mejor lugar para discutir el diseño y la implementación.
Para la comunicación por chat, tenemos un canal en Kubernetes Slack al que todos pueden unirse y conversar sobre el desarrollo.
Mantenemos una lista seleccionada de enlaces relacionados con CRI-O. ¿Encontraste algo interesante en la web sobre el proyecto? Genial, siéntete libre de abrir un PR y agregarlo a la lista.
Para instalar CRI-O , puede seguir nuestra guía de instalación. Alternativamente, si prefiere crear CRI-O desde la fuente, consulte nuestra guía de configuración.
Antes de comenzar, deberá iniciar CRI-O
Puedes ejecutar una versión local de Kubernetes con CRI-O usando local-up-cluster.sh :
CGROUP_DRIVER=systemd
CONTAINER_RUNTIME=remote
CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/crio/crio.sock'
./hack/local-up-cluster.sh Para obtener más orientación sobre cómo ejecutar CRI-O , visite nuestra página de tutoriales
CRI-O expone de forma predeterminada la API gRPC para cumplir con la interfaz de ejecución de contenedor (CRI) de Kubernetes. Además de esto, existe una API HTTP adicional para recuperar más información sobre el estado del tiempo de ejecución de CRI-O. Tenga en cuenta que esta API no se considera estable y los casos de uso de producción no deben depender de ella.
En una instancia de CRI-O en ejecución, podemos acceder a la API a través de una herramienta de transferencia HTTP como 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": { ... }
}Actualmente se admiten los siguientes puntos de entrada API:
| Camino | Tipo de contenido | Descripción |
|---|---|---|
/info | application/json | Información general sobre el tiempo de ejecución, como storage_driver y storage_root . |
/containers/:id | application/json | Información del contenedor dedicado, como name , pid e image . |
/config | application/toml | La configuración TOML completa (por defecto /etc/crio/crio.conf ) utilizada por CRI-O. |
/pause/:id | application/json | Pausar un contenedor en ejecución. |
/unpause/:id | application/json | Reanudar la pausa de un contenedor pausado. |
/debug/goroutines | text/plain | Imprime las pilas de gorutinas. |
/debug/heap | text/plain | Escribe el volcado del montón. |
El subcomando crio status se puede utilizar para acceder a la API con una herramienta de línea de comandos dedicada. Admite todos los puntos finales de API a través de los subcomandos dedicados config , info y containers , por ejemplo:
$ sudo crio status info
cgroup driver: systemd
storage driver: btrfs
storage root: /var/lib/containers/storage
default GID mappings (format <container>:<host>:<size>):
0:0:4294967295
default UID mappings (format <container>:<host>:<size>):
0:0:4294967295 Consulte la guía de métricas CRI-O.
Consulte la guía de seguimiento CRI-O.
Algunos aspectos del Container Runtime merecen una explicación adicional. Estos detalles se resumen en una guía dedicada.
¿Tiene algún problema? Hay algunos consejos y trucos para la depuración ubicados en nuestra guía de depuración.
Puede encontrar una lista incompleta de quienes adoptan CRI-O en entornos de producción aquí. Si es un usuario, ayúdenos a completarlo enviando una solicitud de extracción.
Se lleva a cabo una reunión semanal para discutir el desarrollo de CRI-O. Está abierto a todos. Los detalles para unirse a la reunión están en la wiki.
Para obtener más información sobre cómo se gobierna CRI-O, consulte el archivo de gobernanza
