CRI-O suit les cycles de publication de Kubernetes en ce qui concerne ses versions mineures ( 1.xy
). Les versions de correctifs ( 1.xz
) pour Kubernetes ne sont pas synchronisées avec celles du CRI-O, car elles sont planifiées chaque mois, alors que le CRI-O ne les fournit qu'en cas de besoin. Si une version Kubernetes passe en Fin de Vie, alors la version CRI-O correspondante peut être considérée de la même manière.
Cela signifie que CRI-O suit également la politique de biais de la version Kubernetes n-2
en ce qui concerne la graduation, la dépréciation ou la suppression de fonctionnalités. Cela s'applique également aux fonctionnalités indépendantes de Kubernetes. Néanmoins, les rétroportages de fonctionnalités vers les branches de versions prises en charge, indépendantes de Kubernetes ou d'autres outils tels que les outils cri, sont toujours possibles. Cela permet à CRI-O de se dissocier du cycle de publication de Kubernetes et de disposer de suffisamment de flexibilité lorsqu'il s'agit d'implémenter de nouvelles fonctionnalités. Chaque fonctionnalité à rétroporter sera une décision au cas par cas de la communauté tandis que la matrice de compatibilité globale ne doit pas être compromise.
Pour plus d’informations, consultez la politique de biais de version de Kubernetes.
CRI-O | Kubernetes | Statut d'entretien |
---|---|---|
branche main | branche master | Les fonctionnalités du référentiel principal Kubernetes sont activement implémentées |
branche release-1.x ( v1.xy ) | branche release-1.x ( v1.xz ) | La maintenance est manuelle, seules les corrections de bugs seront rétroportées. |
Les notes de version de CRI-O sont rédigées à la main et peuvent être récupérées en permanence sur notre site Web de pages GitHub.
CRI-O est destiné à fournir un chemin d'intégration entre les environnements d'exécution conformes à OCI et le Kubelet. Plus précisément, il implémente l'interface d'exécution de conteneur Kubelet (CRI) à l'aide d'environnements d'exécution conformes à OCI. Le périmètre du CRI-O est lié au périmètre du CRI.
À un niveau élevé, nous nous attendons à ce que la portée de CRI-O soit limitée aux fonctionnalités suivantes :
CRI-O est une implémentation de Kubernetes Container Runtime Interface (CRI) qui permettra à Kubernetes de lancer et de gérer directement les conteneurs Open Container Initiative (OCI).
Le plan est d'utiliser les projets OCI et les meilleures bibliothèques pour différents aspects :
Il est actuellement en développement actif dans la communauté Kubernetes grâce à la proposition de conception. Les questions et les problèmes doivent être soulevés dans le canal Slack du nœud de signature Kubernetes.
Une feuille de route décrivant l’orientation du CRI-O peut être trouvée ici. Le projet suit tous les efforts en cours dans le cadre du projet Feature Roadmap GitHub.
Le CI de CRI-O est divisé entre les actions GitHub et OpenShift CI (Prow). Les images de machines virtuelles pertinentes utilisées pour les tâches de proue sont créées périodiquement dans les tâches :
Les tâches sont conservées à partir du référentiel openshift/release et définissent les flux de travail utilisés pour les tâches particulières. Les définitions de tâches réelles peuvent être trouvées dans le même référentiel sous ci-operator/jobs/cri-o/cri-o/cri-o-cri-o-main-presubmits.yaml pour la branche main
ainsi que les fichiers correspondants pour les branches de publication. La configuration de l'image de base pour ces tâches est disponible dans le même référentiel sous ci-operator/config/cri-o/cri-o.
Commande | Description |
---|---|
crio(8) | Démon d'exécution de conteneur OCI Kubernetes |
Des exemples d'outils de ligne de commande pour interagir avec CRI-O (ou d'autres environnements d'exécution compatibles CRI) sont Crictl et Podman.
Déposer | Description |
---|---|
crio.conf(5) | Fichier de configuration CRI-O |
politique.json(5) | Fichier(s) de stratégie de vérification de signature |
registres.conf(5) | Fichier de configuration des registres |
stockage.conf(5) | Fichier de configuration du stockage |
Le processus de sécurité pour signaler les vulnérabilités est décrit dans SECURITY.md.
Vous pouvez configurer CRI-O pour injecter des hooks OCI lors de la création de conteneurs.
Nous fournissons des informations utiles pour les opérations et le transfert de développement en ce qui concerne l'infrastructure qui utilise CRI-O.
Pour les communications asynchrones et les discussions de longue durée, veuillez utiliser les problèmes et les demandes d'extraction sur le dépôt GitHub. Ce sera le meilleur endroit pour discuter de la conception et de la mise en œuvre.
Pour la communication par chat, nous avons un canal sur Kubernetes slack que tout le monde est invité à rejoindre et à discuter du développement.
Nous maintenons une liste organisée de liens liés au CRI-O. Avez-vous trouvé quelque chose d'intéressant sur le Web à propos du projet ? Génial, n'hésitez pas à ouvrir un PR et à l'ajouter à la liste.
Pour installer CRI-O
, vous pouvez suivre notre guide d'installation. Alternativement, si vous préférez créer CRI-O
à partir des sources, consultez notre guide de configuration.
Avant de commencer, vous devrez démarrer CRI-O
Vous pouvez exécuter une version locale de Kubernetes avec CRI-O
en utilisant local-up-cluster.sh
:
CGROUP_DRIVER=systemd
CONTAINER_RUNTIME=remote
CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/crio/crio.sock'
./hack/local-up-cluster.sh
Pour plus de conseils sur l'exécution CRI-O
, visitez notre page de didacticiel.
CRI-O expose par défaut l'API gRPC pour remplir la Container Runtime Interface (CRI) de Kubernetes. En plus de cela, il existe une API HTTP supplémentaire pour récupérer des informations supplémentaires sur l'état d'exécution de CRI-O. Veuillez noter que cette API n'est pas considérée comme stable et que les cas d'utilisation en production ne doivent pas s'appuyer sur elle.
Sur une instance CRI-O en cours d'exécution, nous pouvons accéder à l'API via un outil de transfert HTTP comme 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": { ... }
}
Les points d'entrée d'API suivants sont actuellement pris en charge :
Chemin | Type de contenu | Description |
---|---|---|
/info | application/json | Informations générales sur le runtime, comme storage_driver et storage_root . |
/containers/:id | application/json | Informations sur le conteneur dédié, comme name , pid et image . |
/config | application/toml | La configuration TOML complète (par défaut /etc/crio/crio.conf ) utilisée par CRI-O. |
/pause/:id | application/json | Suspendre un conteneur en cours d'exécution. |
/unpause/:id | application/json | Reprendre un conteneur en pause. |
/debug/goroutines | text/plain | Imprimez les piles de goroutines. |
/debug/heap | text/plain | Écrivez le vidage du tas. |
La sous-commande crio status
peut être utilisée pour accéder à l'API avec un outil de ligne de commande dédié. Il prend en charge tous les points de terminaison de l'API via les sous-commandes dédiées config
, info
et containers
, par exemple :
$ 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
Veuillez vous référer au guide des métriques CRI-O.
Veuillez vous référer au guide de traçage CRI-O.
Certains aspects de Container Runtime méritent des explications supplémentaires. Ces détails sont résumés dans un guide dédié.
Vous avez un problème ? Il existe quelques trucs et astuces pour le débogage dans notre guide de débogage
Une liste incomplète des utilisateurs de CRI-O dans les environnements de production peut être trouvée ici. Si vous êtes un utilisateur, aidez-nous à le compléter en soumettant une pull-request !
Une réunion hebdomadaire est organisée pour discuter du développement du CRI-O. Il est ouvert à tous. Les détails pour rejoindre la réunion sont sur le wiki.
Pour plus d'informations sur la gouvernance du CRI-O, consultez le dossier de gouvernance