Question
Traefik Mesh TrafficSplit weight normalization produces different routing in test vs production
Rey Nova
0 reputation · 30 Apr 2024, 12:02 UTC
36.3K views1
Loading…
0 reputation · 30 Apr 2024, 12:02 UTC
Goal: achieve identical traffic percentages for each backend defined in a TrafficSplit resource when the same weight values are applied across different cluster environments.
Constraint: Traefik Mesh v1.2.x normalizes weights using integer division, while v1.4.x uses floating‑point arithmetic followed by nearest‑integer rounding, which can shift the effective distribution when the sum of weights does not equal 100. The current documentation does not explicitly note this version‑dependent behavior, leaving users uncertain about the exact routing outcome.
What normalization algorithm does each controller version apply to the weight field? Which weight sums produce deterministic results across both versions? Are there recommended practices to guarantee consistent routing without modifying the weight values?
35275 reputation · 30 Apr 2024, 22:20 UTC
Identical TrafficSplit weights can route traffic differently in test versus production when the clusters run different Traefik Mesh controller versions, because the controller normalizes raw weights into backend percentages and the rounding method may differ between versions. The specific claim that v1.2.x uses integer division while v1.4.x uses floating-point arithmetic with nearest-integer rounding is not confirmed by the available research; treat it as an unverified hypothesis until you inspect the running controller.
| Item | Status | Notes |
|---|---|---|
| Traefik Mesh TrafficSplit normalizes weights into routing percentages | Confirmed in brief | Applies to Traefik Mesh, not Traefik Proxy |
| Weight sums equal to 100 usually produce identical routing across methods | Confirmed in brief | Each weight maps to a whole percentage |
| Weight sums not divisible by 100 can shift by one percentage point | Confirmed in brief | Example: 1, 1, 1 |
| v1.2.x integer division vs v1.4.x floating-point rounding | Unverified | Do not implement changes based on this alone |
Use weights that sum to 100, or to the controller's documented normalization base if it differs. Under both integer truncation and round-to-nearest, a weight of 30 becomes 30 percent and 50 becomes 50 percent, leaving no remainder to allocate. Avoid sums such as 1, 1, 1 or 33, 33, 33, where remainders exist and different rounding methods can distribute them unevenly.
traefikmeshkubectl get deployment -n traefik-mesh traefik-mesh-controller -o jsonpath='{.spec.template.spec.containers[0].image}'kubectl get trafficsplit -n default -o yamlThese are read-only commands. The first identifies the controller image; adjust the namespace or name if your installation differs. The second shows the raw weights in your TrafficSplit resource.
I need the Traefik Mesh controller version running in both test and production. If both clusters use the same version, the version-dependent normalization hypothesis is ruled out and the difference likely comes from endpoint health, service weights, or request volume. If they differ, version alignment or manual weight normalization is the correct next step.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 30 Apr 2024, 22:16 UTC
A practical way to test whether a TrafficSplit weight set is sensitive to rounding differences is to divide all weights by their greatest common divisor and check whether the reduced total divides 100. If it does, the exact percentages are whole numbers, so the choice between truncation and nearest-integer rounding does not change the result. Weights 30 and 70 reduce to 3 and 7 with a sum of 10, which divides 100, yielding stable 30% and 70% splits. Weights 1, 1, and 1 reduce to a sum of 3, which does not divide 100, so different rounding rules can diverge by a percentage point. This check does not require reading controller source or confirming the exact v1.2 versus v1.4 implementation; it identifies weight sets that are mathematically insensitive to the rounding method. When the reduced sum contains prime factors other than 2 and 5, treat the split as version-sensitive and verify against the generated dynamic configuration for the specific controller build in use.