openova/platform/knative
hatiyildiz 4043e1d51c docs(pass-32): registry-DNS sweep — harbor.<domain> across 9 component READMEs
Pass 25's deferred sweep, executed. Image refs of the form
harbor.<domain>/... (and one registry.<domain>/... in temporal) collapse
the location-code segment. Per NAMING §5.1, Catalyst per-host-cluster
Harbor DNS is harbor.{location-code}.{sovereign-domain} (e.g.
harbor.hfmp.openova.io).

Fixed (11 instances, 9 files):
- anthropic-adapter, bge (×2), debezium, harbor (×2 — ingress + Kyverno
  policy), knative (×2 — serving + traffic-split), llm-gateway, strimzi,
  trivy — all standardized to harbor.<location-code>.<sovereign-domain>.
- temporal had two drift items in one line: registry.<domain> (off-spec
  placeholder — Catalyst's only per-host-cluster registry is Harbor) AND
  legacy "fuse" namespace (renamed to bp-fabric per BUSINESS-STRATEGY
  §16.2 / Pass 26). Rewritten to fabric/order-worker.

Out of scope (deliberate): :latest tag hygiene, and whether Application
Blueprint READMEs should reference ghcr.io/openova-io/bp-<name>:<semver>
vs the Sovereign Harbor mirror. Stalwart customer-email-domain <domain>
placeholders preserved (correct semantics). external-dns illustrative
gslb/api/svc.<domain> preserved (upstream-doc generic).

With Pass 29 (canonical-doc DNS) + Pass 31 (carry-over fixes) + Pass 32
(image registry), the recurring DNS-placeholder collapse drift category
is addressed end-to-end.

Validation log Pass 32 entry added.
2026-04-27 22:36:39 +02:00
..
README.md docs(pass-32): registry-DNS sweep — harbor.<domain> across 9 component READMEs 2026-04-27 22:36:39 +02:00

Knative

Serverless platform for Kubernetes with scale-to-zero and event-driven capabilities. Application Blueprint (see docs/PLATFORM-TECH-STACK.md §4.6 — AI/ML). Used by bp-cortex (composite AI Hub Blueprint) as the serverless layer for KServe-managed model inference.

Status: Accepted | Updated: 2026-04-27


Overview

Knative provides serverless capabilities on Kubernetes. Used independently for event-driven workloads and as the foundation for KServe model serving.

flowchart TB
    subgraph Knative["Knative"]
        Serving[Knative Serving]
        Eventing[Knative Eventing]
    end

    subgraph Use Cases
        KServe[KServe<br/>Model Serving]
        Functions[Serverless<br/>Functions]
        Events[Event-Driven<br/>Workloads]
    end

    Serving --> KServe
    Serving --> Functions
    Eventing --> Events
    Eventing --> KServe

Components

Component Purpose
Knative Serving Request-driven compute, scale-to-zero
Knative Eventing Event-driven architecture, CloudEvents

Why Knative?

Feature Benefit
Scale-to-zero Cost savings for idle workloads
Auto-scaling Handles traffic spikes automatically
Revisions Traffic splitting, canary deployments
CloudEvents Standard event format
KServe foundation Required for ML model serving

Configuration

Helm Values

knative-serving:
  enabled: true
  config:
    network:
      ingress-class: "cilium"
      domain-template: "{{.Name}}.{{.Namespace}}.{{.Domain}}"
    autoscaler:
      enable-scale-to-zero: "true"
      scale-to-zero-grace-period: "30s"
      stable-window: "60s"

knative-eventing:
  enabled: true
  config:
    default-ch-webhook:
      default-ch-config: |
        clusterDefault:
          apiVersion: messaging.knative.dev/v1
          kind: InMemoryChannel        

Knative Service Example

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
        autoscaling.knative.dev/max-scale: "10"
    spec:
      containers:
        - image: harbor.<location-code>.<sovereign-domain>/my-app:latest
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

Traffic Splitting

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    metadata:
      name: my-service-v2
    spec:
      containers:
        - image: harbor.<location-code>.<sovereign-domain>/my-app:v2
  traffic:
    - revisionName: my-service-v1
      percent: 90
    - revisionName: my-service-v2
      percent: 10

Event-Driven Architecture

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: default
---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: my-trigger
spec:
  broker: default
  filter:
    attributes:
      type: my.event.type
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: my-service

Integration with Cilium

Knative uses Cilium as the ingress class:

config:
  network:
    ingress-class: "cilium"

Monitoring

Metric Query
Request count revision_request_count
Request latency revision_request_latencies
Pod count autoscaler_actual_pods
Desired pods autoscaler_desired_pods

Consequences

Positive:

  • Scale-to-zero reduces costs
  • Automatic scaling for traffic spikes
  • Foundation for KServe model serving
  • Event-driven architecture support
  • Traffic splitting for canary deployments

Negative:

  • Cold start latency for scale-to-zero
  • Additional complexity
  • Requires understanding of Knative concepts

Part of OpenOva