AlinsRan commented on issue #2749:
URL:
https://github.com/apache/apisix-ingress-controller/issues/2749#issuecomment-4539331749
Thanks for the additional detail. I think the root cause here may be broader
than only "don't mix Admin API writes".
A more general explanation is: **multiple independent writers may be pushing
config to the same standalone APISIX target, but they do not share the same
version/cache state**. Once that happens, one writer can advance
`*_conf_version`, and another writer's next sync may be rejected as "too old".
From the controller side, there are at least two ways this can happen:
1. **Conflicting `GatewayProxy` objects targeting the same APISIX control
plane**
Each `GatewayProxy` is translated into an independent ADC config, and its
ADC `CacheKey` is derived from the `GatewayProxy` identity itself. The client
also syncs configs one-by-one. So if two different `GatewayProxy` objects point
to the same APISIX Service/endpoints and use the same AdminKey, they
effectively become two logical writers to the same standalone cluster.
The repo already has webhook-side conflict detection for exactly this
shape of problem: same Service + shared AdminKey secret, or overlapping
endpoints + shared inline AdminKey.
2. **Multiple ingress-controller deployments managing the same resources**
Reconciliation is selected by `controller_name` (default:
`apisix.apache.org/apisix-ingress-controller`), while leader election is scoped
to the controller Pod namespace. So if there are multiple controller
deployments in different namespaces, but they use the same `controller_name`,
they can both be active against the same `GatewayClass` / `IngressClass`. Each
controller keeps its own ADC cache and sync loop, which again becomes "multiple
writers" and can look like periodic overwrite/drift.
So before treating this as purely an APISIX standalone multi-replica bug, I
think it would be worth ruling out these conditions first:
- only **one** `GatewayProxy` is targeting this standalone APISIX cluster,
or at least no two `GatewayProxy` objects share the same Service/endpoints +
AdminKey;
- only **one active ingress-controller writer** is managing the affected
resources, or different controller deployments use different `controller_name`
values;
- no direct Admin API writes are mixed in.
If all of the above are already ruled out, and the issue still reproduces
with a single `GatewayProxy`, a single controller, and no Admin API access,
then I agree it likely deserves to be tracked separately as a standalone
multi-replica / ADC coordination bug.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
