Ein Container enthält für gewöhnlich eine einzelne App, die oft einen Microservice zur Verfügung stellt. Im praktischen Einsatz muss in der Regel eine Vielzahl von Containern zusammen gesteuert werden, um eine komplette Anwendung zu realisieren. Die koordinierte Verwaltung ganzer Gruppen von Containern ist als Orchestrierung bekannt.
Auch wenn die Orchestrierung mit Docker und Tools wie Docker Swarm machbar ist, hat sich mit Kubernetes eine Alternative zu Docker durchgesetzt. Kubernetes fasst mehrere Container in einem sogenannten Pod zusammen. Die Pods wiederum laufen auf Nodes genannten Maschinen – dabei kann es sich sowohl um physische als auch um virtuelle Maschinen handeln.
Eines der ausschlaggebenden Probleme mit Docker war die monolithische Architektur der Software. Der Docker-Daemon lief mit Root-Rechten und war für eine Vielzahl unterschiedlicher Aufgaben zuständig: vom Herunterladen der Container-Images, über die Ausführung in der Laufzeitumgebung, bis zum Erstellen neuer Images. Diese Verquicking eigentlich unabhängiger Bereiche verstößt gegen das Software-Entwicklungs-Prinzip „Separation of concerns“ („Trennung der Belange“) und führt in der Praxis u. a. zu Sicherheitsproblemen. Daher folgten Anstrengungen, die einzelnen Komponenten zu entkoppeln.
Beim Erscheinen von Kubernetes enthielt der Kubernetes-Daemon kubelet eine hartcodierte Docker-Laufzeitumgebung. Jedoch zeigte sich schon bald die Notwendigkeit, auch andere Runtimes zu unterstützen. Eine Modularisierung der einzelnen Aspekte versprach eine vereinfachte Weiterentwicklung sowie erhöhte Sicherheit. Um verschiedene Runtimes mit Kubernetes kompatibel zu machen, wurde eine Schnittstelle definiert: das Container Runtime Interface (CRI). CRI-O ist eine spezifische Implementation dieser Schnittstelle.