Gallardot commented on issue #1019:
URL: 
https://github.com/apache/apisix-ingress-controller/issues/1019#issuecomment-1129921588

   > It's my idea that we have two ways:
   > 
   > 1. The service in the service registry has a corresponding Kubernetes 
Service object but without endpoints, and there is an annotation on the 
Kubernetes service with some details about the real service information in the 
registry. This way we don't have to update the ApisixRoute CRD;
   > 2. We modify the ApisixRoute CRD so that we can allow users specify a 
field like `discovery_from`, when this field exists, APISIX Ingress Controller 
doesn't ask users to fill the `service` item. This way makes the ApisixRoute 
CRD more complicated. But the use is easier (without the dependency of 
annotations on Service).
   
   > The first method is too complicated, and currently we need to consider 
other requirements at the same time, such as supporting external name #927 and 
split ApisixUpstream #864
   
   Yes, I agree that the first method is too complicated and less usable. 
   
   If we use the second method, the question becomes where to add fields? I 
suggest the following option
   
   
   > One possible solution is to add `discovery_type` to `http[].backends` and 
`stream[].backend` of 
[`apisix_route_v2Beta3`](https://apisix.apache.org/zh/docs/ingress-controller/references/apisix_route_v2beta3).
 The default value is `kubernetes` and the behavior remains the same as now.
   > 
   > Consul_kv, DNS, NacOS, Eureka are available based on [apisix's service 
integration configuration](https://apisix.apache.org/docs/apisix/discovery). If 
these are optional, these configurations will only be converted to apisix 
upstream configurations and will not be processed by parsing the endpoint 
through the kubernetes service.
   
   If we supporting external name service #927 , we can add a new 
`discovery_type ` named `external_Service`
   
   


-- 
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]

Reply via email to