*Github issue: **https://github.com/apache/apisix-ingress-controller/issues/1225
<https://github.com/apache/apisix-ingress-controller/issues/1225>*
Backend
Currently, the ApisixRoute resources support service and endpoints
service-level resolve granularity. In the project, our implementation: The
service corresponds to an upstream, and an upstream has only one
resolve-granularity.
This implementation has the following problems:
- When a service is referenced by more than one ApisixRoute, they each
use different resolve-granularities, and only the last updated ApisixRoute
configuration takes effect.
- And when the pod changes, the endpoint controller will update
upstream, and the function of resolve-granularity will be destroyed.
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin-route
spec:
http:
- name: httpbin
match:
hosts:
- local.httpbin.org
paths:
- /*
backends:
- serviceName: httpbin
servicePort: 80
resolveGranularity: service
SolutionServices and Upstream [1:1]
In the current design, upstream only supports one resolve-granularity. When
the referenced service has multiple resolve-granularity, it cannot be
perceived resolve-granularity by the endpoint controller to make correct
processing. The resolveGranularity fields should not be supported in
apisixroute, which is incorrect.
If a service corresponds to an Upstream [1:1], the configuration of
ResolveGranularity resolution granularity should be handed over to
ApisixUpstream, and ApisixUpstream will configure the resolution
granularity of the service. When resources such as ApisixRoute reference
services, the resolve-granularity configured by ApisixUpstream will be used.
- It is not possible to support multiple resolve-granularities at the
same time.
- This method does not require changing the way UpstreamName is
generated.
- The endpoint Controller can sense the resolve-granularity of the
service by getting ApisixUpstream.
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin
spec:
resolveGranularity: service #endpoint
Services and Upstream [1: m]
ApisixUpstream corresponds to one service. A service corresponds to
multiple upstream, and each upstream represents a resolve-granularity of a
service. The ApisixRoute rule can only refer to one resolve-granularity of
a service. The resolveGranuarity field is still in ApisixRoute.
- This approach can support multiple resolve-granularities at the same
time
- ApisixUpstream needs to be compatible, configure multiple upstream
- The endpoint controller does not need to be changed, it only needs to
update the Upstream whose resolution granularity is at the Endpoint level
- Requires svc Controller support or UpstreamServiceRelation for
compatibility.
- Need to change how UpstreamName is generated.
Change the way UpstreamName is generated
- (Service and Upstream [1: m]) by adding the existing UpstreamName
suffix (resolution granularity suffix)
- Compatible with upgrades from previous versions.
- Multiple upstream objects exist when there are multiple
resolve-granularities.
- No suffix, default endpoint, endpoint level does not build suffixes.
Conclusion
The first one has some drawbacks. The parsing granularity of services
cannot exist at the same time. The resolveGranularity field of ApisixRoute
will be deprecated, so it may have some impact.
We prefer to choose the second scheme, because the second scheme can be
fully compatible. We only need to configure ApisixRoute to support this
function. Welcome to discuss together.
