56 lines
1.7 KiB
Markdown
56 lines
1.7 KiB
Markdown
# Canary Helm Template
|
|
|
|
Generated Railiance overlays include a stage-aware Helm chart for Stage 2
|
|
canaries and Stage 3 stable promotion.
|
|
|
|
The chart keeps stable and canary release identities explicit:
|
|
|
|
- `railiance.stableRelease` names the current stable release;
|
|
- `railiance.canaryRelease` names the Stage 2 candidate release;
|
|
- `railiance.stage` selects the rendered identity, labels, and selectors;
|
|
- `railiance.previousStable` records rollback context before promotion.
|
|
|
|
## Traffic Shape
|
|
|
|
The default Stage 2 values use an isolated canary ingress:
|
|
|
|
```yaml
|
|
railiance:
|
|
stage: canary
|
|
traffic:
|
|
mode: isolated
|
|
|
|
ingress:
|
|
enabled: true
|
|
```
|
|
|
|
This creates canary Deployment, Service, and Ingress resources without changing
|
|
the stable release. For environments that use Traefik weighted routing, set:
|
|
|
|
```yaml
|
|
railiance:
|
|
traffic:
|
|
mode: weighted
|
|
provider: traefik
|
|
stableWeight: 95
|
|
canaryWeight: 5
|
|
```
|
|
|
|
The chart then renders a `TraefikService` and `IngressRoute` that split traffic
|
|
between the stable and canary services. Other ingress controllers can use the
|
|
same stable/canary values layout with controller-specific annotations or a later
|
|
provider template.
|
|
|
|
## Observability And Safety
|
|
|
|
Generated workloads include:
|
|
|
|
- Prometheus-compatible scrape annotations on pods and services;
|
|
- readiness and liveness HTTP probes;
|
|
- conservative resource requests/limits for single-node clusters;
|
|
- separate `values/stage2-canary.yaml` and `values/stage3-production.yaml` so
|
|
canary exposure and stable promotion can be reviewed independently.
|
|
|
|
Run `tests/stage2-template.sh` in the overlay repo before any Stage 2 attempt.
|
|
It verifies the scaffold and runs `helm template` when Helm is available.
|