cloudparts

KubelessArchived

An archived Kubernetes-native functions framework: each function was a custom resource that a controller turned into its own Deployment and Service, triggered over HTTP, by cron or from Kafka, NATS or Kinesis.

What it is
Serverless functions (FaaS)
Type
Open source
Made by
VMware (from Bitnami, started at Skippbox)
License
Apache 2.0
Status
Archived since 25 August 2021
Facts checked
23 October 2026
Website Source code (archived)

What it is

Kubeless added a Function custom resource to Kubernetes. You deployed code with kubeless function deploy, naming a runtime such as Python, Node.js, Go, Ruby, PHP, Java, .NET Core or Ballerina, and a controller in the cluster created a Deployment and a ClusterIP Service for that function. The code itself travelled inside the custom resource and was mounted into the runtime pod from a ConfigMap, with an init container installing its dependencies, so a function’s source had to fit in a single etcd entry of 1 MB.

Every runtime was a small web server (Express for Node.js, Bottle for Python, Sinatra for Ruby) that called a handler taking an event and a context. Triggers were separate custom resources with their own controllers: an HTTP trigger created an Ingress, a cron trigger a Kubernetes CronJob, and Kafka, NATS and AWS Kinesis triggers ran consumers that called the function for each message. Scaling used a standard HorizontalPodAutoscaler on CPU or requests per second, with at least one pod per function, so there was no scale to zero.

Kubeless was one of the first function frameworks built on Kubernetes custom resources. It started in late 2016 at Skippbox, which Bitnami bought in 2017, and moved to VMware when VMware acquired Bitnami in 2019. VMware stopped maintaining it in August 2021, and the repository has been archived since.

Why teams pick it

  • Functions were plain Kubernetes objects: a custom resource, a Deployment and a Service, visible to kubectl and existing tooling
  • A uniform handler(event, context) interface across languages and across HTTP, cron and message triggers
  • Simple to read and extend: adding a runtime meant building an image, and each trigger type was its own small controller

Watch out for

  • Unmaintained since August 2021 and tested only up to Kubernetes 1.15; its runtime images target language versions that have long reached end of life, such as Node.js 8 and Python 3.6
  • No scale to zero: every function kept at least one pod running
  • Function code lived inside the custom resource, which capped it at etcd’s 1 MB entry size
  • Kafka triggers invoked functions at most once, so a failed call could lose a message

Alternatives, recommended first

What all serverless functions (faas) have in common →Compare side by side →
FissionOpen sourceOpen-source functions on Kubernetes: a pool of warm, generic pods takes your code on the first call, so cold starts stay around 100 ms.NuclioOpen sourceOpen-source functions for Kubernetes or plain Docker, built for event streams and data work: each function is a long-running processor that reads from HTTP, Kafka, Kinesis, MQTT and other sources with several parallel workers.

How it fits with other technologies

Deploy a Python function, call it, then expose it and schedule it · bash

# test.py:  def hello(event, context): return event['data']
kubeless function deploy hello --runtime python3.8 \
  --from-file test.py --handler test.hello

kubeless function call hello --data 'Hello world!'

kubeless trigger http create hello --function-name hello
kubeless trigger cronjob create hello-every-minute \
  --function hello --schedule "*/1 * * * *"

See it in a real stack

No architecture uses Kubeless yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2016–2021

Kubeless grew out of work by Sebastien Goasguen, founder of the Kubernetes start-up Skippbox; its repository was created in November 2016. The idea was to make functions first-class objects in the cluster, using Kubernetes’ extension mechanism for custom resource types, with a controller that turned each one into ordinary Deployments and Services.

Bitnami bought Skippbox in March 2017 and kept developing Kubeless; in May 2017 RedMonk described it as a serverless framework native to Kubernetes, competing with Fission, funktion, funcatron and OpenWhisk, with functions as custom resources, Node.js and Python runtimes, and Kafka for pub/sub. More languages and triggers followed, and version 1.0 arrived in November 2018.

VMware announced it would acquire Bitnami in May 2019, and Kubeless moved with it. Releases slowed to v1.0.8 in January 2021. On August 25, 2021, VMware added a notice that it no longer maintained the project and invited anyone to take it over as a fork; no fork was linked, the last commit landed in December 2021, and the repository now lives read-only under the vmware-archive organization.

Why it’s built this way

Functions as custom resources
Making a function a Kubernetes object let the project reuse Deployments, Services, Ingress and autoscalers instead of building its own scheduler or router.
One Deployment per function
Each function scaled and failed on its own using standard Kubernetes parts, at the cost of at least one idle pod per function and pod-start cold starts.
Code stored in the custom resource
Keeping the source in the Function object meant no separate artifact store or image build was needed for small functions, which also limited code to what fits in etcd.

Timeline

  1. 2016

    Repository created at Skippbox in November

  2. 2017

    Bitnami acquires Skippbox in March and continues Kubeless

  3. 2018

    Version 1.0.0 released in November

  4. 2019

    VMware announces it will acquire Bitnami

  5. 2021

    Last release v1.0.8 in January; VMware ends maintenance in August

Sources9 · facts checked 23 October 2026

Improve this page on GitHub