Kubernetes and Docker(shim) deprecation

[Rodric Rabbah <ro...@gmail.com>]

You may have read that the kubernetes 1.20 releate includes a notable
deprecation notice for dockershim
https://kubernetes.io/blog/2020/12/02/dockershim-faq which affects
OpenWhisk deployments on Kubernetes.

Several private deployments of OpenWhisk already don’t use docker, but the
Apache project does. I think there are some considerations for the project
to discuss. This note is to kick off that discussion.

-r

Re: Kubernetes and Docker(shim) deprecation

[Rodric Rabbah <ro...@gmail.com>]

An update on dockershim
https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2
.

"Mirantis and Docker have agreed to partner to maintain the shim code
standalone outside Kubernetes, as a conformant CRI interface for the Docker
Engine API... This means that you can continue to build Kubernetes based on
the Docker Engine as before, just switching from the built in dockershim to
the external one."

Dave Grove in the community Slack [1] noted, when I asked about dockershim,
that this should rightfully be a dev list discussion. I'm quoting his
message below:

"The big decision point is whether we want to have the option when
deploying on Kubernetes to bypass the global Kubernetes scheduler and do
our own container management on dedicated invoker worker nodes.  If so, we
need to invest in a container-d or cri-o variant of the current
DockerContainerFactory.   The alternative is to make a long-term bet that
eventually things like Knative will force Kubernetes to reach acceptable
levels of latency in Pod creation.  If so, then the path is to invest in
getting a reasonable logging story for the KubernetesContainerFactory and
just accept that we will not do our own fine-grained scheduling of
user-action pods to worker nodes."

The more recent news is good in that we may not have to a whole lot.
However the points Dave raises are good. I think others can comment better
about whether Knative or Kubernetes will eventually solve the latency
issues around pod creation.

I think the project should also consider containerless functions
orchestration seriously. Earlier this year, in collaboration between folks
at Adobe and Nimbella, we prototyped function execution using v8 isolates.
We found through benchmarking that isolate reuse is still important for
high throughput (order of magnitude) so that means routing and resource
allocation will remain integral to OpenWhisk IMO. The intent was always to
contribute this code to the project and I am long overdue on submitting a
POEM to do so. But I think discussion around orchestration should consider
these "edge" like scenarios where latency will be even more critical. I am
committed to doing this before the end of the year and invite anyone
interested in this topic to reach out - help and input is appreciated and
welcomed.

-r

[1] https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1607008892384400

On Thu, Dec 3, 2020 at 2:24 PM Rodric Rabbah <ro...@gmail.com> wrote:

> You may have read that the kubernetes 1.20 releate includes a notable
> deprecation notice for dockershim
> https://kubernetes.io/blog/2020/12/02/dockershim-faq which affects
> OpenWhisk deployments on Kubernetes.
>
> Several private deployments of OpenWhisk already don’t use docker, but the
> Apache project does. I think there are some considerations for the project
> to discuss. This note is to kick off that discussion.
>
> -r
>