Jenkins 在 CPU 使用率高时使 Kubernetes 节点卡住
Jenkins makes a Kubernetes node stuck when high CPU usage
我注意到在启动某些 Jenkins 构建时，托管 Jenkins 的节点有时会永远卡住。这意味着整个节点不可访问，并且其所有 pods 都已关闭（仪表板中未就绪）。
为了再次弥补，我需要将其从集群中删除并再次添加（我在 GCE 上，因此我需要将其从实例组中删除才能删除它）。
注意：在几个小时内我无法通过 SSH 连接到该节点，显然它已停止服务 ^^
根据我的理解，达到内存上限会使节点崩溃，但达到内存上限 CPU 使用率应该只会减慢服务器速度，不会像我遇到的那样造成大问题。在最坏的情况下，Kubelet 应该在 CPU 变得更好之前不可用。
有人能帮我确定这个问题的根源吗？什么会导致这样的问题？
Node metrics 1
Node metrics 2
Jenkins slave metrics
Node metrics from GCE
另一方面，在等待几个小时后，我已经能够通过 SSH 访问该节点，并且我 运行 sudo journalctl -u kubelet 想看看发生了什么。我在晚上 7 点没有看到任何具体信息，但我能够看到重复出现的错误，例如：
Apr 04 19:00:58 nodes-s2-2g5v systemd[43508]: kubelet.service: Failed at step EXEC spawning /home/kubernetes/bin/kubelet: Permission denied
Apr 04 19:00:58 nodes-s2-2g5v systemd[1]: kubelet.service: Main process exited, code=exited, status=203/EXEC
Apr 04 19:00:58 nodes-s2-2g5v systemd[1]: kubelet.service: Unit entered failed state.
Apr 04 19:00:58 nodes-s2-2g5v systemd[1]: kubelet.service: Failed with result 'exit-code'.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: Stopped Kubernetes Kubelet Server.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
Apr 04 19:01:00 nodes-s2-2g5v systemd[43511]: kubelet.service: Failed at step EXEC spawning /home/kubernetes/bin/kubelet: Permission denied
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Main process exited, code=exited, status=203/EXEC
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Unit entered failed state.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Failed with result 'exit-code'.
Apr 04 19:01:02 nodes-s2-2g5v systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Apr 04 19:01:02 nodes-s2-2g5v systemd[1]: Stopped Kubernetes Kubelet Server.
Apr 04 19:01:02 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
我查看较旧的日志，在 5:30pm 处找到此类消息的开头：
Apr 04 17:26:50 nodes-s2-2g5v kubelet[1841]: I0404 17:25:05.168402 1841 prober.go:111] Readiness probe for "...
Apr 04 17:26:50 nodes-s2-2g5v kubelet[1841]: I0404 17:25:04.021125 1841 prober.go:111] Readiness probe for "...
-- Reboot --
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
Apr 04 17:31:31 nodes-s2-2g5v systemd[1699]: kubelet.service: Failed at step EXEC spawning /home/kubernetes/bin/kubelet: Permission denied
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: kubelet.service: Main process exited, code=exited, status=203/EXEC
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: kubelet.service: Unit entered failed state.
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: kubelet.service: Failed with result 'exit-code'.
Apr 04 17:31:33 nodes-s2-2g5v systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Apr 04 17:31:33 nodes-s2-2g5v systemd[1]: Stopped Kubernetes Kubelet Server.
Apr 04 17:31:33 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
此时node kubelet重启，对应一次Jenkins构建。 CPU 使用率高的模式相同。我不知道为什么早些时候它刚刚重新启动并且在晚上 7 点左右节点卡住了：/
真的很抱歉，信息很多，但我完全迷路了，这不是第一次发生在我身上^^
谢谢，
正如@Brandon 所提到的，它与应用于我的 Jenkins 奴隶的资源限制有关。
在我的例子中，即使在我的 Helm 图表 YAML 文件中进行了精确设置，也没有设置值。我不得不深入 UI 手动设置它们。
从这次修改开始，一切都稳定了！ :)
我注意到在启动某些 Jenkins 构建时，托管 Jenkins 的节点有时会永远卡住。这意味着整个节点不可访问，并且其所有 pods 都已关闭（仪表板中未就绪）。
为了再次弥补，我需要将其从集群中删除并再次添加（我在 GCE 上，因此我需要将其从实例组中删除才能删除它）。
注意：在几个小时内我无法通过 SSH 连接到该节点，显然它已停止服务 ^^
根据我的理解，达到内存上限会使节点崩溃，但达到内存上限 CPU 使用率应该只会减慢服务器速度，不会像我遇到的那样造成大问题。在最坏的情况下，Kubelet 应该在 CPU 变得更好之前不可用。
有人能帮我确定这个问题的根源吗？什么会导致这样的问题？
Node metrics 1
Node metrics 2
Jenkins slave metrics
Node metrics from GCE
另一方面，在等待几个小时后，我已经能够通过 SSH 访问该节点，并且我 运行 sudo journalctl -u kubelet 想看看发生了什么。我在晚上 7 点没有看到任何具体信息，但我能够看到重复出现的错误，例如：
Apr 04 19:00:58 nodes-s2-2g5v systemd[43508]: kubelet.service: Failed at step EXEC spawning /home/kubernetes/bin/kubelet: Permission denied
Apr 04 19:00:58 nodes-s2-2g5v systemd[1]: kubelet.service: Main process exited, code=exited, status=203/EXEC
Apr 04 19:00:58 nodes-s2-2g5v systemd[1]: kubelet.service: Unit entered failed state.
Apr 04 19:00:58 nodes-s2-2g5v systemd[1]: kubelet.service: Failed with result 'exit-code'.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: Stopped Kubernetes Kubelet Server.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
Apr 04 19:01:00 nodes-s2-2g5v systemd[43511]: kubelet.service: Failed at step EXEC spawning /home/kubernetes/bin/kubelet: Permission denied
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Main process exited, code=exited, status=203/EXEC
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Unit entered failed state.
Apr 04 19:01:00 nodes-s2-2g5v systemd[1]: kubelet.service: Failed with result 'exit-code'.
Apr 04 19:01:02 nodes-s2-2g5v systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Apr 04 19:01:02 nodes-s2-2g5v systemd[1]: Stopped Kubernetes Kubelet Server.
Apr 04 19:01:02 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
我查看较旧的日志，在 5:30pm 处找到此类消息的开头：
Apr 04 17:26:50 nodes-s2-2g5v kubelet[1841]: I0404 17:25:05.168402 1841 prober.go:111] Readiness probe for "...
Apr 04 17:26:50 nodes-s2-2g5v kubelet[1841]: I0404 17:25:04.021125 1841 prober.go:111] Readiness probe for "...
-- Reboot --
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
Apr 04 17:31:31 nodes-s2-2g5v systemd[1699]: kubelet.service: Failed at step EXEC spawning /home/kubernetes/bin/kubelet: Permission denied
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: kubelet.service: Main process exited, code=exited, status=203/EXEC
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: kubelet.service: Unit entered failed state.
Apr 04 17:31:31 nodes-s2-2g5v systemd[1]: kubelet.service: Failed with result 'exit-code'.
Apr 04 17:31:33 nodes-s2-2g5v systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Apr 04 17:31:33 nodes-s2-2g5v systemd[1]: Stopped Kubernetes Kubelet Server.
Apr 04 17:31:33 nodes-s2-2g5v systemd[1]: Started Kubernetes Kubelet Server.
此时node kubelet重启，对应一次Jenkins构建。 CPU 使用率高的模式相同。我不知道为什么早些时候它刚刚重新启动并且在晚上 7 点左右节点卡住了：/
真的很抱歉，信息很多，但我完全迷路了，这不是第一次发生在我身上^^
谢谢，
正如@Brandon 所提到的，它与应用于我的 Jenkins 奴隶的资源限制有关。
在我的例子中，即使在我的 Helm 图表 YAML 文件中进行了精确设置，也没有设置值。我不得不深入 UI 手动设置它们。
从这次修改开始，一切都稳定了！ :)