Improve documentation for container probes
- mention gRPC probes in concept page - revise explanation of gRPC probes in task page - general tidying
This commit is contained in:
+33
-29
@@ -226,51 +226,56 @@ kubectl describe pod goproxy
|
||||
|
||||
If your application implements [gRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/master/doc/health-checking.md),
|
||||
kubelet can be configured to use it for application liveness checks.
|
||||
You must enable the `GRPCContainerProbe`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
in order to configure checks that rely on gRPC.
|
||||
|
||||
Here is an example manifest:
|
||||
|
||||
{{< codenew file="pods/probe/grpc-liveness.yaml">}}
|
||||
|
||||
To use a gRPC probe, `port` must be configured. If the health endpoint is configured
|
||||
on a non-default service, `service` must be configured.
|
||||
on a non-default service, you must also specify the `service`.
|
||||
|
||||
{{< note >}}
|
||||
Unlike HTTP and TCP probes, named ports cannot be used and custom host cannot be configured.
|
||||
{{< /note >}}
|
||||
|
||||
Configuration problems (e.g. incorrect port and service, unimplemented health checking protocol)
|
||||
Configuration problems (for example: incorrect port and service, unimplemented health checking protocol)
|
||||
are considered a probe failure, similar to HTTP and TCP probes.
|
||||
|
||||
To try the gRPC liveness check, create a Pod using the command below.
|
||||
In the example below, the etcd pod is configured to use gRPC liveness probe.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/probe/content/en/examples/pods/probe/grpc-liveness.yaml
|
||||
```
|
||||
|
||||
After 15 seconds, view Pod events to verify that the liveness check has not failed:
|
||||
|
||||
```shell
|
||||
kubectl describe pod etcd-with-grpc
|
||||
```
|
||||
|
||||
Before Kubernetes 1.23, gRPC health probes were often implemented using [grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/),
|
||||
as described in the blog post [Health checking gRPC servers on Kubernetes](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/).
|
||||
The built-in gRPC probes behavior is similar to one implemented by grpc-health-probe.
|
||||
When migrating from grpc-health-probe to built-in probes, remember the following differences:
|
||||
|
||||
- Built-in probes will run against pod IP, unlike grpc-health-probe that often runs against `127.0.0.1`.
|
||||
Be sure to configure your gRPC endpoint to listen for pod IP address.
|
||||
- Built-in probes do not currently support any authentication parameters (like `-tls`).
|
||||
- There are no error codes in built-in probes. All errors are considered as probe failures.
|
||||
- If `ExecProbeTimeout` feature gate is set to `false`, grpc-health-probe will NOT
|
||||
respect `timeoutSeconds` setting (which defaults to 1s),
|
||||
while built-in probe will fail on timeout.
|
||||
|
||||
To try the gRPC liveness check, create a Pod using the command below.
|
||||
In the example below, etcd pod is configured to use gRPC liveness probe.
|
||||
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/probe/content/en/examples/pods/probe/grpc-liveness.yaml
|
||||
```
|
||||
|
||||
After 15 seconds, view Pod events to verify that the liveness probes has not failed:
|
||||
|
||||
```shell
|
||||
kubectl describe pod etcd-with-grpc
|
||||
```
|
||||
- Built-in probes run against the pod IP address, unlike grpc-health-probe that often runs against `127.0.0.1`.
|
||||
Be sure to configure your gRPC endpoint to listen on the Pod's IP address.
|
||||
- Built-in probes do not support any authentication parameters (like `-tls`).
|
||||
- There are no error codes for built-in probes. All errors are considered as probe failures.
|
||||
- If `ExecProbeTimeout` feature gate is set to `false`, grpc-health-probe does **not** respect the `timeoutSeconds` setting (which defaults to 1s),
|
||||
while built-in probe would fail on timeout.
|
||||
|
||||
## Use a named port
|
||||
|
||||
You can use a named
|
||||
[ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core)
|
||||
for HTTP and TCP probes. Note, gRPC probe does not support named port.
|
||||
[`port`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports)
|
||||
for HTTP and TCP probes. (gRPC probes do not support named ports).
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
ports:
|
||||
@@ -533,12 +538,11 @@ It will be rejected by the API server.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about
|
||||
[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
|
||||
|
||||
You can also read the API references for:
|
||||
|
||||
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
|
||||
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
|
||||
* [Pod](/docs/reference/kubernetes-api/workload-resources/pod-v1/), and specifically:
|
||||
* [container(s)](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)
|
||||
* [probe(s)](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Probe)
|
||||
|
||||
Reference in New Issue
Block a user