feat: In version 3.9.1 apisix, multiple ingress controllers are deployed in the same K8S cluster, corresponding to the same set of etcds, and consul is used for service discovery, and some apisix pods are forwarded after rolling updates, and the upstream node is considered unavailable and thus 503

[lvdb-wuzihong]

Description

Description

As shown in the image, the route is configured via CRD
This is one of the routing configurations right now：
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: demo
namespace: demo
spec:
http:

• backends:
  • resolveGranularity: service
    serviceName: demo
    servicePort: 80
  • match:
    hosts:
    - api.demo.com
    paths:
    - /*
    name: rule1
    plugin_config_name: demo

If I don't add resolveGranularity: service, it will be forwarded after a while and there will be problems

The consul service found the configuration with the problem:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: demo
namespace: demo
spec:
http:

• match:
  hosts:
  - demo.com
  paths:
  - /*
  name: rule1
  plugin_config_name: demo
  upstreams:
  - name: demo
  apiVersion: apisix.apache.org/v2
  kind: ApisixUpstream
  metadata:
  name: demo
  namespace: demo
  spec:
  discovery:
  serviceName: demo
  type: consul
  retries: 5

Is it a problem with the deployment architecture or something, because we didn't find a problem with consul, if there is a problem, there should be a problem with these multiple sets of apisix pods

Environment
APISIX version 3.9.1
Operating system Linux apisix-57b7d7d8fb-7lz26 5.10.134-17.2.al8.x86_64 apache/apisix#1 SMP Fri Aug 9 15:49:42 CST 2024 x86_64 GNU/Linux
OpenResty / Nginx version openresty/1.25.3.1
etcd version, etcdctl version: 3.5.15