Skip to content

Commit 5c27482

Browse files
authored
Merge pull request #21185 from johscheuer/add-docs-api-health-checks
Add documentation for API server health checks
2 parents 81e9489 + f1588c0 commit 5c27482

File tree

1 file changed

+103
-0
lines changed

1 file changed

+103
-0
lines changed
Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
---
2+
title: Kubernetes API health endpoints
3+
reviewers:
4+
- logicalhan
5+
content_type: concept
6+
weight: 50
7+
---
8+
9+
<!-- overview -->
10+
The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server.
11+
This page describes these API endpoints and explains how you can use them.
12+
13+
<!-- body -->
14+
15+
## API endpoints for health
16+
17+
The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server.
18+
The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead.
19+
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.
20+
For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
21+
Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
22+
A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
23+
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.
24+
25+
The following examples will show how you can interact with the health API endpoints.
26+
27+
For all endpoints you can use the `verbose` parameter to print out the checks and their status.
28+
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:
29+
30+
```shell
31+
curl -k https://localhost:6443/livez?verbose
32+
```
33+
34+
or from a remote host with authentication:
35+
36+
```shell
37+
kubectl get --raw='/readyz?verbose'
38+
```
39+
40+
The output will look like this:
41+
42+
[+]ping ok
43+
[+]log ok
44+
[+]etcd ok
45+
[+]poststarthook/start-kube-apiserver-admission-initializer ok
46+
[+]poststarthook/generic-apiserver-start-informers ok
47+
[+]poststarthook/start-apiextensions-informers ok
48+
[+]poststarthook/start-apiextensions-controllers ok
49+
[+]poststarthook/crd-informer-synced ok
50+
[+]poststarthook/bootstrap-controller ok
51+
[+]poststarthook/rbac/bootstrap-roles ok
52+
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
53+
[+]poststarthook/start-cluster-authentication-info-controller ok
54+
[+]poststarthook/start-kube-aggregator-informers ok
55+
[+]poststarthook/apiservice-registration-controller ok
56+
[+]poststarthook/apiservice-status-available-controller ok
57+
[+]poststarthook/kube-apiserver-autoregistration ok
58+
[+]autoregister-completion ok
59+
[+]poststarthook/apiservice-openapi-controller ok
60+
healthz check passed
61+
62+
The Kubernetes API server also supports to exclude specific checks.
63+
The query parameters can also be combined like in this example:
64+
65+
```shell
66+
curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
67+
```
68+
69+
The output show that the `etcd` check is excluded:
70+
71+
[+]ping ok
72+
[+]log ok
73+
[+]etcd excluded: ok
74+
[+]poststarthook/start-kube-apiserver-admission-initializer ok
75+
[+]poststarthook/generic-apiserver-start-informers ok
76+
[+]poststarthook/start-apiextensions-informers ok
77+
[+]poststarthook/start-apiextensions-controllers ok
78+
[+]poststarthook/crd-informer-synced ok
79+
[+]poststarthook/bootstrap-controller ok
80+
[+]poststarthook/rbac/bootstrap-roles ok
81+
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
82+
[+]poststarthook/start-cluster-authentication-info-controller ok
83+
[+]poststarthook/start-kube-aggregator-informers ok
84+
[+]poststarthook/apiservice-registration-controller ok
85+
[+]poststarthook/apiservice-status-available-controller ok
86+
[+]poststarthook/kube-apiserver-autoregistration ok
87+
[+]autoregister-completion ok
88+
[+]poststarthook/apiservice-openapi-controller ok
89+
[+]shutdown ok
90+
healthz check passed
91+
92+
## Individual health checks
93+
94+
{{< feature-state state="alpha" >}}
95+
96+
Each individual health check exposes an http endpoint and could can be checked individually.
97+
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.
98+
The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
99+
These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
100+
101+
```shell
102+
curl -k https://localhost:6443/livez/etcd
103+
```

0 commit comments

Comments
 (0)