|
| 1 | +--- |
| 2 | +title: Kubernetes API 健康端点 |
| 3 | +content_type: concept |
| 4 | +weight: 50 |
| 5 | +--- |
| 6 | +<!-- |
| 7 | +title: Kubernetes API health endpoints |
| 8 | +reviewers: |
| 9 | +- logicalhan |
| 10 | +content_type: concept |
| 11 | +weight: 50 |
| 12 | + --> |
| 13 | + |
| 14 | +<!-- overview --> |
| 15 | +<!-- |
| 16 | +The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server. |
| 17 | +This page describes these API endpoints and explains how you can use them. |
| 18 | +--> |
| 19 | +Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}} 提供 API 端点以指示 API 服务器的当前状态。 |
| 20 | +本文描述了这些 API 端点,并说明如何使用。 |
| 21 | + |
| 22 | +<!-- body --> |
| 23 | + |
| 24 | +<!-- ## API endpoints for health --> |
| 25 | +## API 健康端点 {#api-endpoints-for-health} |
| 26 | + |
| 27 | +<!-- |
| 28 | +The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server. |
| 29 | +The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead. |
| 30 | +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. |
| 31 | +For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint. |
| 32 | +Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code. |
| 33 | +A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint. |
| 34 | +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. |
| 35 | +--> |
| 36 | +Kubernetes API 服务器提供 3 个 API 端点(`healthz`、`livez` 和 `readyz`)来表明 API 服务器的当前状态。 |
| 37 | +`healthz` 端点已被弃用(自 Kubernetes v1.16 起),你应该使用更为明确的 `livez` 和 `readyz` 端点。 |
| 38 | +`livez` 端点可与 `--livez-grace-period` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)一起使用,来指定启动持续时间。 |
| 39 | +为了正常关机,你可以使用 `/readyz` 端点并指定 `--shutdown-delay-duration` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)。 |
| 40 | +检查 API 服务器的 `health`/`livez`/`readyz` 端点的机器应依赖于 HTTP 状态代码。 |
| 41 | +状态码 `200` 表示 API 服务器是 `healthy`、`live` 还是 `ready`,具体取决于所调用的端点。 |
| 42 | +以下更详细的选项供操作人员使用,用来调试其集群或专门调试 API 服务器的状态。 |
| 43 | + |
| 44 | +<!-- The following examples will show how you can interact with the health API endpoints. --> |
| 45 | +以下示例将显示如何与运行状况 API 端点进行交互。 |
| 46 | + |
| 47 | +<!-- |
| 48 | +For all endpoints you can use the `verbose` parameter to print out the checks and their status. |
| 49 | +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: |
| 50 | +--> |
| 51 | +对于所有端点,都可以使用 `verbose` 参数来打印检查项以及检查状态。 |
| 52 | +这对于操作人员调试 API 服务器的当前状态很有用,这些不打算给机器使用: |
| 53 | + |
| 54 | +```shell |
| 55 | +curl -k https://localhost:6443/livez?verbose |
| 56 | +``` |
| 57 | + |
| 58 | +<!-- or from a remote host with authentication: --> |
| 59 | +或从具有身份验证的远程主机: |
| 60 | + |
| 61 | +```shell |
| 62 | +kubectl get --raw='/readyz?verbose' |
| 63 | +``` |
| 64 | + |
| 65 | +<!-- The output will look like this: --> |
| 66 | +输出将如下所示: |
| 67 | + |
| 68 | +```shell |
| 69 | +[+]ping ok |
| 70 | +[+]log ok |
| 71 | +[+]etcd ok |
| 72 | +[+]poststarthook/start-kube-apiserver-admission-initializer ok |
| 73 | +[+]poststarthook/generic-apiserver-start-informers ok |
| 74 | +[+]poststarthook/start-apiextensions-informers ok |
| 75 | +[+]poststarthook/start-apiextensions-controllers ok |
| 76 | +[+]poststarthook/crd-informer-synced ok |
| 77 | +[+]poststarthook/bootstrap-controller ok |
| 78 | +[+]poststarthook/rbac/bootstrap-roles ok |
| 79 | +[+]poststarthook/scheduling/bootstrap-system-priority-classes ok |
| 80 | +[+]poststarthook/start-cluster-authentication-info-controller ok |
| 81 | +[+]poststarthook/start-kube-aggregator-informers ok |
| 82 | +[+]poststarthook/apiservice-registration-controller ok |
| 83 | +[+]poststarthook/apiservice-status-available-controller ok |
| 84 | +[+]poststarthook/kube-apiserver-autoregistration ok |
| 85 | +[+]autoregister-completion ok |
| 86 | +[+]poststarthook/apiservice-openapi-controller ok |
| 87 | +healthz check passed |
| 88 | +``` |
| 89 | + |
| 90 | +<!-- |
| 91 | +The Kubernetes API server also supports to exclude specific checks. |
| 92 | +The query parameters can also be combined like in this example: |
| 93 | +--> |
| 94 | +Kubernetes API 服务器也支持排除特定的检查项。 |
| 95 | +查询参数也可以像以下示例一样进行组合: |
| 96 | + |
| 97 | +```shell |
| 98 | +curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' |
| 99 | +``` |
| 100 | + |
| 101 | +<!-- The output show that the `etcd` check is excluded: --> |
| 102 | +输出显示排除了 `etcd` 检查: |
| 103 | + |
| 104 | +```shell |
| 105 | +[+]ping ok |
| 106 | +[+]log ok |
| 107 | +[+]etcd excluded: ok |
| 108 | +[+]poststarthook/start-kube-apiserver-admission-initializer ok |
| 109 | +[+]poststarthook/generic-apiserver-start-informers ok |
| 110 | +[+]poststarthook/start-apiextensions-informers ok |
| 111 | +[+]poststarthook/start-apiextensions-controllers ok |
| 112 | +[+]poststarthook/crd-informer-synced ok |
| 113 | +[+]poststarthook/bootstrap-controller ok |
| 114 | +[+]poststarthook/rbac/bootstrap-roles ok |
| 115 | +[+]poststarthook/scheduling/bootstrap-system-priority-classes ok |
| 116 | +[+]poststarthook/start-cluster-authentication-info-controller ok |
| 117 | +[+]poststarthook/start-kube-aggregator-informers ok |
| 118 | +[+]poststarthook/apiservice-registration-controller ok |
| 119 | +[+]poststarthook/apiservice-status-available-controller ok |
| 120 | +[+]poststarthook/kube-apiserver-autoregistration ok |
| 121 | +[+]autoregister-completion ok |
| 122 | +[+]poststarthook/apiservice-openapi-controller ok |
| 123 | +[+]shutdown ok |
| 124 | +healthz check passed |
| 125 | +``` |
| 126 | + |
| 127 | +<!-- ## Individual health checks --> |
| 128 | +## 独立健康检查 {#individual-health-check} |
| 129 | + |
| 130 | +{{< feature-state state="alpha" >}} |
| 131 | + |
| 132 | +<!-- |
| 133 | +Each individual health check exposes an http endpoint and could can be checked individually. |
| 134 | +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 the liveness or the readiness of the API server. |
| 135 | +The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. |
| 136 | +These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: |
| 137 | +--> |
| 138 | +每个单独的健康检查都会公开一个 http 端点,并且可以单独检查。 |
| 139 | +单个运行状况检查的模式为 `/livez/<healthcheck-name>`,其中 `livez` 和 `readyz` 表明你要检查的是 API 服务器是否存活或就绪。 |
| 140 | +`<healthcheck-name>` 的路径可以通过上面的 `verbose` 参数发现 ,并采用 `[+]` 和 `ok` 之间的路径。 |
| 141 | +这些单独的健康检查不应由机器使用,但对于操作人员调试系统而言,是有帮助的: |
| 142 | + |
| 143 | +```shell |
| 144 | +curl -k https://localhost:6443/livez/etcd |
| 145 | +``` |
0 commit comments