FaaSController

FaaSController

A FaaSController is a business controller for handling Easegress and FaaS products integration purposes. It abstracts FaasFunction, FaaSStore and, FaasProvider. Currently, we only support Knative type FaaSProvider. The FaaSFunction describes the name, image URL, the resource, and autoscaling type of this FaaS function instance. The FaaSStore is covered by Easegress' embed Etcd already.
FaaSController works closely with local FaaSProvider. Please make sure they are running in a communicable environment. Follow this knative doc to install Knative[1]'s serving component in K8s. It's better to have Easegress run in the same VM instances with K8s for saving communication costs.

Prerequisites

K8s cluster : v1.18+
Knative Serving : v0.23 (with kourier type of networklayer instead of Istio which is too complicated here)

Configuration

Controller spec

One FaaSController will manage one shared HTTP traffic gate and multiple pipelines according to the functions it has.
The httpserver section in spec is the configuration for the shared HTTP traffic gate.
The Knative section inf spec is for Knative type FaaSProvider. The ${knative_kourier_clusterIP} value can be set by using the command

$ kubectl get svc -n kourier-system
NAME               TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
kourier            LoadBalancer   10.109.159.129   <pending>     80:31731/TCP,443:30571/TCP   250dk

The CLUSTER-IP valued with 10.109.159.129 is your kourier's K8s service's address.

Note: Using the CLUSTER-IP value above to replace the {knative_kourier_clusterIP} in the YAML below.
The hostSuffix filed should be filled with value example.com[2] according to Knative serving's Temporary DNS.

name: faascontroller
kind: FaaSController           
provider: knative             # FaaS provider kind, currently we only support Knative

syncInterval: 10s              

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

knative:
   networkLayerURL: https://{knative_kourier_clusterIP}
   hostSuffix: example.com

FaaSFunction spec

The FaaSFunction spec including name, image, and other resource-related configurations.
The image is the HTTP microservice's image URL. When upgrading the FaaSfFunction's business logic. this field can be helpful.
The resource and autoscaling fields are similar to K8s or Knative's resource management configuration.[3]
The requestAdaptor is for customizing the way how HTTP request content will be routed to Knative's kourier gateway.

name:           "demo10"                                                                                                                                   
image:          "dev.local/colordeploy:17.0"    
port:           8089
autoScaleType:  "rps"          
autoScaleValue: "111"          
minReplica:     1
maxReplica:     3
limitCPU:       "180m"         
limitMemory:    "100Mi"        
requestCPU:     "80m"          
requestMemory:  "20Mi"         
requestAdaptor:                       
  header:
    set:
      X-Func1: func-demo-10              # add one HTTP header

Lifecycle

There four types of function state: Initial, Active, InActive, and Failed[4]. Basically, they come from AWS Lambda's status.

Initial: Once the function has been created in Easegress, its original state is initial. After checking FaaSProvider(Knative)'s status successfully, it will become active automatically. And the function is ready for handling traffic.
Active: Easegress's FaaSFunction will be active not matter there are requests or not. Easegress will only route ingress traffic to FaaSProvider when the function is in the active state.
Inactive: Stopping function execution by calling FaaSController's stop RESTful API and it will run into inactive. Updating function's spec for image URL or other fields, or deleting function also need to stop it first.
Failed: The function will be turned into failed states during the runtime checking. If it's about some configuration error, e.g., wrong docker image URL, we can detect this failure by function's status message and then update the function's spec by calling RESTful API. If it's about some temporal failure caused by FaaSProvider, the function will turn into the initial state after FaaSProvider is recovered.

                  Provision

                      │
                      │
                      │
                ┌─────▼──────┐      Start     ┌────────────┐
                │            │     Success    │            │
       ┌────────┤  Initial   ├────────────────►   Active   │
       │        │            │                │            ├──────┐
       │        └───┬───▲────┘                └────┬───▲───┘      │
       │            │   │                          │   │          │
       │            │   │                          │   │          │
       │      Errors│   │ Update             Stop  │   │ Start    │
       │            │   ├───────────┐              │   │Success   │
       │            │   │           │              │   │          │
       │        ┌───▼───┴────┐      │         ┌────▼───┴───┐      │
       │        │            │      └─────────┤            │      │
Delete │        │   Failed   │                │  Inactive  │      │
       │        │            ◄────────────────┤            │      │
       │        └───┬───▲────┘  Start Failed  └──────┬─────┘      │
       │            │   │                            │            │
       │            │   │              Errors        │            │
       │    Delete  │   └────────────────────────────┼────────────┘
       │            │                                │
       │            │                                │
       │        ┌───▼────────┐                       │
       │        │            │          Delete       │
       └────────►  Destory   ◄───────────────────────┘
                │            │
                └────────────┘

