You are viewing documentation for Kubernetes version: v1.18
Kubernetes v1.18 documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
Kubernetes API health endpoints
The Kubernetes API serverControl plane component that serves the Kubernetes API. 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 to specify the startup duration.
For a graceful shutdown you can specify the --shutdown-delay-duration
flag with the /readyz
endpoint.
Machines that check the health
/livez
/readyz
of the API server should rely on the HTTP status code.
A status code 200
indicates the the API server is healthy
/live
/ready
, depending of the called endpoint.
The more verbose options shown below are intended to be used by human operators to debug their cluster or specially 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-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
[+]shutdown ok
healthz check passed
Individual health checks
Kubernetes v1.18 [alpha]
Each individual health check exposes an http endpoint and could can be checked individually.
The schema for the individual health checks is /livez/<healthcheck-name>
where livez
and readyz
and be used to indicate if you want to check thee liveness or the readiness of the API server.
The <healthcheck-name>
path can be discovered using the verbose
flag from above and take the path between [+]
and ok
.
These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
```shell
curl -k https://localhost:6443/livez/etcd
```