Open Container Initiative (OCI) started in 2015 to make different implementations of container runtimes and images compliant with well-defined specifications. Together with other folks at Kinvolk, I have been involved in various OCI projects since months, and encountered various issues that occur in runtime specs and runtime-tools for verification. Since we live in a real world, not everything works well as expected. I’m going to talk about practical issues, and possible ways to get it improved.
Open Container Initiative (OCI) defines container runtime specs (https://github.com/opencontainers/runtime-spec) as well as container image specs (https://github.com/opencontainers/image-spec) and distribution spec (https://github.com/opencontainers/distribution-spec).
There is also runtime-tools (https://github.com/opencontainers/runtime-tools) that helps container runtime to verify compliance of the runtime specifications. The standard container runtime is runc (https://github.com/opencontainers/runc) that is included in multiple high-level container managers like Docker or containerd. Most of the practical issues arise when specification is not clearly defined in the first place, or when container runtimes have own reasons for not being compliant with the specs, or when there’s no consensus in the community how it should proceed.
On the other hand, container orchestration systems like Kubernetes have defined their own interfaces such as Container Runtime Interface (CRI). The different interfaces (OCI runtime and CRI) exist at different layers in the software stack. I'll show how CRI depends on OCI and some mismatches between them.
In this talk I want to introduce such practical issues, and try to suggest how we should proceed regarding spec compliance.