Original State	Event	New State
initial	Checking the status in FaaSProvider by FaaSController automatically, and it's ready	active
initial	Checking the status in FaaSProvider by FaaSController automatically, and it's has some faults	failed
initial	Checking the status in FaaSProvider by FaaSController automatically, and it's waiting on all resources to become ready	initial
initial	Deleting the function by RESTful API	destroyed
active	Checking the status of instance in FaaSProvider by FaaSController automatically, and it has some faults	failed
active	Checking the status of instance in FaaSProvider by FaaSController automatically, and for something reason, some resources are missing or pending	failed
active	Stoping the function by RESTful API	inactive
active	Checking the status of instance in FaaSProvider by FaaSController automatically, and it's healthy	active
inactive	Updating the function by RESTful API	initial
inactive	Deleting the function by RESTful API	destroyed
inactive	Staring the function by RESTful API and after successfully checking the status in FaaSProvider by FaaSController automatically	active
inactive	Staring the function by RESTful API but failing at checking status in FaaSProvider by FaaSController automatically	failed
inactive	Staring the function by RESTful API, Checking the status of instance in FaaSProvider by FaaSController automatically, and for something reason, some resources are missing or pending	failed
failed	Updating the function by RESTful API	initial
failed	Deleting the function by RESTful API	destroyed
failed	Checking the status in FaaSProvider by FaaSController automatically, and it's ready again	initial
failed	Checking the status of instance in FaaSProvider by FaaSController automatically, and for something reason, some resources are missing or pending	failed
failed	Checking the status in FaaSProvider by FaaSController automatically, and it has some faults	failed

RESTful APIs

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

Operation	URL	Method	Body	Description
Create a function	https://eg-host/apis/v1/faas/{controller_name}	POST	function spec	When there is not such a function in Easegress
Start a function	https://eg-host/apis/v1/faas/{controller_name}/{function_name}/start	PUT	empty	When function is in `inactive` state only, it will turn-on accepting traffic for this function
Stop a function	https://eg-host/apis/v1/faas/{controller_name}/demo1/stop	PUT	empty	When function is in `active` state only, it will turn-off accpeting traffic for this function
Update a function	https://eg-host/apis/v1/faas/{controller_name}/{function_name}	PUT	function spec	When function is in `initial`, `inactive` or `failed` state. It can used to update your function or fix your function's deployment problem.
Delete a function	https://eg-host/apis/v1/faas/{controller_name}/{function_name}	DELETE	empty	When function is in `initial`, `inactive` or `failed` states.
Get a function	https://eg-host/apis/v1/faas/{controller_name}/{function_name}	GET	empty	No timing limitation.
Get function list	https://eg-host/apis/v1/faas/{controller_name}	GET	empty	No timing limitation.

Demoing

Creating the FaasController in Easegress

$ cd ./easegress/example/writer-001 && ./start.sh

$ ./egctl.sh object create -f ./faascontroller.yaml

$ ./egctl.sh object get faascontroller
name: faascontroller
kind: FaaSController 
provider: knative             # FaaS provider kind, currently we only support Knative

syncInterval: 10s

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

knative:
   networkLayerURL: https://10.109.159.129
   hostSuffix: example.com

Creating the function

$ curl --data-binary @./function.yaml -X POST -H 'Content-Type: text/vnd.yaml' https://127.0.0.1:12381/apis/v1/faas/faascontroller

Waiting for the function provisioned successfully. Confirmed by using Get API for checking the state field

$ curl https://127.0.0.1:12381/apis/v1/faas/faascontroller/demo10
spec:
  name: demo10
  image: dev.local/colordeploy:17.0
  port: 8089
  autoScaleType: rps
  autoScaleValue: "111"
  minReplica: 1
  maxReplica: 3
  limitCPU: 180m
  limitMemory: 100Mi
  requestCPU: 80m
  requestMemory: 20Mi
  requestAdaptor:
    host: ""
    method: ""
    header:
      del: []
      set:
        X-Func: func-demo
        X-Func1: func-demo-10
      add: {}
    body: ""
status:
  name: demo10
  state: active
  event: ready 
  extData: {}
fsm: null

Visiting function by HTTP traffic gate with X-FaaS-Func-Name: demo10 in HTTP header.

$ curl https://127.0.0.1:10083/tomcat/job/api -H "X-FaaS-Func-Name: demo10" -X POST -d ‘{"megaease":"Hello Easegress+Knative"}’ 
V3 Body is 
‘{megaease:Hello Easegress+Knative}’%  

$ curl https://127.0.0.1:10083/tomcat/job/api -H "X-FaaS-Func-Name: demo10" -X POST -d ‘{"FaaS":"Cool"}’ 
V3 Body is 
‘{FaaS:Cool}’%

The function's API is serving in /tomcat/job/api path and its logic is displaying "V3 body is" with the contents u post.

Reference

knative website https://knative.dev
Install knative serving via YAML https://knative.dev/docs/install/install-serving-with-yaml
resource quota https://kubernetes.io/docs/concepts/policy/resource-quotas/
AWS Lambda state https://aws.amazon.com/blogs/compute/tracking-the-state-of-lambda-functions/

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

faascontroller.md

faascontroller.md

FaaSController

Prerequisites

Configuration

Controller spec

FaaSFunction spec

Lifecycle

RESTful APIs

Demoing

Reference

Files

faascontroller.md

Latest commit

History

faascontroller.md

File metadata and controls

FaaSController

Prerequisites

Configuration

Controller spec

FaaSFunction spec

Lifecycle

RESTful APIs

Demoing

Reference