A New Serverless Plugin: Kubeless
But first couple thoughts: I was recently at the first JeffConf a community led one day conference to focus on the users of serverless and get past the name. Two things struck me:
1The user base! Serverless in general has a ton of users. And not just beginners, there were some super advanced technical discussions around real use cases during the open space. Things like scaling lambdas for apps with unpredictable bursts of 150k requests/sec… Users are mostly on AWS lambda but no doubt that other clouds will pick up.
2The serverless framework from serverless.com is by the far the main tool to deploy functions. Wirtten in Node.js, and with support for Lambda, Azure Functions, Google Cloud Functions and Apache Openwhisk, it is the leading serverless abstraction for deployment of functions.
So for Bitnami to spend some energy on one new application paradigm makes total sense. Piggy backing on our Kubernetes work and building kubeless on top of Kubernetes is the logical step for us.
Yes, Kubeless is Kubernetes Native. That means that you need a Kubernetes cluster to run Kubeless, you cannot run it without. So check that you have a Kubernetes endpoint:
$ kubectl version
$ kubectl get nodes
Now download the `kubeless` CLI (e.g on OSX with brew), create a k8s namespace to put kubeless in and deploy it using the released manifest:
$ brew install kubeless/tap/kubeless
$ kubectl create ns kubeless
$ curl -sL https://github.com/kubeless/kubeless/releases/download/0.0.18/kubeless-0.0.18.yaml | kubectl create -f -
Once all the pods are up and running you are ready to deploy functions:
$ kubeless function ls
$ kubeless function deploy — help
I will skip talking about all the features (e.g Node.js and Python runtimes, HTTP and event triggers…) because this post is only about the Serverless plugin.
Kubeless Serverless Plugin
The first thing to notice about the kubeless plugin is that it is being developed upstream in the serverless organization. Austen Collins and Philipp Muens have been very welcoming and super helpful.
Second, the main framework will soon remove a provider validation which will allow kubeless to become a first class citizen.
Third, we contributed a template creation step so that you can use the framework to generate function skeletons using the `serverless` cli.
Once those PRs are merged and a new
serverless is released, here is what you will be able to do with kubeless:
Create a function template
$ serverless create — template kubeless-nodejs — path foobar
Serverless: Generating boilerplate…
Serverless: Generating boilerplate in “/Users/sebgoa/Desktop/foobar”
| _ . — — -. — — . — . — . — — -. — — | . — — -. — — -. — — -.
| |___| -__| _| | | -__| _| | -__|__ — |__ — |
|____ |_____|__| \___/|_____|__| |__|_____|_____|_____|
| | | The Serverless Application Framework
| | serverless.com, v1.17.0
— — — -’
Serverless: Successfully generated boilerplate for template: “kubeless-nodejs”
sebgoa@foobar $ tree foobar
serverless.yml looks something like:
Note the support for multiple language runtimes and deploying functions in different kubernetes namespace. Support for function memory allocation, environment variable and labels is coming super shortly. By default a function is HTTP triggered but we also support event triggers.
Deploy a function
This is the standard
serverless usage. Multiple functions can be defined in a service. Removing a function is also supported (thankfully :))
$ serverless deploy
Serverless: Packaging service…
Serverless: Deploying function capitalize…
Serverless: Function capitalize succesfully deployed
$ serverless remove
Invoke a function
$ serverless invoke -f capitalize -d “foobar” -l
Serverless: Calling function: capitalize…
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Logs and Info
In the information about a function you can Kubernetes specific metadata, like the Self Link and port definitions. Each function is exposed via a k8s service. Ingress support for functions that need to be externally exposed is currently in a PR under on-going review.
$ serverless info -v
Service Information “capitalize”
Cluster IP: 10.0.0.228
Target Port: 8080
Node Port: 30710
Self Link: /api/v1/namespaces/foobar/services/capitalize
The coverage is almost complete. What we need to add now is better metadata in kubeless itself so that a function deployed on AWS Lambda or any other provider can be also deployed in Kubeless (granted a few function interfaces issues).
But the door is open now. You can use
kubeless . And that means you can have a serverless solution on-premise that mimics what you find in a public cloud.