[AMORO-1957] Support liveness port testing for standby instance

[huyuanfeng2018]

Why are the changes needed?

Close ##1957

Brief change log

• Start a thread to open the port for k8s when the container starts k8s use for livenessprobe

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

• Add screenshots for manual tests if appropriate

In my environment it works fine.

• Run test locally before making a pull request

Documentation

• Does this pull request introduce a new feature? (no)
• If yes, how is the feature documented? (not documented)

[codecov]

Codecov Report

Attention: 19 lines in your changes are missing coverage. Please review.

Files	Coverage Δ
...om/netease/arctic/server/ArcticManagementConf.java	99.51% <100.00%> (+0.01%)	⬆️
.../netease/arctic/server/ArcticServiceContainer.java	68.11% <0.00%> (-5.51%)	⬇️

... and 4 files with indirect coverage changes

📢 Thoughts on this report? Let us know!.

[baiyangtx]

I think using a separate port as a liveness port is not a good solution. If the goal is to solve the Kubernetes pod liveness probe issue, using the "ps" command is also a viable option. This PR proposes reusing the HTTP port and obtaining the instance status through an HTTP API.

[wangtaohz]

I think using a separate port as a liveness port is not a good solution. If the goal is to solve the Kubernetes pod liveness probe issue, using the "ps" command is also a viable option. This PR proposes reusing the HTTP port and obtaining the instance status through an HTTP API.

Do you think using the HTTP API mentioned here #2082 is a resonable solution? @baiyangtx

[huyuanfeng2018]

I think using a separate port as a liveness port is not a good solution. If the goal is to solve the Kubernetes pod liveness probe issue, using the "ps" command is also a viable option. This PR proposes reusing the HTTP port and obtaining the instance status through an HTTP API.

Do you think using the HTTP API mentioned here #2082 is a resonable solution? @baiyangtx

Maybe take a look at this:
https://github.com/NetEase/amoro/blob/27bbc6991ce6d495a16527a083f45d89eb1a0268/ams/server/src/main/java/com/netease/arctic/server/dashboard/controller/HealthCheckController.java#L27

[baiyangtx]

I think using a separate port as a liveness port is not a good solution. If the goal is to solve the Kubernetes pod liveness probe issue, using the "ps" command is also a viable option. This PR proposes reusing the HTTP port and obtaining the instance status through an HTTP API.

Do you think using the HTTP API mentioned here #2082 is a resonable solution? @baiyangtx

Can this interface be accessed on standby nodes? @wangtaohz

[wangtaohz]

Can this interface be accessed on standby nodes? @wangtaohz

I don't think it can, just like any other HTTP API, only the leader AMS provides HTTP service.

[baiyangtx]

Since this PR is not planed to proceed for now, can I close the PR temporarily? @huyuanfeng2018

[huyuanfeng2018]

Since this PR is not planed to proceed for now, can I close the PR temporarily? @huyuanfeng2018

ok