Kubernetes API health endpoints [page]deterministic
The Kubernetes [API server](#gloss:kube-apiserver) provides API endpoints to indicate the current status of the API server. This page describes these API endpoints and explains how you can use them.
## API endpoints for health
The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server. The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead. The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration. For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint. Machines that check the `healthz`/`livez`/`readyz` of the API server should rely on the HTTP status code. A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending on the called endpoint.
These endpoints align with how Kubernetes [HTTP probes](/docs/concepts/workloads/pods/probes/#http-probes) function:
* livez: Use this to determine if the API server should be restarted. If `/livez` returns a failure status code (such as 500), the API server is likely in a non-recoverable state, such as a deadlock, and requires a restart. * readyz: Use this to determine if the API server is ready to accept traffic. If `/readyz` returns a failure status code, it indicates the server is still initializing or temporarily unable to serve requests (for example, waiting for etcd to be available), and traffic should be routed away from it.
The more verbose options shown below are intended to be used by human operators to debug their cluster or understand the state of the API server.
The following examples will show how you can interact with the health API endpoints.
For all endpoints, you can use the `verbose` parameter to print out the checks and their status. This can be useful for a human operator to debug the current status of the API server, it is not intended to be consumed by a machine:
```shell curl -k https://localhost:6443/livez?verbose ```
or from a remote host with authentication:
```shell kubectl get --raw='/readyz?verbose' ```
The output will look like this:
[+]ping ok [+]log ok [+]etcd ok [+]poststarthook/start-kube-apiserver-admission-initializer ok [+]poststarthook/generic-apiserver-start-informers ok [+]poststarthook/start-apiextensions-informers ok [+]poststarthook/start-apiextensions-controllers ok [+]poststarthook/crd-informer-synced ok [+]poststarthook/bootstrap-controller ok [+]poststarthook/rbac/bootstrap-roles ok [+]poststarthook/scheduling/bootstrap-system-priority-classes ok [+]poststarthook/start-cluster-authentication-info-controller ok [+]poststarthook/start-kube-aggregator-informers ok [+]poststarthook/apiservice-registration-controller ok [+]poststarthook/apiservice-status-available-controller ok [+]poststarthook/kube-apiserver-autoregistration ok [+]autoregister-completion ok [+]poststarthook/apiservice-openapi-controller ok healthz check passed
The Kubernetes API server also supports to exclude specific checks. The query parameters can also be combined like in this example:
```shell curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' ```
The output show that the `etcd` check is excluded:
[+]ping ok [+]log ok [+]etcd excluded: ok [+]poststarthook/start-kube-apiserver-admission-initializer ok [+]poststarthook/generic-apiserver-start-informers ok [+]poststarthook/start-apiextensions-informers ok [+]poststarthook/start-apiextensions-controllers ok [+]poststarthook/crd-informer-synced ok [+]poststarthook/bootstrap-controller ok [+]poststarthook/rbac/bootstrap-roles ok [+]poststarthook/scheduling/bootstrap-system-priority- …(trimmed)