OCI images and runtimes: manifests, bundles and Kubernetes boundaries
Separate OCI image packaging, runtime execution and Kubernetes orchestration. Trace a multi-platform image selection and diagnose pull, create and application failures at the correct boundary.
TL;DR: OCI image specifications describe packaged content and metadata; runtime specifications describe how a prepared container is executed. Kubernetes adds orchestration through its runtime interface. A valid image package does not prove it can start on the selected node or serve the application correctly.
Packaging and execution are separate contracts
An image manifest identifies configuration and layers for an image. An image index can refer to manifests for different platforms. A tag is a registry reference that can change; a digest identifies particular content. A digest can identify an index or an individual manifest, so name which object you mean when discussing multi-platform releases.
The OCI image manifest specification defines the package structure. It does not decide how many replicas an application needs or whether its health endpoint passes.
A runtime bundle contains a root filesystem and runtime configuration used to create a container. The OCI runtime bundle specification describes that boundary. Higher-level software can fetch and unpack images before invoking a low-level runtime.
This is a conceptual boundary map. Concrete runtime implementations divide internal responsibilities differently.
Kubernetes talks through CRI
The kubelet uses the Container Runtime Interface, or CRI, to request container and image operations from a compatible runtime service. CRI and OCI solve different interface problems. A product implementing CRI may use OCI-compatible components beneath it.
Kubernetes documents this relationship in its CRI reference. Saying “Kubernetes runs Dockerfiles” skips the build, registry and runtime boundaries: a Dockerfile is a build recipe, while the node executes a prepared image through its runtime stack.
| Boundary | Responsibility | Failure to investigate there |
|---|---|---|
| Build recipe | Produce image content | Missing files or incorrect entrypoint |
| Registry and image metadata | Distribute and identify content | Authentication, missing manifest or platform selection |
| CRI implementation | Coordinate node image/container operations | Pull, unpack or container-creation errors |
| OCI runtime | Create and manage configured container execution | Invalid runtime configuration or host capability mismatch |
| Application | Initialize and serve intended behavior | Crash, dependency failure or readiness failure |
Worked failure: an image exists but cannot execute
Suppose CI builds an image on one CPU architecture and publishes only that platform's manifest. A workload is then scheduled to nodes using another architecture. The registry can be reachable and the tag can exist while the node still lacks a usable image for its platform, or execution fails because the binary architecture does not match.
Inspect the resolved manifest or index and the node platform. Confirm the build actually produced the intended architecture variants. Repeatedly changing image-pull credentials cannot repair an architecture mismatch.
Now suppose platform selection is correct but the process exits immediately. Inspect command, arguments, required files and runtime logs. An image successfully unpacked by the runtime may still contain an entrypoint pointing to a nonexistent executable or a binary requiring an unavailable library.
Finally, a process that remains running can still fail readiness. Move to application and dependency evidence rather than continuing to debug the image format. Kubernetes architecture helps identify which component reports each state.
Image portability has host constraints
Container packaging reduces environment differences but does not eliminate them. Kernel capabilities, architecture, device access and configured security restrictions can affect execution. A workload requiring a device or privileged operation needs an explicit supported deployment design.
Namespaces and cgroups explain isolation and resource-control mechanisms on Linux. Ordinary Linux containers execute system calls against the host kernel; namespace isolation does not supply a VM-style guest operating system. Additional sandboxing technologies can change the isolation boundary and should be named when relevant.
Pin the release identity and test on representative target nodes. A multi-platform index can improve distribution while still containing a broken build for one platform. Validate each supported variant rather than assuming success on the build machine establishes portability.
Answer from the boundary
Is OCI the same as CRI? No. OCI specifies image and runtime contracts; CRI is the Kubernetes interface to its runtime service. They can participate in the same stack.
Does a valid image manifest prove application health? No. It establishes packaging structure. Startup, permissions, dependencies and readiness need separate verification.
Why understand layers here? Image layers and build cache explain where files originate and why a missing or exposed file can persist through packaging even when orchestration is configured correctly.