Istio 服务的健康检查
Kubernetes 存活和就绪探针6 描述了几种配置存活和就绪探针的方法:
命令方式无需更改即可工作,但 HTTP 请求、TCP 探针和 gRPC 探针需要 Istio 更改 Pod 的配置。
对 liveness-http
服务的健康检查请求由 kubelet 发送。当启用双向 TLS 时,
这会成为一个问题,因为 kubelet 没有 Istio 颁发的证书。
因此,健康检查请求将失败。
TCP 探针检查需要特殊处理,因为 Istio 将所有传入的流量重定向到 Sidecar, 所以所有 TCP 端口都显示为开放。kubelet 仅检查某个进程是否正在监听指定的端口, 因此只要 Sidecar 正在运行,该探针就总会成功。
Istio 通过重写应用程序 PodSpec
就绪/存活探针来解决这两个问题,
以便将探针请求发送到 Sidecar 代理7。
存活探针重写示例
为了演示存活探针和就绪探针如何在应用程序 PodSpec
级别进行重写,
可以使用 liveness-http-same-port 样例8。
首先为此样例应用创建一个命名空间并打好标签:
然后部署样例应用程序:
部署完成后,您可以检查 Pod 的应用容器,以查看已更改的路径:
原来的 livenessProbe
路径现在被映射到 Sidecar 容器环境变量 ISTIO_KUBE_APP_PROBERS
中的新路径:
对于 HTTP 和 gRPC 请求,Sidecar 代理将请求重定向到应用程序并剥离响应体,仅返回响应代码。 对于 TCP 探针,Sidecar 代理会在避免流量重定向的同时进行端口检查。
在所有内置的 Istio 配置文件9中, 有问题的探针的重写是默认启用的,但可以如下所述禁用。
使用命令方式的存活和就绪探针
Istio 提供了一个存活示例10来实现这种方式。 为了演示该探针在启用双向 TLS 的情况下如何工作,本例先创建一个命名空间:
要配置 STRICT
双向 TLS,请运行:
接下来,运行以下命令来部署示例服务:
要确认存活探针是否正常工作,请检查示例 Pod 的状态以验证它是否正在运行。
使用 HTTP、TCP 和 gRPC 方式的存活和就绪探针
如上所述,Istio 默认使用探针重写来实现 HTTP、TCP 和 gRPC 探针。 您可以为特定 Pod 或全局禁用此特性。
为 Pod 禁用探针重写
您可以使用 sidecar.istio.io/rewriteAppHTTPProbers: "false"
来为 Pod 添加注解11
以禁用探针重写选项。确保将注解添加到
Pod 资源12,
因为在其他任何地方该注解会被忽略(例如,在封闭的 Deployment 资源上)。
这种方式允许您在单个 Deployment 上逐步禁用健康检查探针重写, 而无需重新安装 Istio。
全局禁用探针重写
安装 Istio13 时使用
--set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=false
全局禁用探针重写。或者更新 Istio Sidecar 注入器的配置映射:
清理
移除这些示例所用的命名空间: