The Fn Load Balancer (Fn LB) allows operators to deploy clusters of Fn servers and route traffic to them intelligently. Most importantly, it will route traffic to nodes where hot functions are running to ensure optimal performance, as well as distribute load if traffic to a specific function increases. It also gathers information about the entire cluster which you can use to know when to scale out (add more Fn servers) or in (decrease Fn servers).
You can run multiple Fn instances and balance the load amongst them using fnlb
as follows:
fnlb --listen <address-for-incoming> --nodes <node1>,<node2>,<node3>
And redirect all traffic to the load balancer.
NOTE: For the load balancer to be of use, all function nodes need to be sharing the same DB.
To build a docker image for fnlb
just run:
make docker-build
To start the fnlb
proxy with the addresses of functions nodes in a docker
container:
docker run -d --name fnlb -p 8081:8081 fnproject/lb:latest --nodes <node1>,<node2>
If running locally with functions servers in docker, running with docker links can make things easier (can use local addresses). for example:
docker run -d --name fn-8080 --privileged -p 8080:8080 fnproject/fnserver:latest
docker run -d --name fnlb --link fn-8080 -p 8081:8081 fnproject/lb:latest --nodes 127.0.0.1:8080
To make functions requests against the lb with the cli:
FN_API_URL=http://<fnlb_address> fn call my/function
To add a functions node later:
curl -sSL -X PUT -d '{"node":"<node>"}' <fnlb_address>/1/lb/nodes
<node>
should be the address of a functions server. The lb will health check
this and log if it cannot reach that node as well as stop sending requests to
that node until it begins passing health checks again. Any number of functions
servers may be added to the load balancer.
To permanently remove a functions node:
curl -sSL -X DELETE -d '{"node":"<node>"}' <fnlb_address>/1/lb/nodes
To list functions nodes and their state:
curl -sSL -X GET <fnlb_address>/1/lb/nodes
The fnlb supports a mode of operation which relies on Kubernetes to inform it as Fn pods come in and out of service. In order to run in this mode, some additional command-line flags are required. -db=k8s
will select Kubernetes operation; in this mode, the nodes
flag is ignored. -label-selector=...
is a standard Kubernetes selector expression.
A sample k8s configuration follows; this expects Fn pods to be labelled app=fn,role=fn-service
. By default, the lb will look in its own namespace for Fn pods. This can be changed by explicitly passing the -namespace=...
option.
apiVersion: v1
kind: Service
metadata:
name: fn-service
namespace: fn
labels:
app: fn
role: fn-lb
spec:
type: NodePort
ports:
- name: fn-service
port: 8080
targetPort: 8080
nodePort: 32180
selector:
app: fn
role: fn-lb
---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: fn-lb
namespace: fn
spec:
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
minReadySeconds: 30
template:
metadata:
labels:
app: fn
role: fn-lb
spec:
containers:
- name: fn-lb
image: fnproject/fnlb
imagePullPolicy: Always
args:
- "-db=k8s"
- "-label-selector=app=fn,role=fn-service"
- "-listen=:8080"
- "-mgmt-listen=:8080"
ports:
- containerPort: 8080
env:
- name: LOG_LEVEL
value: debug
In this mode, the shared database is not required; each lb will listen to the Kubernetes master independently to derive the same information. The lb nodes continue to health-check Fn pods in addition to the health checks running directly as part of a Pod definition.