目前,我的应用程序面临一个问题:由于kubelet无法成功地进行健康检查,它变得不健康。
从豆荚中描述:
Warning Unhealthy 84s kubelet Startup probe failed: Get "http://10.128.0.208:7777/healthz/start": dial tcp 10.128.0.208:7777: connect: connection refused
Warning Unhealthy 68s (x3 over 78s) kubelet Liveness probe failed: HTTP probe failed with statuscode: 500现在,我发现这很奇怪,因为我可以从运行kubelet的工作节点运行健康检查吗?因此,我想知道通过curl从worker节点运行健康检查与kubelet运行健康检查有什么区别。
示例:
From worker node where the kubelet is running:
sh-4.4# curl -v http://10.128.0.208:7777/healthz/readiness
* Trying 10.128.0.208...
* TCP_NODELAY set
* Connected to 10.128.0.208 (10.128.0.208) port 7777 (#0)
> GET /healthz/readiness HTTP/1.1
> Host: 10.128.0.208:7777
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 0
< Connection: close
<
* Closing connection 0
sh-4.4#我能追踪到库贝利特什么时候发送健康探测器检查吗?或者到库贝利特去亲自送去?
还有一件事要告诉我们:我的吊舱里面有一个istio代理容器。看起来这个istio代理阻塞了kubelet的流量。
在部署中设置以下注释:
"rewriteAppHTTPProbe": true对库贝拉帮不了什么忙。当从worker节点运行curl命令时,它确实有助于获得200 OK。
也许还需要注意:我们正在使用istio插件来摄取istio侧面。不确定这在注射使用istio时使用前一种方法是否有区别.
欢迎任何建议:)。谢谢。
发布于 2022-03-15 10:35:01
问题似乎是istio插件改变了iptables,并且对应用程序进行了健康探测检查的重定向。然而,重定向发生在本地主机上:并且应用程序没有在那里侦听健康探测.只在:..。
在将iptable改为更合适的重定向后,健康探头可以得到200 OK的响应,并且吊舱也变得健康。
https://stackoverflow.com/questions/71465205
复制相似问题