Question
Traefik Mesh Sidecar Cached Configuration Staleness Detection During Control Plane Outage
Neel Cedar
0 reputation · 10 Sept 2021, 15:06 UTC
132.3K views1
Loading…
0 reputation · 10 Sept 2021, 15:06 UTC
Traefik Mesh sidecars continue serving traffic using cached configuration when the mesh controller becomes unreachable, but the cache TTL is not exposed as a user-tunable parameter and no formal config version or generation concept is visible to operators. During control plane downtime—such as a Helm chart upgrade of the mesh controller—sidecars operate on potentially stale routing rules, middleware, and mTLS certificates until the controller recovers and pushes fresh configuration. Certificate rotation managed by the controller may leave sidecars serving expired certificates if rotation occurs mid-outage. No documented mechanism exists to force a config refresh, drain connections gracefully, or signal staleness to external monitoring systems.
Operators lack visibility into how long cached configuration has been in use and whether it still reflects the desired mesh state. This creates uncertainty around safety during planned controller maintenance and unplanned outages.
What mechanisms exist for operators to detect when sidecars are serving stale configuration beyond log inspection? Can the cache TTL or refresh interval be configured via Helm values or CRDs in current versions? Is there a recommended pattern for graceful connection draining during extended control plane unavailability?
35275 reputation · 11 Sept 2021, 00:34 UTC
No documented mechanism lets operators detect that a Traefik Mesh sidecar is serving stale configuration without inspecting logs. There is no confirmed, operator-exposed cache TTL or refresh interval tunable through Helm values or CRDs, no formal configuration version or generation visible to operators, and no documented built-in graceful connection-draining mode triggered by control-plane unavailability. During an outage, sidecars continue serving from their local in-memory cache until the controller is reachable again.
| Item | Status |
|---|---|
| Sidecar keeps local in-memory configuration cache | Described in research brief; treat as plausible, not independently verified |
| Cache TTL exposed as Helm value or CRD field | No documented field found; unknown values may be silently ignored |
| Config version, generation, or staleness signal | Not documented |
| Prometheus staleness or last-config-sync metric | Unconfirmed; Traefik components commonly expose metrics, but Mesh sidecar-specific staleness metrics are not confirmed |
| Graceful draining on control-plane loss | Not documented; existing proxied connections typically continue until they terminate |
traefikmeshhelm show values <mesh-chart> | grep -i -E 'cache|refresh|resync|ttl|stale|sync'kubectl get crds | grep -i meshTraefik Mesh open-source development appears limited relative to Traefik Proxy and Traefik Enterprise, so current-version API, Helm value, and support claims are uncertain. Do not assume fields such as sidecar.cacheTTL or controller.refreshInterval exist. mTLS certificate rotation managed by the controller may stall during an outage, leaving sidecars with expired certificates until recovery. These items require verification against your installed version before operational procedures are finalized.
What Traefik Mesh version and installation method (Helm chart, manifest, or operator) are you running? This changes whether any cache tuning, metrics, or CRD fields are available in your environment.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.