lies es
1.31.2
CRI-O folgt den Kubernetes-Veröffentlichungszyklen in Bezug auf seine Nebenversionen ( 1.xy ). Patch-Releases ( 1.xz ) für Kubernetes sind nicht synchron mit denen von CRI-O, da sie für jeden Monat geplant sind, während CRI-O sie nur bei Bedarf bereitstellt. Wenn ein Kubernetes-Release das End of Life erreicht, kann die entsprechende CRI-O-Version in gleicher Weise berücksichtigt werden.
Das bedeutet, dass CRI-O auch die Kubernetes n-2 Release-Version-Skew-Richtlinie befolgt, wenn es um die Graduierung, Abwertung oder Entfernung von Funktionen geht. Dies gilt auch für Funktionen, die unabhängig von Kubernetes sind. Dennoch sind Feature-Backports auf unterstützte Release-Branches, die unabhängig von Kubernetes oder anderen Tools wie Cri-Tools sind, weiterhin möglich. Dies ermöglicht es CRI-O, sich vom Kubernetes-Release-Zyklus zu entkoppeln und über genügend Flexibilität bei der Implementierung neuer Funktionen zu verfügen. Jedes Feature, das zurückportiert werden soll, ist eine Einzelfallentscheidung der Community, während die gesamte Kompatibilitätsmatrix nicht beeinträchtigt werden sollte.
Weitere Informationen finden Sie in der Kubernetes-Versionsskew-Richtlinie.
| CRI-O | Kubernetes | Wartungsstatus |
|---|---|---|
main | master | Funktionen aus dem Haupt-Kubernetes-Repository werden aktiv implementiert |
release-1.x Zweig ( v1.xy ) | release-1.x Zweig ( v1.xz ) | Die Wartung erfolgt manuell, nur Bugfixes werden zurückportiert. |
Die Versionshinweise für CRI-O sind handgefertigt und können kontinuierlich von unserer GitHub-Seiten-Website abgerufen werden.
CRI-O soll einen Integrationspfad zwischen OCI-konformen Laufzeiten und Kubelet bieten. Insbesondere implementiert es das Kubelet Container Runtime Interface (CRI) mithilfe von OCI-konformen Laufzeiten. Der Geltungsbereich von CRI-O ist an den Geltungsbereich des CRI gebunden.
Auf hoher Ebene gehen wir davon aus, dass der Umfang von CRI-O auf die folgenden Funktionalitäten beschränkt wird:
CRI-O ist eine Implementierung des Kubernetes Container Runtime Interface (CRI), die es Kubernetes ermöglicht, Container der Open Container Initiative (OCI) direkt zu starten und zu verwalten.
Es ist geplant, OCI-Projekte und erstklassige Bibliotheken für verschiedene Aspekte zu nutzen:
Es befindet sich derzeit im Rahmen des Designvorschlags in der aktiven Entwicklung in der Kubernetes-Community. Fragen und Probleme sollten im Kubernetes-Sign-Node-Slack-Kanal gestellt werden.
Eine Roadmap, die die Ausrichtung von CRI-O beschreibt, finden Sie hier. Das Projekt verfolgt alle laufenden Bemühungen im Rahmen des Feature Roadmap GitHub-Projekts.
Das CI von CRI-O ist zwischen GitHub-Aktionen und OpenShift CI (Prow) aufgeteilt. Relevante VM-Images, die für die Prow-Jobs verwendet werden, werden regelmäßig in den Jobs erstellt:
Die Jobs werden aus dem OpenShift/Release-Repository verwaltet und definieren Workflows, die für die jeweiligen Jobs verwendet werden. Die tatsächlichen Jobdefinitionen finden Sie im selben Repository unter ci-operator/jobs/cri-o/cri-o/cri-o-cri-o-main-presubmits.yaml für den main sowie die entsprechenden Dateien für die Release-Zweige. Die Basis-Image-Konfiguration für diese Jobs ist im selben Repository unter ci-operator/config/cri-o/cri-o verfügbar.
| Befehl | Beschreibung |
|---|---|
| crio(8) | OCI Kubernetes Container Runtime-Daemon |
Beispiele für Befehlszeilentools zur Interaktion mit CRI-O (oder anderen CRI-kompatiblen Laufzeiten) sind Crictl und Podman.
| Datei | Beschreibung |
|---|---|
| crio.conf(5) | CRI-O-Konfigurationsdatei |
| Policy.json(5) | Richtliniendatei(en) zur Signaturüberprüfung |
| registries.conf(5) | Registrierungskonfigurationsdatei |
| storage.conf(5) | Speicherkonfigurationsdatei |
Der Sicherheitsprozess zum Melden von Schwachstellen wird in SECURITY.md beschrieben.
Sie können CRI-O so konfigurieren, dass beim Erstellen von Containern OCI-Hooks eingefügt werden.
Wir stellen nützliche Informationen für den Betrieb und den Entwicklungstransfer in Bezug auf die Infrastruktur bereit, die CRI-O nutzt.
Für asynchrone Kommunikation und langwierige Diskussionen verwenden Sie bitte Issues und Pull Requests im GitHub-Repo. Dies ist der beste Ort, um Design und Implementierung zu besprechen.
Für die Chat-Kommunikation haben wir einen Kanal im Kubernetes-Slack, dem jeder gerne beitreten und über die Entwicklung chatten kann.
Wir führen eine kuratierte Liste mit Links zu CRI-O. Haben Sie im Internet etwas Interessantes über das Projekt gefunden? Großartig, öffnen Sie gerne eine PR und fügen Sie sie der Liste hinzu.
Um CRI-O zu installieren, können Sie unserer Installationsanleitung folgen. Wenn Sie CRI-O lieber aus dem Quellcode erstellen möchten, schauen Sie sich alternativ unsere Einrichtungsanleitung an.
Bevor Sie beginnen, müssen Sie CRI-O starten
Sie können eine lokale Version von Kubernetes mit CRI-O mithilfe von local-up-cluster.sh ausführen:
CGROUP_DRIVER=systemd
CONTAINER_RUNTIME=remote
CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/crio/crio.sock'
./hack/local-up-cluster.sh Weitere Anleitungen zum Ausführen von CRI-O finden Sie auf unserer Tutorial-Seite
CRI-O stellt standardmäßig die gRPC-API zur Verfügung, um das Container Runtime Interface (CRI) von Kubernetes zu erfüllen. Darüber hinaus gibt es eine zusätzliche HTTP-API zum Abrufen weiterer Laufzeitstatusinformationen zu CRI-O. Bitte beachten Sie, dass diese API nicht als stabil gilt und Produktionsanwendungsfälle nicht darauf angewiesen sein sollten.
Auf einer laufenden CRI-O-Instanz können wir über ein HTTP-Übertragungstool wie Curl auf die API zugreifen:
$ 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": { ... }
}Die folgenden API-Einstiegspunkte werden derzeit unterstützt:
| Weg | Inhaltstyp | Beschreibung |
|---|---|---|
/info | application/json | Allgemeine Informationen zur Laufzeit, wie storage_driver und storage_root . |
/containers/:id | application/json | Dedizierte Containerinformationen, wie name , pid und image . |
/config | application/toml | Die vollständige TOML-Konfiguration (standardmäßig /etc/crio/crio.conf ), die von CRI-O verwendet wird. |
/pause/:id | application/json | Unterbrechen Sie einen laufenden Container. |
/unpause/:id | application/json | Heben Sie die Pause eines angehaltenen Containers auf. |
/debug/goroutines | text/plain | Drucken Sie die Goroutine-Stacks. |
/debug/heap | text/plain | Schreiben Sie den Heap-Dump. |
Der Unterbefehl crio status kann verwendet werden, um mit einem speziellen Befehlszeilentool auf die API zuzugreifen. Es unterstützt alle API-Endpunkte über die dedizierten Unterbefehle config , info und containers , zum Beispiel:
$ 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 Weitere Informationen finden Sie im CRI-O-Metrik-Leitfaden.
Weitere Informationen finden Sie im CRI-O Tracing-Leitfaden.
Einige Aspekte der Container Runtime sind eine zusätzliche Erläuterung wert. Diese Details sind in einem speziellen Leitfaden zusammengefasst.
Haben Sie ein Problem? Einige Tipps und Tricks zum Debuggen finden Sie in unserem Debugging-Leitfaden
Eine unvollständige Liste der Anwender von CRI-O in Produktionsumgebungen finden Sie hier. Wenn Sie ein Benutzer sind, helfen Sie uns bitte beim Vervollständigen, indem Sie eine Pull-Anfrage senden!
Es findet wöchentlich ein Treffen statt, um die CRI-O-Entwicklung zu besprechen. Es steht allen offen. Die Details zur Teilnahme an der Besprechung finden Sie im Wiki.
Weitere Informationen zur Steuerung von CRI-O finden Sie in der Governance-Datei
