Update haproxy and keepalived config

[nijave]

Closes #3052

[k8s-ci-robot]

Welcome @nijave!

It looks like this is your first PR to kubernetes/kubeadm 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubeadm has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @nijave. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[neolit123]

thanks
/approve
/kind documentation

/cc @mbert

[k8s-ci-robot]

@neolit123: GitHub didn't allow me to request PR reviews from the following users: mbert.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

thanks
/approve
/kind documentation

/cc @mbert

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mbert]

Looks good to me. As the timeout values are concerned, the reason for increasing them was given in the original ticket, however I'd still be interested to understand why they need to be that high.

[nijave]

Looks good to me. As the timeout values are concerned, the reason for increasing them was given in the original ticket, however I'd still be interested to understand why they need to be that high.

I'm not sure they necessarily need to be that high--I'm not sure if Kubernetes does any sort of keepalives but they would ideally be set around what k8s has

Edit looks like 1800s is what kube-apiserver is using for watches

--min-request-timeout int Default: 1800
An optional field indicating the minimum number of seconds a handler must keep a request open before timing it out. Currently only honored by the watch request handler, which picks a randomized value above this number as the connection timeout, to spread out load.

https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/

There's also

--request-timeout duration Default: 1m0s
An optional field indicating the duration a handler must keep a request open before timing it out. This is the default request timeout for requests but may be overridden by flags such as --min-request-timeout for specific types of requests.

Edit 2:
With kubectl -w I do see some TCP traffic every 30 seconds so maybe there's some heartbeat/keepalive somewhere

[nijave]

I found kubernetes/kubernetes#95981 which would explain the 30s interval I'm seeing. I also asked in Kubernetes Slack https://kubernetes.slack.com/archives/C09NXKJKA/p1714925405232349

With that info, maybe 35s is more reasonable?

[mbert]

I found kubernetes/kubernetes#95981 which would explain the 30s interval I'm seeing. I also asked in Kubernetes Slack https://kubernetes.slack.com/archives/C09NXKJKA/p1714925405232349

With that info, maybe 35s is more reasonable?

Yes, definitely.

[neolit123]

please squash the commits to one, then this can merge.

[neolit123]

/lgtm
thanks for the changes!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: neolit123, nijave

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [neolit123]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[neolit123]

also thanks for the discussion about this @mbert @nijave

[neolit123]

/ok-to-test