113 lines
3.6 KiB
Markdown
113 lines
3.6 KiB
Markdown
|
|
A high level view of the internals of Fission.
|
|
|
|
How it works
|
|
============
|
|
|
|
Fission is a FaaS -- users create functions (source level), register
|
|
them with fission using a CLI, and associate functions with triggers.
|
|
|
|
Fission wraps those functions into a service, and runs them on
|
|
Kubernetes on demand.
|
|
|
|
Here's an overview of the services that make up fission.
|
|
|
|
Components
|
|
==========
|
|
|
|
Language-neutral components:
|
|
|
|
* controller
|
|
* poolmgr
|
|
* router
|
|
* kubewatcher
|
|
|
|
Language-specific components:
|
|
|
|
* Environment container
|
|
|
|
|
|
Controller
|
|
----------
|
|
|
|
The controller contains CRUD APIs for functions, http triggers,
|
|
environments, Kubernetes event watches. This is the component that
|
|
the client talks to.
|
|
|
|
This is the only stateful component. It needs to be configured with a
|
|
URL to an etcd cluster and a path to a persistent volume. The volume
|
|
is used to store the functions' source code. Etcd is used as the DB.
|
|
|
|
[Work to extend to other storage backends is planned, see issue #83.]
|
|
|
|
Pool Manager
|
|
------------
|
|
|
|
Poolmgr manages pools of generic containers and function containers.
|
|
|
|
It has a simple API; both these endpoints are called by the router.
|
|
|
|
* GetFunctionService takes function metadata and returns the address
|
|
of a service.
|
|
|
|
* TapService lets poolmgr know a service is being used; if it's not
|
|
called for a few minutes the pod(s) backing the service are killed.
|
|
|
|
Poolmgr watches the controller API and eagerly creates generic pools
|
|
for environments. It uses Kubernetes deployments to do that. The
|
|
environment container runs in a pod with the 'fetcher' container.
|
|
Fetcher is a very simple utility that downloads a URL sent to it and
|
|
saves it at a configured location.
|
|
|
|
GetFunctionService "specializes" a pod. The implementation chooses a
|
|
pod from the pool, relabels it to "orphan" the pod from the
|
|
deployment, invokes fetcher to copy the function into the pod, and
|
|
hits the the specialize endpoint on the environment container. This
|
|
causes the function to be loaded. The pod is now specific to that
|
|
function.
|
|
|
|
This function pod is cached; it's cleaned up if it's unused for a few
|
|
minutes.
|
|
|
|
Router
|
|
------
|
|
|
|
The router forwards HTTP requests to function pods. If there's no
|
|
running service for a function, it requests one from poolmgr, while
|
|
holding on to the request; when the function's service is ready it
|
|
forwards the request.
|
|
|
|
The router is stateless and can be scaled up if needed, according to
|
|
load.
|
|
|
|
Kubewatcher
|
|
-----------
|
|
|
|
Kubewatcher watches the Kubernetes API and invokes functions
|
|
associated with watches, sending the watch event to the function.
|
|
|
|
The controller keeps track of user's requested watches and associated
|
|
functions. Kubewatcher watches the API based on these requests; when
|
|
a watch event occurs, it serializes the object and calls the function
|
|
via the router.
|
|
|
|
While a few simple retries are done, there isn't yet a reliable
|
|
message bus between Kubewatcher and the function. Work for this is
|
|
tracked in issue #64.
|
|
|
|
Environment Container
|
|
---------------------
|
|
|
|
Environment containers run user-defined functions. Environment
|
|
containers are language specific. They must contain an HTTP server
|
|
and a loader for functions.
|
|
|
|
Poolmgr deploys the environment container into a pod with fetcher
|
|
(fetcher is a simple utility that can fetch an HTTP url to a file at a
|
|
configured location). This pod forms a "generic pod", because it can
|
|
be loaded with any function.
|
|
|
|
When poolmgr needs to create a service for a function, it calls
|
|
fetcher to fetch the function. Fetcher downloads the function into a
|
|
volume shared between fetcher and this environment container. Poolmgr
|
|
then requests the container to load the function. |