railiance-cluster/docs/canary-helm-template.md

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:

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:

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.