I don't think there is definitive guides on this, but I've always felt that liveness and readiness endpoints -- in the context of kubernetes -- should be exposed under /.well-known/. I looked for similar questions and found:
Wikipedia says
A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with
/.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.
And then goes on to list a bunch of well-known endpoints for various services. I don't think the list is prescriptive, we could serve /.well-known/live and /.well-known/ready for the microservices we're building at my company, but my question is really, would we be breaking any rules about well-known URIs by doing this, or should we just stick to /livez and /readyz?
RFC 8615 §3 says
Applications that wish to mint new well-known URIs MUST register them, following the procedures in Section 5.1....
The registry (pointed to by §3.1) doesn't obviously list anything health-check oriented. The text above suggests to me that you're really not supposed to put anything under /.well-known that's not in the registry.
That having been said, the various well-known paths are just machine-readable content being published at canonical per-host URL paths; there's nothing technically special about /.well-known URLs beyond the RFC conventions. Particularly if your individual services will never be directly exposed to the public Internet, nothing is stopping you from using those URL paths if you really want to.