openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David P Grove" <>
Subject Re: What is the problem with the DockerContainerFactory in Kubernetes?
Date Sun, 06 Jan 2019 19:53:19 GMT

Michele Sciabarra <> wrote on 01/05/2019 09:05:28 AM:
> I am deploying OpenWhisk in Kubernetes using the helm charts, it
> works, but I noticed the issues with the external event providers:
> "the issue is that user action containers created by the
> DockerContainerFactory are not configured to themselves be able to
> invoke Kubernetes services"
> In the documentation, it says that  need either:
> - use an external couchdb
> - use a "lower performance" KubernetesContainerFactory
> - specify the IP of the kube-dns server
> I do not understand exactly what is the problem, ...
> Also, why using an
> external couchdb or providing the IP of the DNS server solve this

See [1] for the DNS discussion.  In brief, the DockerContainerFactory by
default does not configure /etc/resolv.conf in the user action containers
to enable Kubernetes service names like couchdb.openwhisk to be resolved.
So when the action that OpenWhisk internally use to create an alarm trigger
runs and tries to talk to the internal couchdb instance using this name,
the DNS lookup fails and therefore the trigger creation fails.   If we can
agree to merge something like [2] in the core project, then I do believe we
can smooth over this issue by doing some additional DNS configuration in
the Helm chart / invoker.yaml.

> why the KubernetesContainerFactory is lower performance?

(a) Pod creation time is higher than docker container creation time,
therefore cold starts are more expensive (about 4x last time I measured).
(b) Log extraction via the Kubernetes APIs is extremely slow, which delays
containers from being ready for reuse, which reduces overall system

> Furthermore, the documentation says to use Kubernetes 1.10 and 1.11,
> I used 1.13 and apparently works, the fact it now uses CoreDNS may help?

I do not believe the change from kube-dns to coredns will fix the provider
DNS problem.

I've also been deploying just fine on Kubernetes 1.12, but haven't updated
the docs because we aren't doing TravisCI testing with Kube 1.12 yet.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message