The Cloud Native Computing Foundation (CNCF) appears to be suffering an embarrassment of container technology riches.
Docker Inc., after pledging to give up control of the lower level run-time Docker functions as promised, is proposing the CNCF will now be responsible for continuing the development of containerd as an open-source project. At the same time, CoreOS announced that it, too, is proposing the CNCF take control over the rival rkt container platform.
Because of the work the CNCF does involving the Kubernetes orchestration engine, Patrick Chanezon, a member of the technical staff for Docker Inc., says the implications of this project go well beyond simply making low-level container technology more accessible. The Kubernetes container orchestration engine interfaces today with the full Docker Engine. Going forward, implementations of Kubernetes should be able to perform better by interacting directly with containerd components, Chanezon says.
A similar level of tighter integration would also theoretically exist between Kubernetes and rck as well, with the hope that the two rival platforms might one day share common lower level run-time functions. CoreOS, however, is making a case for daemonless approach that makes it possible to run more specialized types of containers.
CNCF also is the steward for gRPC and Promethus open-source projects. containerd exposes an API using gRPC while also sharing metrics in a format that is compatible with the Promethus container monitoring tool.
Future enhancements to containerd are currently scheduled to occur in two phases. The first phase calls for development of a specific containerd API and improvement to the overall architecture. Phase 2 spans design and development work for the execution and storage layers of containerd. It will include porting over existing “graph drivers” from Docker Engine and the creation of a common model for representing snapshots for layered file systems. At the same time, there will be additional work involving support for the Runtime Spec crated by the Open Container Initiative (OCI) and existing containerd execution code.
Chanezon says that even with the contribution of containerd to the CNCF, Docker Inc. believes there is still plenty of room to innovate at both the orchestration and network levels of the container stack. In fact, while being able to access containerd components should go a long way to extending the Docker container ecosystem, interoperability between various container orchestration engines might still prove elusive.
For example, Docker Inc., continues to pursue its own management platform, while the bulk of the IT vendor community has endorsed Kubernetes. At the same time, however, there is a separate faction relying on the Marathon container engine that is most often associated with clusters based on Mesos software.
The degree to which organizations standardize on any of these engines remains to be seen. Container adoption is relatively nascent. In fact, many enterprise IT organizations are likely to have multiple container projects employing different container orchestration engines. That, in turn, may create demand for some form of container orchestration management platform capable of invoking multiple types of engines. Naturally, as that transitions occurs, there also should be a fair amount of contention among vendors trying to exercise supremacy over various container orchestration engines.
In the meantime, enterprise IT organizations continue to rely mainly on existing frameworks for managing virtual machines to manage containers deployed on top of them. In time, however, more of those IT organizations are expected to deploy containers on bare-metal servers, which would then make choosing a container orchestration engine an essential element of their overall IT strategy.