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.
|
||
|---|---|---|
| .. | ||
| README.md | ||
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