Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add some explanation of the difference between the livez and readyz endpoints of the kubernetes API #49283

Open
Ji-Elle opened this issue Jan 4, 2025 · 1 comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@Ji-Elle
Copy link

Ji-Elle commented Jan 4, 2025

What would you like to be added
The current documentation page regarding the Kubernetes API health endpoint is not clear about where the /readyz and /livez differ and in which situations one or the other should be called. It was already a point raised before and the conversation around the commit adding the current version of the documentation indicate that those endpoints may not be relied upon: if it is the case it could be a good thing to add a note in the documentation.

Why is this needed
When setting up a kubernetes cluster on premise you want to have multiple nodes hosting the control plane to help with high availability. Then when setting up some load balancers on front having them able to check which nodes are down so people would expect some easy healthcheck.

Comments
More generally the documentation is not clear (or lack locality of information) regarding what happens when you scale the api server: if I have 3 nodes hosting the API, is the information those health endpoints return only for the node receiving the call or for every node? What happens when 1 of those 3 nodes is down?

@Ji-Elle Ji-Elle added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 4, 2025
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jan 4, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants