[DISCUSS] Proposal: support different resolve-granularity of service for Apache Ingress Controller

[xin Ro <al...@gmail.com>]

*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.