Bring per-component READMEs in line with the canonical glossary
(docs/GLOSSARY.md). Substantive architectural content unchanged —
this is a terminology + reference correctness pass.
Placeholder rename: <tenant> → <org> in YAML / IaC examples across
- platform/cnpg/README.md (Cluster + Pooler + ScheduledBackup)
- platform/debezium/README.md (PostgreSQL connector + topic patterns)
- platform/external-secrets/README.md (ExternalSecret / SecretStore)
- platform/grafana/README.md (Instrumentation namespace)
- platform/k8gb/README.md (Gslb + namespace + kubectl examples)
- platform/keda/README.md (ScaledObject + Kafka triggers + Prometheus)
- platform/opentofu/README.md (server resource example)
- platform/velero/README.md (BackupStorageLocation buckets)
- platform/vpa/README.md (VerticalPodAutoscaler examples)
- platform/flux/README.md (kustomization name + tenants/ → organizations/)
"Catalyst IDP" → "Catalyst console":
- platform/crossplane/README.md (integration section retitled and
rewritten — Crossplane is platform
plumbing, not user-facing)
- platform/gitea/README.md (architecture diagram + integration table)
- platform/kyverno/README.md (rollout tracking surface)
- products/fingate/README.md (TPP onboarding portal)
"Bootstrap wizard" → "Catalyst bootstrap":
- platform/openbao/README.md (bootstrap procedure rewritten —
independent Raft per region clarified;
cross-references docs/SECURITY.md §5)
- platform/opentofu/README.md (Quick Start)
Kyverno labels & prose:
- openova.io/tenant → openova.io/organization (label rename for
consistency; deployed clusters will add new label as a co-label
during migration window)
- "tenant labels" / "tenant namespace" prose updated to
"Organization labels" / "Organization-labeled namespace"
- Priority class names (tenant-high, tenant-default, tenant-batch)
retained as deployed artifact names — rename pending in a
separate migration ticket
No banned-term hits remain in component READMEs (verified by grep
in docs/GLOSSARY.md banned-terms table).
Refs #37
|
||
|---|---|---|
| .. | ||
| README.md | ||
KEDA
Event-driven horizontal autoscaling for OpenOva platform.
Status: Accepted | Updated: 2026-01-16
Overview
KEDA (Kubernetes Event-driven Autoscaling) provides horizontal pod autoscaling based on external metrics and events:
- Queue-based scaling (Kafka via Strimzi)
- Metric-based scaling (Prometheus, custom metrics)
- Cron-based scaling
- Scale-to-zero capability
Architecture
flowchart TB
subgraph KEDA["KEDA"]
Operator[KEDA Operator]
Metrics[Metrics Adapter]
end
subgraph Sources["Event Sources"]
Kafka[Kafka]
Prometheus[Prometheus/Mimir]
Cron[Cron]
end
subgraph Workloads["Workloads"]
Deploy[Deployments]
Pods[Pods]
end
Sources --> Operator
Operator --> Deploy
Deploy --> Pods
Metrics --> Operator
Scalers
| Scaler | Use Case |
|---|---|
| kafka | Kafka consumer lag |
| prometheus | Custom metrics |
| cron | Time-based scaling |
| cpu/memory | Resource utilization |
Configuration
ScaledObject
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: <org>-worker
namespace: <org>
spec:
scaleTargetRef:
name: <org>-worker
minReplicaCount: 1
maxReplicaCount: 10
cooldownPeriod: 300
triggers:
- type: kafka
metadata:
bootstrapServers: kafka-kafka-bootstrap.databases.svc:9092
consumerGroup: <org>-workers
topic: <org>-jobs
lagThreshold: "100"
Prometheus Scaler
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: <org>-api
namespace: <org>
spec:
scaleTargetRef:
name: <org>-api
minReplicaCount: 2
maxReplicaCount: 20
triggers:
- type: prometheus
metadata:
serverAddress: http://mimir.monitoring.svc:8080/prometheus
metricName: http_requests_per_second
query: |
sum(rate(http_requests_total{namespace="<org>"}[1m]))
threshold: "100"
Cron Scaler
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: <org>-batch
namespace: <org>
spec:
scaleTargetRef:
name: <org>-batch
minReplicaCount: 0
maxReplicaCount: 5
triggers:
- type: cron
metadata:
timezone: UTC
start: "0 8 * * 1-5"
end: "0 18 * * 1-5"
desiredReplicas: "3"
VPA + KEDA Coordination
flowchart LR
subgraph Scaling["Scaling"]
VPA[VPA<br/>Vertical]
KEDA[KEDA<br/>Horizontal]
end
subgraph Workload["Workload"]
Deploy[Deployment]
Pods[Pods]
end
VPA -->|"Right-size resources"| Pods
KEDA -->|"Scale replicas"| Deploy
Deploy --> Pods
- VPA: Optimizes CPU/memory per pod
- KEDA: Scales replica count based on events
- Combined: Optimal resource utilization with event-driven elasticity
Scale-to-Zero
KEDA supports scaling to zero for batch workloads:
spec:
minReplicaCount: 0 # Allow scale-to-zero
idleReplicaCount: 0 # Scale to zero when idle
Monitoring
| Metric | Description |
|---|---|
keda_scaler_active |
Whether scaler is active |
keda_scaler_metrics_value |
Current metric value |
keda_scaled_object_errors |
Scaling errors |
Part of OpenOva