suninuni commented on issue #632: URL: https://github.com/apache/apisix-ingress-controller/issues/632#issuecomment-901014313
> Or you can add readiness configurations @tao12345666333 If you mean the readiness of the pod, yes I have. AND @tokers @Donghui0 thanks for your replies. From the screenshot of Apisix's access log, I think the retry mechanism is worked. You can find some of requests are return 200 after retried 1 times (because I only set 2 replicas for the test service).  So, I known if I have enough pods in the upstream, there will no failed requests after retried many times. And for the active and passive health check, they will reduce the failed number but not make it disappear. > We'll also try to optimize the process from the internal of apisix and apisix-ingress-controller. Yes, this is what I want. For ingress-nginx-controller, it watch the changes of upstream nodes and updated them in memory. But for apisix-ingress-controller and apisix, the update process will be (in my opinion, if there is any error, please help me to point it out): apisix-ingress-controller watch the changes -> call Apisix api to update -> Apisix save to Etcd -> Other Apisix get new upstrems from Etcd. Compared to ingress-nginx-controller, this process is indeed a lot longer. -- 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]
