Serverless Kubernetes Operator: Adapting an Existing Operator to Knative’s Scale‑to‑Zero

In the first two parts of this series we introduced the problem that a Kubernetes Operator can consume significant resources at scale and presented the idea of reducing its impact by scaling the controller to zero when idle using server‑less techniques.

The final part demonstrates how to adapt an existing Operator to take advantage of Knative’s built‑in scale‑to‑zero capabilities.

Operator Architecture

At a low level a typical Operator watches changes in the Kubernetes backing store (etcd) via an Informer, queues events, and ensures only one reconciler handles a given object at a time. The Informer continuously watches events while the reconciler runs only when items are placed in the work queue, making it the primary candidate for applying Knative’s scale‑to‑zero.

Since Knative Eventing 0.6 provides a CloudEvent source for Kubernetes API‑server events, combining this source with Knative’s scale‑to‑zero feature allows the controller to be idle without consuming resources, while the notifier can be shared among multiple Operators.

Serverless Sample Controller

We start from the sample controller project that defines a new CRD Foo and a controller that creates a Deployment for each Foo object.

apiVersion: samplecontroller.k8s.io/v1alpha1
kind: Foo
metadata:
  name: example-foo
spec:
  deploymentName: example-foo
  replicas: 1
  generates:
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: example-foo
      ownerReferences:
      - apiVersion: samplecontroller.k8s.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: Foo
        name: example-foo
    spec: ...

To make the Foo operator serverless we removed the custom notifier, letting the API‑server event source handle change detection, and added a generic notifier that queues incoming CloudEvents. All indexer calls are now directed to the API server.

We then added an ApiServerSource to watch Foo and Deployment events:

apiVersion: sources.eventing.knative.dev/v1alpha1
kind: ApiServerSource
metadata:
  name: example-foo
spec:
  serviceAccountName: example-foo
  resources:
  - apiVersion: samplecontroller.knative.io/v1alpha1
    kind: Foo
  - apiVersion: apps/v1
    kind: Deployment
  controller: true
  sink:
    apiVersion: serving.knative.dev/v1alpha1
    kind: Service
    name: example-foo-reconcile

Next we deployed the reconciler as a Knative Service, configuring the pod autoscaler to limit concurrency to one and to use a 30‑second stability window:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: example-foo-reconcile
spec:
  runLatest:
    configuration:
      revisionTemplate:
        metadata:
          annotations:
            autoscaling.knative.dev/maxScale: "1"
            autoscaling.knative.dev/window: "30s"
        spec:
          container:
            image: $DOCKER_USER/knative-sample-controller
            serviceAccountName: example-foo-reconcile

Running the modified controller shows the reconciler scaling down to zero when no Foo objects are present. Compared with the original sample controller, the Knative‑based solution has a few current limitations:

Event filtering in Knative Eventing 0.6 does not monitor Deployments.

If the reconciler container crashes, the event importer does not replay events, potentially leaving the system inconsistent.

No periodic event synchronization.

These limitations are expected to be addressed in future Knative releases.

The article concludes the series on serverless Operators, having demonstrated two approaches to scale an Operator to zero: one that works with existing Operator deployments and another that leverages Knative’s native serverless capabilities.