AlinsRan opened a new issue, #1225:
URL: 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
Solution
Services 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.
--
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]
