feat(traefik): tenants-default-retry Middleware (3 attempts, 200ms init)
This commit is contained in:
30
templates/tenants-default-middlewares.yaml
Normal file
30
templates/tenants-default-middlewares.yaml
Normal file
@@ -0,0 +1,30 @@
|
||||
# Default Traefik Middlewares applied to every tenant IngressRoute.
|
||||
# Living at the cluster level (not in instance-template-v3) so the
|
||||
# policy is a one-place edit — every instance picks them up by name
|
||||
# from its own `tenants` namespace, no cross-namespace reference
|
||||
# trickery and no per-chart redeclare.
|
||||
#
|
||||
# tenants-default-retry — small retry budget so a transient 1-2s
|
||||
# Pod-not-ready window during an Odoo restart (addon install, Helm
|
||||
# rollout, etc.) doesn't surface as Traefik's "404 page not found"
|
||||
# to the customer. Traefik's retry only covers TCP-level failures
|
||||
# (connection refused / no available servers), not HTTP 5xx — so it
|
||||
# never re-sends a POST to a server that already accepted it.
|
||||
#
|
||||
# Tuning: 3 attempts with 200 ms initialInterval (doubled each
|
||||
# retry) → worst-case ~600 ms of latency before giving up. Within
|
||||
# typical browser patience and well below the 30 s+ window that a
|
||||
# slow Pod restart needs (we don't try to mask those — the user
|
||||
# eventually sees a clean 503 instead of a confusing 404).
|
||||
---
|
||||
apiVersion: traefik.io/v1alpha1
|
||||
kind: Middleware
|
||||
metadata:
|
||||
name: tenants-default-retry
|
||||
namespace: tenants
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: cluster-platform-v3
|
||||
spec:
|
||||
retry:
|
||||
attempts: 3
|
||||
initialInterval: 200ms
|
||||
Reference in New Issue
Block a user