1.6.0

Quick Highlight

• Quick Highlight
  • Configurable function-level timeout
  • Ingress host, path, annotations and TLS support
    • Ingress annotations (--ingressannotation)
    • Ingress host rule (--ingressrule)
    • Ingress TLS (--ingresstls)
  • Annotations support for router service
  • PodSpec in Environment
  • Deploy router as DaemonSet
  • Router now supports encoded URL

Configurable function-level timeout

Before 1.6, router had a fixed timeout for functions. Some functions are longer running than others hence there was a request for per function timeout.

In 1.6, a new flag called --fntimeout was added to function sub command. To setup the timeout for functions, you can use --fntimeout value, --ft value when creating/updating the function. If a functions does not specify function-level timeout then the default timeout will be 60 seconds.

--fntimeout value, --ft value

Time duration to wait for the response while executing the function.
If the flag is not provided, by default it will wait of 60s for the response. (default: 60)

For details, see PR#1284.

Ingress host, path, annotations and TLS support

Ingress is a Kubernetes built-in resource that allows accessing Kubernetes services from outside of cluster with help of a ingress controller. There are many ingress controllers available to use webpage.

Fission supported ingress but without the support for TLS, host field and ingress annotations. 1.6 release adds support for all three. Related issue

Ingress annotations (--ingressannotation)

You can specify annotations to ingress when creating the HTTP trigger. If you want to disable TLS auto redirect and enable regular expression matching in NGINX Ingress Controller, you can add annotations such as:

$ fission route create --name foo \
    --url /foo --function foofn --createingress \
    --ingressannotation "nginx.ingress.kubernetes.io/ssl-redirect=false" \
    --ingressannotation "nginx.ingress.kubernetes.io/use-regex=true"

NOTE: The format of annotation depends on the underlying ingress controller being used. You should check the respective documentation for details.

Ingress host rule (--ingressrule)

The format of rule is host=path, you have to give host and API endpoint path with delimiter = between them. If the rule is not provided, fission uses path specified by --url and allows requests from all hosts. For example, if you want to expose your function to the path /foobar and allow access from all hosts, you can do:

$ fission route create --name foobar --method GET --function nodejs --url "/foobar" --createingress --ingressrule "*=/foobar"

Which results in ingress definition like below:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: foobar
  namespace: fission
  ...
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: router
          servicePort: 80
        path: /foobar

If you want to limit the accessibility of function to a specific hosts, specify the host rule like --ingressrule "example.com=/foobar":

spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: router
          servicePort: 80
        path: /foobar

NOTE: The format of rule depends on the underlying ingress controller you are using.

In case of NGINX Ingress Controller for example, to support wildcard path you need to:

• Enable regular expression matching by adding annotation to the Ingress.
• Specify the router URL as /foo/{bar} and set path to /foo/*. (Issue)

$ fission route create --name foo \
        --url /foo/{bar} --function foofn --createingress \
        --ingressannotation "nginx.ingress.kubernetes.io/use-regex=true" \
        --ingressrule "*=/foo/*"

Ingress TLS (--ingresstls)

To enable TLS termination, you need to follow the guide to create the secret that contains TLS private key and certificate. For Fission you just have to specify the secret name when creating HTTP trigger.

$ fission route create --name foo \
    --url /foo/{bar} --function foofn --createingress \
    --ingressannotation "nginx.ingress.kubernetes.io/ssl-redirect=false" \
    --ingressannotation "nginx.ingress.kubernetes.io/use-regex=true" \
    --ingressrule "*=/foo/*"
    --ingresstls "foobartls"

For details, see PR#1325 and PR#1326.

Annotations support for router service

Router now supports addition of annotations so the LoadBalancer created in your cloud provider can be customized to your needs. The specifics of annotations vary from cloud to cloud and you should check the related documentation.

For ex. On GKE, a LoadBalancer type service by default is accessible from the outside of Kubernetes cluster. But if you instead want to expose service to the applications that use the same VPC network and are located in the same GCP region, you can do by adding an extra annotation to the Service.

To enable internal LoadBalancer, you need to uncomment the svcAnnotations in chart’s values.yaml.

router:
  svcAnnotations:
    cloud.google.com/load-balancer-type: Internal

For details, see PR#1338 and GKE doc.

PodSpec in Environment

PodSpec was introduced in Environment that allows users to modify the deployment created by Fission (Here is a blog post to demonstrate how to use PodSpec.). However, there was an issue reported when merging user-defined PodSpec in executor. In 1.6, we fixed the problem and now should work as expected.

It is worth noticing that the executor merges PodSpec using the following rules:

• Slices are merged and return an error if the elements in the slice have name conflicts. (Containers, Volumes, Ports, Env, VolumeMounts, VolumeDevices)
• Maps are merged, the value in user-defined PodSpec will override the value defined by Fission (if any).
• The rest of type of the fields like pointer, string and int are overridden directly.

Once you have applied the fission spec, it is a good idea to check the resulting deployment.

$ kubectl -n fission-function get deploy <name> -o yaml

If you don’t see any deployment is created, it may due to the wrong PodSpec was generated. You need to follow the instruction here to check executor log for more details.

For details, see PR#1339 and blog post.

Deploy router as DaemonSet

ReplicaSet generated by Deployment distributes pods to nodes based on nodes resource usage, which means in some cases the newly created pods are assigned to only a few nodes. The requests will go to the same node if there are multiple router pods on it and may increase the burden of node resource and overall request latency.

To solve the problem mentioned above, now you can deploy the router as DaemonSet by setting router.deployAsDaemonSet to true when using helm to install Fission, in order to distribute requests across all nodes for better workload distribution and lower latency.

For details, see PR#1342.

Router now supports encoded URL

Fission uses gorilla/mux to match URL for functions and it by default matches path /foo%2Fbar/hello to /foo/bar/hello instead of URL path /{name}/hello. To enable encoded path support in router, you need to set router.useEncodedPath to true when using helm to install Fission.

For details, see issue and PR#1347.