feat: support k8s native ingress and backend service in the different namespace

[shareinto]

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    k8s.apisix.apache.org/svc-namespace: default
  name: details
  namespace: apisix
spec:
  ingressClassName: apisix
  rules:
  - host: bar.com
    http:
      paths:
      - backend:
          service:
            name: details
            port:
              number: 9080
        path: /
        pathType: Prefix

Like the example above, ingress is under the namespace apisix, and service details is under the default namespace.
In actual production, we did encounter such a scenario, which is to use the externalName type of Service that the nginx ingress controller can support. We now want to migrate to apisix and use the old ingress api. There is a problem with the externalName supported by the nginx ingress controller, that is, it will resolve the service of another namespace into clusterIp, which will cause the Layer 7 load balancing strategy to fail. So, it would be the best solution to get the endpoint of another namespace.

[AlinsRan]

I have a few doubts.

1. Why cross ns?
2. Can't the same namespace be used for the ingress resource and service?

It should be noted that if the namespace_selector flag is enabled and the namespace: default is not in the monitoring range, the update of Endpoints API will be lost.

[shareinto]

Yes, I can understand your doubts, our business sometimes requires ingress and service to be in different namespaces, which depends on the choice of our customers. We found some implementations of the same:
(1) https://github.com/nginxinc/kubernetes-ingress/tree/v2.3.0/examples/custom-resources/cross-namespace-configuration
(2) type of externalName service in nginx ingress controller