Introducing Serverless Kube Watch Trigger: Declarative Event Triggers for Kubernetes

Today we’re releasing something small, simple, and surprisingly powerful: serverless-kube-watch-trigger, a Kubernetes Custom Resource Definition that turns cluster events into HTTP calls — directly and declaratively.

No glue scripts. No extra brokers. No complex controllers. Just YAML.

❓ Why We Built It

When working on HariKube, we realized a missing piece: while Kubernetes could scale and orchestrate workloads, there was no simple, built-in way to react to events without writing Go code. Operators work great for stateful loops, but not every use case needs a controller.

We wanted a native, minimal way to say:

“When this Deployment changes, send an HTTP request.”

That’s what serverless-kube-watch-trigger does.

🔌 What It Does

serverless-kube-watch-trigger listens to changes in Kubernetes resources and performs HTTP requests when those changes match defined filters.

You describe what to watch, what to send, and where to send it.

That’s all.

Here’s the full example:

apiVersion: triggers.example.com/v1

kind: HTTPTrigger

metadata:

  name: full-httptrigger-example

  namespace: default

spec:

  resource:

    apiVersion: apps/v1

    kind: Deployment

  namespaces:

    - default

    - kube-system

  labelSelectors:

    - app=frontend

    - tier=prod

  fieldSelectors:

    - metadata.name=my-deployment

  eventTypes:

    - ADDED

    - MODIFIED

    - DELETED

  eventFilter: 'ne .old.status.availableReplicas .new.status.availableReplicas'

  concurrency: 5

  sendInitialEvents: false

  url:

    static: "https://example.com/hook"

    # template: "https://example.com/hook/{{ .metadata.name }}"

    # service:

    #   name: webhook-svc

    #   namespace: default

    #   uri:

    #     template: "/hook/{{ .metadata.name }}"

  method: POST

  auth:

    basicAuth:

      user: ci-bot

      secretKeyRef:

        name: webhook-pass

        key: password

    tls:

      caRef:

        name: webhook-ca

        key: ca.crt

      certRef:

        name: webhook-cert

        key: tls.crt

      keyRef:

        name: webhook-cert

        key: tls.key

      insecureSkipVerify: false

  headers:

    static:

      X-Static-Token: "fixed-token-value"

      X-Cluster-ID: "cluster-001"

    template:

      X-Resource-Name: "{{ .metadata.name }}"

      X-Resource-Namespace: "{{ .metadata.namespace }}"

    fromSecretRef:

      X-Api-Key:

        name: api-secret

        key: api-key

      X-Other-Token:

        name: extra-secrets

        key: token

  body:

    contentType: application/json

    template: |

      {{ toJson . }}

    signature:

      header: X-Signature

      keySecretRef:

        name: sig-key

        key: key

      hmac:

        hashType: SHA512

  delivery:

    timeout: 30s

    retries: 5

Install the controller.

kubectl apply -f https://github.com/mhmxs/serverless-kube-watch-trigger/releases/download/beta-v1.0.0-0/bundle.yaml

Apply the custom resource, and whenever a Deployment’s replica count changes, Kubernetes will POST its event as JSON to your endpoint.

⚡ How It Fits Into HariKube

Within the HariKube ecosystem, serverless-kube-watch-trigger acts as the simplest way to build event-driven systems:

• It connects Kubernetes watches directly to functions or APIs.


• It works out of the box with OpenFaaS, Knative, or any HTTP endpoint.


• It uses no custom controller logic — just Kubernetes’ built-in reconciliation.

This aligns with HariKube’s philosophy: let Kubernetes be the platform.

Instead of bolting on more systems, reuse what already exists — RBAC, namespaces, CRDs, and event streams — and keep logic outside the cluster.

🧠 Final Thoughts

Kubernetes has grown into the universal runtime for everything from batch jobs to databases. With HariKube’s data fabric and serverless-kube-watch-trigger’s declarative event hooks, it’s now also becoming the runtime for events and automation.

Small building blocks. Clear contracts. Native integration.

That’s the direction we’re heading.

If you want to try it or contribute, the README in the repository has all the details.

Sounds interesting? Learn how HariKube unifies different service design strategies into a single hybrid architecture. [→]

That’s it! You’ve just built a Kubernetes cluster that’s ready for serious data handling. With HariKube, you can design your own data topology and take advantage of lower latency, higher throughput, true data isolation, virtually unlimited storage, and a much simpler development experience. HariKube supports both flat and hierarchical topologies, so you can organize your databases like leaves on a tree.

Thank you for following along! If you have questions or ideas, please share them—we’d love to hear from you.