Traefik Mesh controller ↔ Traefik Proxy: config parse safety after controller downgrade

Short answer

No, a downgrade is not automatically safe, and no, you cannot rely on the proxy ignoring unknown fields. Kubernetes performs no automatic schema conversion on downgrade unless a conversion webhook exists — and Traefik Mesh does not ship one for its CRDs (TrafficSplit, TrafficTarget, HTTPRouteGroup, TCPRoute). Without a webhook, the API server does only a trivial apiVersion rename, so fields that exist only in the new schema are silently dropped when the old controller reads the object. The safe path is to convert or recreate affected CRs in the old schema before rolling back the controller.

Where the failure actually happens

One clarification to the premise: Traefik Proxy (the data plane) does not parse the raw CRDs. It consumes dynamic configuration derived and pushed by the Mesh controller. The parse-failure risk lives in the controller's informers and listers decoding persisted CRs into typed structs compiled against the old schema. That distinction matters operationally: if the old controller cannot decode a stored object, it may push an empty or partial configuration to the proxies — which can drop routes cluster-wide rather than merely log an error. So the blast radius is larger than "one unparseable CR."

Why "ignore unknown fields" is not enough

Unknown-field tolerance only covers the easy case — additive changes. It fails when:

• The new schema renamed a field or changed its type (old struct decode fails outright).
• The new schema made a previously optional field required, or vice versa.
• The CRD's storage version was bumped to the new schema; objects stored in that version may not round-trip cleanly into the old controller's types.

Note also that preserveUnknownFields was removed in Kubernetes 1.22+, so pruning behavior is governed by the structural schema — fields not in the served old schema are dropped on write, which is silent data loss, not a parse error you can catch.

Version-skew guarantees

There is no provider-mechanism skew tolerance to lean on here. Traefik Mesh has been deprecated by its maintainers and reached end-of-life, so no upstream rollback tooling or compatibility matrix should be expected. Any skew policy must be enforced by your own deployment pipeline.

Safe rollback procedure

1. Check what the API server actually stores:

   kubectl get crd trafficsplits.split.smi-spec.io \
     -o jsonpath='{.status.storedVersions}'

   If the new version appears, plan a storage migration before rollback.
2. Confirm no conversion webhook is configured (expected for Mesh):

   kubectl get crd trafficsplits.split.smi-spec.io \
     -o jsonpath='{.spec.conversion}'

3. Round-trip test each affected CR: fetch it as the old API version and verify every required field survives. Missing fields mean downgrade-time data loss.
4. Rewrite or recreate incompatible CRs in the old schema, reapply the CRD manifests that shipped with the target (old) controller release, then roll back the controller.
5. Stage the rollback in a test cluster first and watch controller logs for cannot unmarshal or unknown field decode errors from informers.

Caveats

Exact CRD versioning varies by Mesh release — verify against the manifests shipped with the specific versions involved rather than assuming multi-version serving. Given the project's EOL status, treat this as a migration argument as much as a rollback question.