Precisely, the dependency we're talking about here is "just" leveraging Kubernetes as a generic extensible control plane which makes it quite convenient to plug into for management of resources.

+1 we really wanted to leverage the ecosystem and have something that is immediately familiar when we decided to use kube-apiserver (and etcd) for crossplane. I think the K8S resource model [1] goes well beyond container orchestration

[1] https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRf...

As I said, we have lots of customers who need a packaging format that targets clouds APIs which in some cases don't have any containers (hence no need for Kubernetes). Functions + datastore + service bus being a good example.

I know there's lots of love for Kubernetes, containers, and operators -- with me too. Still we can't and shouldn't presume the existence of Kubernetes or Kubernetes APIs to solve the problems CNAB is tackling.

From reading the spec though it looks like everything uses containers built from a Dockerfile:

"A bundle is comprised of a bundle definition and at least one invocation image. The invocation image's job is to install zero or more components into the host environment. Such components MAY include (but are not limited to) containers, functions, VMs, IaaS and PaaS layers, and service frameworks."

So, the very first step of CNAB is to run a container. And CNAB invents a new way of configuring, lifecycling, etc, this container image.

[1] https://github.com/deislabs/cnab-spec/blob/master/100-CNAB.m...

Right. We took a dependency on a container runtime and not on a container orchestrator.

One of the examples we show is an electron app that provides a desktop installer experience for a cloud-based distributed application. We presume a container runtime for this.

We expect CNAB to play nicely with Kubernetes lifecycle management, but taking a hard dependency on Kubernetes was not deemed advantageous to CNAB's design goals.

It doesn't have to be a container. We have experimented with using VMs as the CNAB runtime as seen with the azure-vm driver in our reference implementation, duffle: https://github.com/deislabs/duffle/tree/master/drivers/azure...

Most of the examples are primarily container-based and the specification reflects that. We will definitely have to do a better job fleshing out the design with alternative invocation image types than OCI/docker. The azure-vm driver is one such (experimental) example.

Hope this helps!

Please note that while Crossplane uses the Kubernetes API the actual server is separate from Kubernetes. This way you can use Crossplane to provision a Kubernetes cluster on the cloud of your choice. See https://news.ycombinator.com/item?id=18601440 for more information.

This doesn't come across in the press that is being made. Perhaps it is just the join messaging with Docker. The purpose of CNAB isn't clear as a generic spec as the examples are all with duffle and dockerapp. Still reading the spec though.

"Functions + datastore + service bus" - that can be easily expressed in an ARM template. Why the need for CNAB..?