- Quick Start
- Function Characteristics
- PubSub Mechanism
- Expose and Secure Functions
- Data Stream Events
- Debug Functions
- Build Function Images
- Advanced deployment
- Kubeless Configuration
- Use a Custom Apache Kafka
- Install Troubleshooting
- Cloud Providers
- Azure Kubernetes Service
- Google Kubernetes Engine
- Development Guide
- Implementing a New Runtime
- Implementing a New Trigger
- Release Flow
Functions are the main entity in Kubeless. It is possible to write Functions in different languages but all of them share common properties like the generic interface, the default timeout or the runtime UID. In this document we are going to explain some these common properties and different runtimes availables in Kubeless. You can find in depth details about the Function specification here.
Every function receives two arguments:
context. The first argument contains information about the source of the event that the function has received. The second contains general information about the function like its name or maximum timeout. This is a representation in YAML of a Kafka event:
event: data: # Event data foo: "bar" # The data is parsed as JSON when required event-id: "2ebb072eb24264f55b3fff" # Event ID event-type: "application/json" # Event content type event-time: "2009-11-10 23:00:00 +0000 UTC" # Timestamp of the event source event-namespace: "kafkatriggers.kubeless.io" # Event emitter extensions: # Optional parameters request: ... # Reference to the request received response: ... # Reference to the response to send # (specific properties will depend on the function language) context: function-name: "pubsub-nodejs" timeout: "180" runtime: "nodejs6" memory-limit: "128M"
Functions should return a string that will be used as the HTTP response for the caller. Some runtimes may support different types (like objects) for the returned values.
You can check basic examples of every language supported in the examples folder.
Runtimes have a maximum timeout set by the environment variable FUNC_TIMEOUT. This environment variable can be set using the CLI option
--timeout. The default value is 180 seconds. If a function takes more than that in being executed, the process will be terminated.
As a Security Context functions are configured to run with an unprivileged user (UID 1000) by default (except for OpenShift where the UID is automatically set). This prevent functions from having root privileges. This default behaviour can be overridden specifying a different Security Context in the
Deployment template that is part of the Function Spec.
It is possible to deploy functions that should be triggered following a certain schedule. For specifying the execution frequency we use the Cron format. Every time a scheduled function is executed, a Job is started. This Job will do a HTTP GET request to the function service and will be successful as far as the function returns 200 OK.
For executing scheduled functions we use Kubernetes CronJobs using mostly the default options which means:
- If a Job fails, it won't be restarted but it will be retried in the next scheduled event. The maximum time that a Job will exist is specified with the function timeout (180 seconds by default).
- The concurrency policy is set to
Allow so concurrent jobs may exists.
- The history limit is set to maintain as maximum three successful jobs (and one failed).
If for some reason you want to modify one of the default values for a certain function you can execute
kubectl edit cronjob trigger-<func_name> (where
func_name is the name of your function) and modify the fields required. Once it is saved the CronJob will be updated.
Some Kubeless runtimes expose metrics at
/metrics endpoint and these metrics will be collected by Prometheus. We also include a prometheus setup in
manifests/monitoring to help you easier set it up. The metrics collected are: Number of calls, succeeded and error executions and the time spent per call.
Check this document to get more details about supported runtimes and languages.