You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2022/08/05 09:43:36 UTC
[GitHub] [apisix-ingress-controller] AlinsRan opened a new issue, #1225: [DISCUSS] Proposal: ApisixRoute resolveGranularity field bug for Apache Ingress Controller
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: notifications-unsubscribe@apisix.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-ingress-controller] tao12345666333 commented on issue #1225: Proposal: support different resolve-granularity of service
Posted by GitBox <gi...@apache.org>.
tao12345666333 commented on issue #1225:
URL: https://github.com/apache/apisix-ingress-controller/issues/1225#issuecomment-1242073323
#1251 has been merged. This can be closed.
Thanks
--
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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-ingress-controller] tao12345666333 closed issue #1225: Proposal: support different resolve-granularity of service
Posted by GitBox <gi...@apache.org>.
tao12345666333 closed issue #1225: Proposal: support different resolve-granularity of service
URL: https://github.com/apache/apisix-ingress-controller/issues/1225
--
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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-ingress-controller] tao12345666333 commented on issue #1225: Proposal: support different resolve-granularity of service
Posted by GitBox <gi...@apache.org>.
tao12345666333 commented on issue #1225:
URL: https://github.com/apache/apisix-ingress-controller/issues/1225#issuecomment-1206768662
SGTM
I like the second one "Service and Upstream [1: m]"
--
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: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org