From ed95607ae614d5e4c402fed609dc596b4f07fab8 Mon Sep 17 00:00:00 2001 From: Jonathan McCall Date: Sun, 12 Jan 2020 11:21:37 -0500 Subject: [PATCH] Be more explicit about what kind of probe (#17943) My guess is that this refers to a TCP probe as opposed to the HTTP probe referred to above. --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 84d2fbc29d..dfa0a1b414 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -356,7 +356,7 @@ and the Pod's `hostNetwork` field is true. Then `host`, under `httpGet`, should to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common case, you should not use `host`, but rather set the `Host` header in `httpHeaders`. -For a probe, the kubelet makes the probe connection at the node, not in the pod, which +For a TCP probe, the kubelet makes the probe connection at the node, not in the pod, which means that you can not use a service name in the `host` parameter since the kubelet is unable to resolve it.