Version:

Function's specification

Serverless in Kyma allows you to create Functions in both Node.js (v14 & v16) and Python (v3.9). Although the Function's interface is unified, its specification differs depending on the runtime used to run the Function.

Signature

Function's code is represented by a handler that is a method that processes events. When your Function is invoked, it runs this handler method to process a given request and return a response.

All Functions have a predefined signature with elements common for all available runtimes:

Functions' code must be introduced by the main handler name.
Functions must accept two arguments that are passed to the Function handler:
- event
- context

See these signatures for each runtime:

Node.js
Python

Event object

The event object contains information about the event the Function refers to. For example, an API request event holds the HTTP request object.

Functions in Kyma accept CloudEvents (ce) with the following specification:

Node.js
Python

See the detailed descriptions of these fields:

Field	Description
ce-type	Type of the CloudEvent data related to the originating occurrence
ce-source	Unique context in which an event happened and can relate to an organization or a process
ce-eventtypeversion	Version of the CloudEvent type
ce-specversion	Version of the CloudEvent specification used for this event
ce-id	Unique identifier of the event
ce-time	Time at which the event was sent
data	Either JSON or a string, depending on the request type. Read more about Buffer in Node.js and bytes literals in Python.
tracer	Fully configured OpenTelemetry tracer object that allows you to communicate with the user-defined Jaeger service to share tracing data. For more information on how to use the tracer object see Use the OpenTelemetry standard
extensions	JSON object that can contain event payload, a Function's incoming request, or an outgoing response

Event object SDK

The event object is extended by methods making some operations easier. You can use every method by providing event.{FUNCTION_NAME(ARGUMENTS...)}.

Node.js
Python

Context object

The context object contains information about the Function's invocation, such as runtime details, execution timeout, or memory limits.

See sample context details:

Click to copy

...
{ "function-name": "main",
  "timeout": 180,
  "runtime": "nodejs16",
  "memory-limit": 200Mi }

See the detailed descriptions of these fields:

Field	Description
function-name	Name of the invoked Function
timeout	Time, in seconds, after which the system cancels the request to invoke the Function
runtime	Environment used to run the Function. You can use `nodejs16`, `nodejs16`, or `python39`.
memory-limit	Maximum amount of memory assigned to run a Function

HTTP requests

You can use the event.extensions.request object to access properties and methods of a given request that vary depending on the runtime. For more information, read the API documentation for Node.js Express and Python.

Custom HTTP responses

Node.js
Python

/metrics endpoint

You can use the /metrics endpoint to return the Function metrics. All the information is gathered using Prometheus and can be displayed using the Grafana dashboard (see Kyma observability for more information on how to use Grafana dashboard in Kyma). As this endpoint is provided by Kubeless, it cannot be customized.
For more information, see Kubeless monitoring and Kubeless runtime variants pages.

NOTE: Prometheus and Grafana are deprecated and are planned to be removed. If you want to install a custom stack, take a look at Install a custom kube-prometheus-stack in Kyma.

Override runtime image

You can use a custom runtime image to override the existing one. Your image must meet all the following requirements:

Expose the workload endpoint on the right port
Provide liveness and readiness check endpoints at /healthz
Fetch sources from the path under the KUBELESS_INSTALL_VOLUME environment
Security support. Kyma runtimes are secure by default. You only need to protect your images.

Note: For better understanding you can look at main dockerfiles which are responsible for building the final image based on the base_image argument which you as an user can override and what we are doing in this tutorial.

Every Function's Pods container have the same system environments which helps you configure the Functions server. For more information, read the Environment variables page.