我得到了以下Pod，它始终无法通过“对等端重置连接”的活动探测，并被标记为不健康，但没有重新启动
146 Unhealthy: (combined from similar events): Liveness probe failed: Get "http://[ip address]:8080/q/health/live": read tcp [local node ip address]:54580->[ip address]:8080: read: connection reset by peer只有当返回http状态503时，集群才重新启动pod。这是否是kubernetes liveness probes的预期行为，以及调整它以重新启动不接受连接的pod的方法？
需要注意的一点是，活动配置被设置为高间隔，每30秒只检查一次。此后，这一频率更高。在pod未重启的5小时时间范围内，未收到成功的穿刺针。
livenessProbe:
failureThreshold: 5
httpGet:
path: /q/health/live
port: http
scheme: HTTP
periodSeconds: 30
successThreshold: 1
timeoutSeconds: 30
initialDelaySeconds: 30
readinessProbe:
failureThreshold: 5
httpGet:
path: /q/health/ready
port: http
scheme: HTTP
periodSeconds: 30
successThreshold: 1
timeoutSeconds: 30
initialDelaySeconds: 15Pod是部署的一部分，而不是复制集，并且不存在poddisruptionbudget
expected：Pod在通过liveness配置标记为不健康后重新启动。发生了什么事：失败的吊舱被保留了5个小时。
1条答案
按热度按时间yxyvkwin1#
如果与网络中对等方的TCP连接被对等方关闭，或者意外关闭，则会发生错误。
要解决此问题，请执行以下操作：
如果您尝试使用CPU限制执行后台工作，请尝试使用“CPU始终分配”CPU分配设置。
确保您处于出站请求超时范围内。如果您的应用程序将任何连接保持在超过此阈值的空闲状态，则网关需要获取该连接。
默认情况下，Cloud Run禁用TCP套接字选项keepalive。在Cloud Run中，没有直接的方法在服务级别配置keepalive选项，但是您可以在打开新的TCP套接字连接时通过提供正确的套接字选项为每个套接字连接启用keepalive选项，具体取决于您在应用程序中用于此连接的客户端库。
偶尔出站连接会由于基础设施更新而重置。如果您的应用程序重用长期连接，则建议您将应用程序配置为重新建立连接，以避免重用死连接。