[feature] FaaSController

[benja-wu]

Background

1. After comparing with popular Serverless/FaaS open-source products, We chose to integrate with Knative which is host by Google/RedHat/IBM[1].
2. Easegress has a Controller called Function for abstracting the communication between Easegress's HTTP server and Function provider(Knative) locally with the help of a separate FaaSServer binary.

Proposal

1. Refactor Easegress' Function Controller to support FaaS CRUD operation with its own RESTful API. Move original FaaSServer's logic into the Easegress' Function controller.
2. The Function controller manages a shared HTTPServer and one pipeline per Knative function.

Design

Roles

1. FaaSController: An controller in Easegress, will listen to a port in HTTP protocol and forward ingress traffic to FaaS Provider's function instances locally. It manages one or many FaaSFunction vias its RESTful API.
2. FaaSFunction: One logic concept in Easegress, will represent a FaaS Provider's function instances, has its own lifecycle, shared with the same HTTP port own by the FaaSController who created it. Its spec will be stored in Easegress's ETCD.
3. FaaSProvider: The physical FaaS function instance manager, currently, is Knative.

Function controller spec

name: faascontroller-1
kind: Function
provider: knative             # FaaS provider kind, currently we only support Knative

httpServer:
    http3: false 
    port: 10083
    keepAlive: true
    keepAliveTimeout: 60s
    https: false
    certBase64:
    keyBase64:
    maxConnections: 10240

knative:
   functionHost: 127.0.0.1.xip.io     # the host for Knative functions shared part, FaaSController will forward ingress traffic to this host combining with function's name

Function spec

name: demo
image: dev.local/colorddeploy:14.0   # the function logic, currently we only support HTTP protocol
autoScaleType: concurrency           # there are three kinds of scale type, concurrency/rps/cpuPercent
autoScaleValue:  "300"               # the scaling metrics value
minReplica: 1                        # the function's minimum instance number   
maxReplica: 5                        # the function's maximum instance number
limitCPU:  200m                      # the function's maximum CPU resource ( the same in K8s's Pod resource limitation)
limitMemory: 80Mi                    # the function's maximum memory resource ( the same in K8s's Pod resource limitation) 
requestCPU: 100m                     # the function's minimum CPU resource ( the same in K8s's Pod resource request)
requestMemory: 40Mi                  # the function's minimum memory resource ( the same in K8s's Pod resource request)

requestAdaptor:                      # optional, indicate how FaasController should transform original HTTP request to FaaSProvider's needed format
  method: POST                       # change HTTP method to `POST` for visiting FaaSProvider's function 
  path:
    replace: /                       # replace HTTP Path to '/', also support Regexp replacing, trimming or adding. 
  header:
    set:
      X-Func: func-demo              # add one HTTP header 

Lifecycle

There four types of function status, Pending, Active, InActive, and Failed[2]. Basically, they come from AWS Lambda's status.

• Once the function has been created in Easegress, its original status is pending. After the function had been provisioned successfully by FaaSProvider(Knative), its status will become active. At last, FaaSController will add the routing rule in its HTTPServer for this function.
• Easegress's FaaSFunction will be active not matter there are requests or not. Stop function execution by calling FaaSController's stop RESTful API, then it will turn function into inactive. Updating function's spec for image URL or else fields, or deleting function also need to stop it first.
• After updating the function, it will run into pending status. (Once provision successfully, it will become active automatically)
• FaaSController will remove the routing rule in its HTTPServer for rejecting one function's ingress traffic when it's in inactive status. (Then the client will receive HTTP 404 failure response. For becoming zero-downtime, deploy another new FaaSfunction in this FaaSController may be helpful)

  +---------------+ (provision successfully)      +-------------+
  |               |------------------------------>|             |
  |    pending    |                               |   active    |<------+
  |               |                               |             |       |
+-+---------------+ <--+     +--------------------+--------+----+       |   
|                      |     |                             |            |
| error                |     |                             |stop        | start
|               update |     | error                       |            |
|  +---------------+   |     |        +-------------+      |            |
+->|               |   |     |        |             |      |            |
   |   failed      |<--+-----+--------+   inactive  |<-----+            |
   |               |                  |             +-------------------+
   |               |                  |             |
   +---------------+                  +-------------+

RESTful APIs

The RESTful API path obey this design http://host/{version}/{namespace}/{scope}(optional)/{resource}/{action},

Operation	URL	Method
Create a function	http://eg-host/apis/v1/faas/faas-controller1	POST
Start a function	http://eg-host/apis/v1/faas/faas-controller1/demo1/start	PUT
Stop a function	http://eg-host/apis/v1/faas/faas-controller1/demo1/stop	PUT
Update a function	http://eg-host/apis/v1/faas/faas-controller1/demo1	PUT
Delete a function	http://eg-host/apis/v1/faas/aas-controller1/demo1	DELETE
Get a function	http://eg-host/apis/v1/faas/faas-controller1/demo1	GET
Get function list	http://eg-host/apis/v1/faas/faas-controller1	GET

References

1. https://knative.dev
2. https://aws.amazon.com/blogs/compute/tracking-the-state-of-lambda-functions/