Kubernetes GKE 拨号后端时出错:EOF on random exec 命令

Kubernetes GKE Error dialing backend: EOF on random exec command

提问人:user3669002 提问时间:6/20/2018 最后编辑:user3669002 更新时间:2/15/2021 访问量:2820

问:

在 GKE 上,我们在 API 上遇到了一些随机错误。 很多年前,我们有“拨号后端时出错:EOF”。

我们在 K8s 之上使用 Jenkins 来管理我们的构建。不久前,作业因此错误而终止:

Executing shell script inside container [protobuf] of pod [kubernetes-bad0aa993add416e80bdc1e66d1b30fc-536045ac8bbe]
java.net.ProtocolException: Expected HTTP 101 response but was '500 Internal Server Error'
    at com.squareup.okhttp.ws.WebSocketCall.createWebSocket(WebSocketCall.java:123)
    at com.squareup.okhttp.ws.WebSocketCall.access$000(WebSocketCall.java:40)
    at com.squareup.okhttp.ws.WebSocketCall$1.onResponse(WebSocketCall.java:98)
    at com.squareup.okhttp.Call$AsyncCall.execute(Call.java:177)
    at com.squareup.okhttp.internal.NamedRunnable.run(NamedRunnable.java:33)
    at 


  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at 

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

这个案例看起来很像:https://gitlab.com/gitlab-org/gitlab-runner/issues/3247

许多审核日志 URL:

permission:  "io.k8s.core.v1.pods.exec.create"     
resource:  "core/v1/namespaces/default/pods/pubsub-6132c0bc-2542-46a2-8041-c865f238698d-4ccc0-c1nkz-lqg5x/exec/pubsub-6132c0bc-2542-46a2-8041-c865f238698d-4ccc0-c1nkz-lqg5x"     

permission:  "io.k8s.core.v1.pods.exec.get"     
resource:  "core/v1/namespaces/default/pods/pubsub-a5a21f14-0bd1-4338-87b1-8658c3bbc7ad-9gm4n-8nz14/exec"     

但我不明白为什么这个错误会出现在 Kubernetes 上......

更新:

这些错误可以通过 kube-state-metrics 进行验证,其中有 2 个: - ssh_tunnel_open_count - ssh_tunnel_open_fail_count

对我来说,随着 200 多个 ssh 隧道的打开,开放隧道 ssh 失败的数量会增长。

作为信息,我们用 GKE 做了一些测试 - SWITH从区域集群到区域集群 - 使用新的本地 IP(旧的别名 IP) 但这并不能解决问题。

在 node-pool 上禁用自动缩放后,我们不再出现错误。

网络 EOF Google-Kubernetes-Engine

评论

0赞 N Singh 7/6/2018
如果你认为这是一个 GKE 问题,我建议你使用这个链接打开一个私人问题报告,提供相关信息(例如:project-id、cluster-name、pod、K8 版本等)和复制步骤(如果可能)进行验证。
0赞 Kalle Richter 2/15/2021
我一直在调查这种行为以及 Jenkins 中的相应问题以及 .似乎 GitLab 通过捕获并重试解决了这个问题。Jenkins 看到了 K8s 中的问题。在第一次测试中,重试似乎是一种解决方法,但是这需要 Jenkinsfiles 中的每个语句都包装在重试函数中(时髦的闭包是有帮助的,但它仍然是一个疯狂的影响)。任何更新甚至解决方案?gitlab-runnerjava.net.ProtocolException

答:

0赞 Kalle Richter 2/15/2021 #1

我可以通过停用自动缩放配置文件/将配置文件重置回默认值来解决这个问题。 无论如何都处于测试状态。optimize-utilizationbalancedoptimize-utilization