help request: apisix discovery with kubernetes

[wolgod]

Description

I want to use the kubernetes service discovery function of apisix, and now the demo has been run through, there are two questions

1. If I use the kubernetes service discovery function, is there an interface to get the real Upstream information on the backend of the service, or is this information just cached in the apisix instance and cannot be viewed?

2. in the documentation, it is said that the data exists in ngx.shared.kubernetes. If my apisix instance is restarted, how can I ensure that all Upstreams have been re-acquired before processing the request?

Environment

• APISIX version (run apisix version):2.13.2
• Operating system (run uname -a):centos7
• OpenResty / Nginx version (run openresty -V or nginx -V):1.9.19
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[zhixiongdu027]

Hi , @wolgod

If I use the kubernetes service discovery function, is there an interface to get the real Upstream information on the backend of the service, or is this information just cached in the apisix instance and cannot be viewed?

there is no interface for dump now ,welecom PR .

in the documentation, it is said that the data exists in ngx.shared.kubernetes. If my apisix instance is restarted, how can I ensure that all Upstreams have been re-acquired before processing the request?

kubernetes discovery uses List-Watch to get endpoint information .

upstreams information is empty until the first "List" complete .
If there is a querying before completed, it will get an "nil" result

If you cannot accept this, you may need some way to ensure that apisix only accepts client requests after kubernetes discovery
completing first "List".
ApiSix can't do this by its own

[wolgod]

Hi , @wolgod

If I use the kubernetes service discovery function, is there an interface to get the real Upstream information on the backend of the service, or is this information just cached in the apisix instance and cannot be viewed?

there is no interface for dump now ,welecom PR .

in the documentation, it is said that the data exists in ngx.shared.kubernetes. If my apisix instance is restarted, how can I ensure that all Upstreams have been re-acquired before processing the request?

kubernetes discovery uses List-Watch to get endpoint information .

upstreams information is empty until the first "List" complete . If there is a querying before completed, it will get an "nil" result

If you cannot accept this, you may need some way to ensure that apisix only accepts client requests after kubernetes discovery completing first "List". ApiSix can't do this by its own

@zhixiongdu027 thanks for answer, about second problem

1. In my understanding, the list-watch should be in the master worker. If I execute apisix reload, it should not cause the list-watch to be re-listed. I don’t know if it is correct.
2. After the first list in k8s is completed, all endpoints will be obtained. At this time, the service should be able to obtain upstreams, but when will the first list be completed, there will be log printing or is there any other way to obtain it
3. because the list-watch is performed on apisix, whether there are multiple apisix instances in theory, the Upstream of the same service may be differen

[zhixiongdu027]

1. In my understanding, the list-watch should be in the master worker. If I execute apisix reload, it should not cause the list-watch to be re-listed. I don’t know if it is correct.

Yes, it is correct.

2. After the first list in k8s is completed, all endpoints will be obtained. At this time, the service should be able to obtain upstreams, but when will the first list be completed, there will be log printing or is there any other way to obtain it

There is no interface to show get the state of List-Watch

Maybe you can sense this by log "list failed " or log "begin to watch ",
If you are willing to modify the source code, you can:

• define your own post_list callback
• add interface to read the value of informer.fetch_state

3. because the list-watch is performed on apisix, whether there are multiple apisix instances in theory, the Upstream of the same service may be differen

exactly as you said, but I think it's the price of multiple apisix

[wolgod]

Thank you very much, there is another question. Due to historical reasons, I can only use the 2.13 version of apisix. I think 2.15 has fixed a bug. I don’t know how much this bug affects. If I don’t upgrade, will there be a big problem?

[tzssangglass]

here is another question. Due to historical reasons, I can only use the 2.13 version of apisix. I think 2.15 has fixed a bug. I don’t know how much this bug affects. If I don’t upgrade, will there be a big problem?

Please open a new issue to describe the new problem. I will close the current issue first.