Traefik Mesh Sidecar Cached Configuration Staleness Detection During Control Plane Outage

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?