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

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 change: added doc of how to load plugin. #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