OCI Is the Container Standard. Kubernetes Is Not.

Okay, let’s get right to it.

Containers became an industry standard because of OCI, not because of Kubernetes. That distinction actually matters a whole lot. Today, many people casually equate containers with Kubernetes, and container portability is often discussed as if it were a Kubernetes feature. Consequently, cloud-native is frequently treated as synonymous with Kubernetes-native.

But the real interoperability layer behind modern containers is OCI: the Open Container Initiative.

OCI defines the standards that make containers portable across registries, runtimes, operating systems, and orchestration platforms. Kubernetes is only one possible orchestration layer sitting on top. And importantly: OCI containers run perfectly well without Kubernetes.

OCI standardized containers. CNCF turned them into an ecosystem — and sometimes into an unnecessary amount of infrastructure.

Here follows an appreciation post for OCI, as a reminder that containers are the standard form factor for packing software across the board, but that the container orchestration solution should be fit-for-purpose.

Why This Matters Again: In Cloud & Edge Computing

This discussion becomes especially relevant as more applications move into hybrid environments. Many modern workloads no longer live only inside centralized cloud or data center infrastructure. Applications increasingly need to operate across factories, retail stores, hospitals, vehicles, telecom sites, and other distributed edge computing environments where infrastructure assumptions are very different from hyperscale cloud environments.

In those scenarios, portability is key.

Not necessarily portability between cloud vendors, but portability between operational models, hardware footprints, connectivity conditions, and orchestration environments.

That is where OCI becomes particularly important. OCI defines a portable application package that can move across very different environments without forcing every deployment target to look identical.

The Three OCI Standards

OCI is not a single specification. It is a small set of standards covering three everyday concepts in the container ecosystem:

Together, these standards are what make containers portable. You can build an OCI image, store it in an OCI-compliant registry, and run it with an OCI-compatible runtime, without Kubernetes being involved at all, if that’s what’s most suitable for the deployment environment.

The OCI Image Specification defines what most people simply call “a container”: filesystem layers, metadata, manifests, and packaging. This is why the same image can run on Docker, Podman, or any container runtime.

The OCI Distribution Specification standardizes how images move between systems. In practice, this is the protocol spoken by container registries such as Docker Hub, Harbor, AWS ECR, or Azure Container Registry.

The OCI Runtime Specification defines how containers are actually started and isolated on a host, close to Linux primitives such as namespaces and cgroups. This specification is implemented by runtimes such as runc and crun, which are then consumed by higher-level engines like Docker or Podman.

Kubernetes Is an Orchestrator, Not the Container Standard

This is where confusion might start.

Kubernetes is not the container standard. Kubernetes consumes OCI containers. It depends on OCI runtimes and OCI images. OCI is the compatibility layer underneath the ecosystem. That means OCI containers, registries, and runtimes can all exist independently of Kubernetes. But Kubernetes fundamentally depends on OCI-compatible components.

This is an important conceptual inversion that often gets lost in modern infrastructure discussions. Containers did not become portable because of Kubernetes. Kubernetes became successful partly because OCI standardized containers first.

Kubernetes deserves credit for making large-scale container operations practical in cloud and data center environments. But recognizing that success should not prevent us from separating the orchestrator from the underlying standard. OCI standardized containers. Kubernetes standardized one way of operating them. As computing expands into increasingly distributed edge environments, that distinction may become more important than ever.

Containers Were Supposed to Be Portable

One of the original promises of containers was simple: package the application together with its dependencies, move it between environments, and it will still run. That portability exists because OCI standardized the container itself.

An OCI container is supposed to be a relatively self-contained execution unit. If the runtime supports OCI containers, the application should largely behave the same whether it runs on a laptop, in a data center, at the edge, or under Kubernetes.

But many modern applications have drifted away from that model. Instead of building self-contained OCI applications, developers increasingly optimize applications around Kubernetes-native operational patterns, APIs, and ecosystem services. The application may technically run in containers, but operationally it becomes heavily tied to a specific orchestration environment.

And in practice, that environment is rarely just Kubernetes itself. It is often Kubernetes together with a growing collection of surrounding CNCF projects: service meshes, ingress controllers, operators, observability stacks, policy engines, storage layers, GitOps tooling, and identity frameworks. Each additional dependency may solve a real problem, but together they also increase coupling to a specific infrastructure ecosystem.

At that point, the container itself is no longer the portable unit. Kubernetes and its surrounding platform ecosystem become a significant part of the application’s operational dependency model.

And that creates risk.

Because moving the application no longer means “run the container somewhere else.” It may also require reproducing surrounding orchestration assumptions, operators, networking models, and infrastructure integrations.

Ironically, this moves applications away from one of the original strengths of containers: portability through standardization.

Containers were supposed to behave like atoms, self-contained execution units with minimal assumptions about the surrounding infrastructure.

The more application behavior leaks into orchestration-specific constructs, the less portable the system becomes. And at some point, organizations may realize they are running applications tightly coupled to a specific orchestration ecosystem.

Conclusion

None of this means Kubernetes is unfit. Kubernetes solved important problems for large-scale distributed infrastructure and became enormously successful for good reasons. And still do (in central data centers).

But OCI and Kubernetes solve different problems.

OCI standardized the application package itself: how applications are built, distributed, and executed as portable containers. Kubernetes is one orchestration model that can consume those containers.

That distinction becomes increasingly important as applications spread beyond centralized cloud environments into hybrid and distributed edge infrastructure.

In those environments, long-term flexibility may depend less on how deeply applications integrate with a specific orchestration ecosystem — and more on preserving the original promise of containers: portable, self-contained application units built on open standards.