Why is docker no longer supported on kata2.X?

[uliux]

Hi, maintainers,
I want to deploy KATA in our production environments, which will increase the robustness and security features of our virtual products. Before, our virtual products were released through Docker. But now kata2.x doesn't support Docker. This leads to huge migration costs for us.
Are there any plans to support Docker in the future? I also want to know why kata2.x no longer supports Docker? After all, docker still has a lot of inventory in the production env.

[bergwolf]

The runc interface is really tied to its own implementations, making it difficult to implement a runc-compliant runtime with other implementations. For example, a container process must be represented by a real host PID, which does not make any sense for a VM-based container runtime. Just to name a few. Kata used to fake a pid for it but it makes kata's architecture unnecessarily complex.

As a result, the community (containerd, crio, kata etc.) moved forward to a more neutral interface -- the containerd shimv2 APIs. moby, too, moved to the containerd shimv2 API but it only supports runc in the containerd shimv2 mode. So Kata is not supported by moby now. There is work around the moby community (moby/moby#42986) to support other runtime types in the shimv2 API mode, but it is making very slow progress.

OTOH, @c3d and @dgibson are working on a wrapper CLI to provide runc like command lines on top of the containerd shimv2 APIs. Once they finish the task, docker support is resumed as well.

[jodh-intel]

Hi @uliux - TL;DR - see #722.

Detail

The problem is that the original OCI runtime spec is not optimal for virtual machine based container systems like Kata Containers. The containerd project recognised this and in mid-2018 added the shimv2 architecture to address the problem:

• https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/history.md
• https://github.com/containerd/containerd/tree/main/runtime/v2

Kata 2.x moved to this new architecture as it is superior in various ways to the old OCI spec. However, unfortunately Docker and podman have still not implemented shimv2. This means that if you wish to use Kata 2.x you need to use either containerd or crio which both support the shimv2 architecture.

Kata could re-add the OCI runtime commands (#722), but that would be a retrograde step. However, there is an alternative solution to the problem: create a "wrapper" around the Kata 2.x shimv2 runtime that:

• Provides the old OCI runtime CLI commands.
• Maps those calls to the appropriate shimv2 method calls and then makes those calls on the Kata 2.x shimv2 runtime.

What this means is that once we have this "wrapper" (it needs a better name ;), it should be possible to configure Docker to use this wrapper with Kata 2.x:

• Kata 1.x:

  /--------\     /--------------\
  | docker | --> | kata-runtime |
  \--------/     \--------------/
  

• Kata 2.x today:

  /-----------\     /-------------------------\
  | containerd| --> | containerd-shim-kata-v2 |
  \-----------/     \-------------------------/
  

• Kata 2.x in the future:

  /--------\     /---------\     /-------------------------\
  | docker | --> | wrapper | --> | containerd-shim-kata-v2 |
  \--------/     \---------/     \-------------------------/
  

@c3d and @dgibson may have more info on this.

[dgibson]

Right. I'm actively working on this wrapper, but it will be a little while before it's ready for use, even experimentally.

[uliux]

Thanks for the quick reply.
The Wrapper can solve the problem I'm having. Expect it to come soon @dgibson.
Our department focuses on the embedded domain. I think it should now be categorized as IoT (the Internet of Things). Our concerns on virtualization infrastructure are different than cloud computing. Cloud computing wants faster startup times and a leaner collection of devices. We need a richer set of equipment to better reproduce the real equipment and production scenarios. So I'm glad that kata can support QEMU.
After an initial assessment by our team, Kata will address the pain points of our virtual products -- insecurity and instability. Thank kata community for bringing us a good product.

Expect my company to final choose Kata as the infrastructure for our virtual products. I also expect kata-maintainers have a good balance between technology and compatibility in the future. To be honest, I was surprised that Kata2.x removed support for Docker. Even though technically removing Docker was the right thing to do. But from a business point of view, it confuses our team. Incompatibilities result in significant migration costs.

[dgibson]

I really can't promise soon, it all depends what challenges I encounter.

Please remember that the Kata team is not a business (although it's supported by various businesses). We have to balance what we'd like to do against the limited resources we have to implement and maintain it.

[uliux]

Understand. Thanks for your reply. @dgibson