Configuration Overview
Use this section when you already know what Bloodraven does and need to choose the right configuration surface.
Pick the right page
| Need | Start here |
|---|---|
| Smallest working manifest | Getting Started |
| Production installation path | Production Install |
| Every CRD field and default | CRD Reference |
| Per-role users and MySQL TLS | Credentials and TLS |
| Node labels, zones, and taints | Placement Contract |
| Application connection behavior | App Integration |
| Security boundaries and network surfaces | Security Model |
| Go-live requirements | Production Hardening |
Configuration model
Bloodraven has three layers:
| Layer | Resource | Owner |
|---|---|---|
| Operator install | Helm release, CRDs, RBAC, metrics Service | Platform team |
| Failover group | MysqlFailoverGroup | Database/platform team |
| Application access | MySQL Services, optional Dragonfly Service, Secrets, DNS name | Application team with platform guardrails |
Recommended production baseline
- Use
spec.credentialsinstead of legacyspec.secretName. - Use distinct Secrets for operator, app, read-only, monitor, and backup users.
- Set
spec.tlsand require client TLS in application connection strings. - Pin operator, sidecar, MySQL, and backup images.
- If you enable
spec.dragonfly, pinspec.dragonfly.imageto Dragonflyv1.38.0+and route applications to the Bloodraven-created active Dragonfly Service. - Configure backups before production traffic starts.
- Enable Prometheus scraping, Grafana dashboards, and alerts.
- Link alerts to Runbooks.
Resource defaults
Bloodraven now sets a default resources.requests on every container it creates,
so the operator's workloads can be scheduled on clusters that enforce a
ResourceQuota or a LimitRange requiring requests. Where the user already
has a CR override field, that field continues to win; only previously-unset
containers picked up a default.
| Workload | Container | Resource source |
|---|---|---|
| MySQL Deployment (per site) | mysql | spec.sites[].resources (user-supplied) |
| MySQL Deployment (per site) | sidecar | spec.sidecarResources (user-supplied) |
| Dragonfly StatefulSet | dragonfly | spec.dragonfly.resources (user-supplied) |
| Backup Job | mysqlsh / mysqlsh-dump / backup-encrypt-upload | spec.backup.resources |
| Cleanup Job | mysqlsh | spec.backup.resources |
| Verification Job | mysqlsh | spec.verification.resources |
| Verification Job init | decrypt-download | spec.backup.resources when set, else 100m CPU / 128Mi memory (requests only) |
| Restore Job (bootstrap + in-place) | mysqlsh | spec.backup.resources when set, else 100m CPU / 128Mi memory (requests only) |
| Restore Job init | pitr-download, decrypt-download | spec.backup.resources when set, else 100m CPU / 128Mi memory (requests only) |
| Operator (Helm) | operator | .Values.resources in charts/bloodraven/values.yaml |
The 100m/128Mi init-container default matches the operator's own request
in the Helm chart. It is intentionally conservative: the AES-GCM decrypt
stream and the PITR archive walker tolerate small requests when the
container can burst on the host. Override by setting spec.backup.resources
on the failover group; the same value flows to the init containers.
The cleanup Job reuses spec.backup.resources because it runs the same
cleanup.py payload sized by the same backup profile parameters. If a
future workload needs a separate budget, we add a dedicated field then.
Security context defaults
Two new opt-in fields let cluster operators apply Kubernetes Restricted PSS to the MySQL Deployments and Dragonfly StatefulSets without forcing a uid/gid migration on existing clusters:
spec.podSecurityContextandspec.containerSecurityContext— applied to the MySQL Deployment pod and to itsmysqlandsidecarcontainers.spec.dragonfly.podSecurityContextandspec.dragonfly.containerSecurityContext— applied to the Dragonfly StatefulSet.
When these fields are nil (the default), Bloodraven leaves the workload's PodSpec untouched; existing CRs render identical pods to before. When they are set, the operator applies the value verbatim — it does not merge with internal hardened defaults. The user owns the uid, gid, fsGroup, seccomp profile, and capability set, because the right values depend on which MySQL and Dragonfly images you run.
See Production Hardening → Opt-in Restricted PSS for MySQL and Dragonfly
for worked examples and the upgrade procedure for existing clusters whose
/var/lib/mysql PVCs were created without an fsGroup.