Goals
Gliffy Diagram |
| name |
OpenWhisk-w-ClusterManager-highlevel |
| pagePin |
3 |
|
- Try to reuse Kubernetes components in OW
- Keep the existing developer experience and CLI
Current deployment
Gliffy Diagram |
| name |
OpenWhisk-with-ClusterManager-simplified |
| pagePin |
5 |
|
Originally OpenWhisk was built with the assumption that each Invoker is responsible for a single VM in the cluster. With a Cluster Manager, this premise changes, as a single Invoker could be in charge of the entire cluster. The Cluster Manager is responsible for each VM. From the Invoker's perspective, the entire cluster looks like a single pool of resources. The current OpenWhisk components, Controller and Invoker, have problems managing the same pull of resources. For example:
- when 2 or more Invokers manage the same resources, conflicts may arise due to the fact that Invokers don't share any model
- the load balancing logic in the Controller becomes less important given than it doesn't matter which Invoker executes a given action, because it will still execute it on the same pool of resources
- the max memory limit set per invoker is also not useful
CNCF based Architecture Given these new premises, and the experience of building a FaaS solution that the OpenWhisk community has, can the OW system benefit from a Cluster Manager to simplify its implementation, while keeping the same developer experience ? This document looks at some possible options to achieve this with Kubernetes and other solutions from the CNCF landscape. Management, Control, and Data Plane OpenWhisk system can be decomposed in 3 distinct areas of concern, inspired from Network Devices and Systems designs.
Gliffy Diagram |
| name |
OpenWhisk-ManagementControlData-plane |
| pagePin |
2 |
|
Management Plane TBD Control Plane TBD Data Plane TBD Previous discussions Provide support for integration with Kubernetes. One approach could be to deploy and run the components on a Kubernetes provider as we do for Vagrant, Docker, Docker-Compose, and OpenStack. ... |