Google Cloud Kuberbetes 失控 systemd CPU 使用率 100%

Question 1

与 Google 合作后，我们终于解决了这个问题。简而言之，我们必须创建一个运行 GKE 1.12.8-gke.10 的新节点池，并使用持久卷将所有 pod 转移到该池。

长版本

这是我希望在调试时立即想到的事情，但我必须感谢谷歌支持团队的 Francisco 和 Lynn。

故障排除过程中的一个关键时刻是我们对负载进行分段。有一次，我们为每种类型的 Pod 指定了一个特定的节点池。这使我们能够回答这个问题：问题是否特定于某种类型的 Pod？我们怀疑安装活动与该问题有关，因此特别感兴趣的是查看具有持久卷的 Pod 是否与节点性能下降相关。

事实证明确实如此。只有运行带有卷的 pod 的节点才会发热。

根本原因

Google GKE 团队的假设是，Docker 在 17.03 和 18.09 版本之间的变化导致每当execpod 中有东西被“添加”时，就会产生大量的 systemd 活动。具体来说，他们的一名工程师发现了一个变化，runc这会导致所有挂载单元作为 exec 活跃度探测的一部分被重新加载。

因此，解决这个问题的秘诀有三个：

Docker 18（GKE 13 使用）
每个节点安装多个卷
用于exec活性探测（或者其他我认为的）

我们每个节点运行大约 40 个 Redis pod。按照惯例，我们的 Redis pod 使用基于 exec 的存活探测器。此外，每个 pod 都有一个挂载卷用于永久存储。存活探测器每分钟运行一次。因此，我们每分钟有 40 个卷被重新加载 40 次。

解决问题

为了解决这个问题，我们使用节点污点隔离了所有 Redis 负载。我们创建了一个专用于 Redis 的新节点池，运行 GKE 1.12.8-gke.10。虽然 GKE 不允许您降级集群，但它允许您创建运行旧版本的新节点池。当然，我们禁用了这个新池的自动升级。

然后我们强制将所有 Redis pod 迁移到这个新池。

结果是立竿见影的：我们现在可以用 6 个 CPU 核心运行与之前用 24 个 CPU 核心一样多的负载，而且情况看起来很稳定。

Answer

与 Google 合作后，我们终于解决了这个问题。简而言之，我们必须创建一个运行 GKE 1.12.8-gke.10 的新节点池，并使用持久卷将所有 pod 转移到该池。

长版本

这是我希望在调试时立即想到的事情，但我必须感谢谷歌支持团队的 Francisco 和 Lynn。

故障排除过程中的一个关键时刻是我们对负载进行分段。有一次，我们为每种类型的 Pod 指定了一个特定的节点池。这使我们能够回答这个问题：问题是否特定于某种类型的 Pod？我们怀疑安装活动与该问题有关，因此特别感兴趣的是查看具有持久卷的 Pod 是否与节点性能下降相关。

事实证明确实如此。只有运行带有卷的 pod 的节点才会发热。

根本原因

Google GKE 团队的假设是，Docker 在 17.03 和 18.09 版本之间的变化导致每当execpod 中有东西被“添加”时，就会产生大量的 systemd 活动。具体来说，他们的一名工程师发现了一个变化，runc这会导致所有挂载单元作为 exec 活跃度探测的一部分被重新加载。

因此，解决这个问题的秘诀有三个：

Docker 18（GKE 13 使用）
每个节点安装多个卷
用于exec活性探测（或者其他我认为的）

我们每个节点运行大约 40 个 Redis pod。按照惯例，我们的 Redis pod 使用基于 exec 的存活探测器。此外，每个 pod 都有一个挂载卷用于永久存储。存活探测器每分钟运行一次。因此，我们每分钟有 40 个卷被重新加载 40 次。

解决问题

为了解决这个问题，我们使用节点污点隔离了所有 Redis 负载。我们创建了一个专用于 Redis 的新节点池，运行 GKE 1.12.8-gke.10。虽然 GKE 不允许您降级集群，但它允许您创建运行旧版本的新节点池。当然，我们禁用了这个新池的自动升级。

然后我们强制将所有 Redis pod 迁移到这个新池。

结果是立竿见影的：我们现在可以用 6 个 CPU 核心运行与之前用 24 个 CPU 核心一样多的负载，而且情况看起来很稳定。

Question 2

这里需要考虑两件事：

要查看集群中是否发生任何问题，您需要检查日志。

系统组件有两种类型：在容器中运行的组件和不在容器中运行的组件。例如：

Kubernetes 调度程序和 kube-proxy 在容器中运行。kubelet 和容器运行时（例如 Docker）不在容器中运行。在具有 systemd 的机器上，kubelet 和容器运行时会写入 journald。如果不存在 systemd，它们会写入 /var/log 目录中的 .log 文件。容器内的系统组件始终会写入 /var/log 目录，从而绕过默认日志记录机制。

例如，用于journalctl -u kubelet分析 kubelet 日志。您还可以检查pod 日志。

如果没有错误，但您可能需要使用的资源仍然存在问题自动缩放：
- HPA 根据 CPU/内存使用情况扩展 pod 副本的数量。
- 垂直 Pod 自动扩缩器 (VPA) 为现有 Pod 分配更多（或更少）的 CPU 或内存。
- 集群自动扩缩器 (CA) 根据待处理的 Pod 扩缩集群节点。

使用上述一种或多种方法的组合来动态扩展您的集群，而无需手动设置。

如果有帮助的话请告诉我。

Answer

这里需要考虑两件事：

要查看集群中是否发生任何问题，您需要检查日志。

系统组件有两种类型：在容器中运行的组件和不在容器中运行的组件。例如：

Kubernetes 调度程序和 kube-proxy 在容器中运行。kubelet 和容器运行时（例如 Docker）不在容器中运行。在具有 systemd 的机器上，kubelet 和容器运行时会写入 journald。如果不存在 systemd，它们会写入 /var/log 目录中的 .log 文件。容器内的系统组件始终会写入 /var/log 目录，从而绕过默认日志记录机制。

例如，用于journalctl -u kubelet分析 kubelet 日志。您还可以检查pod 日志。

如果没有错误，但您可能需要使用的资源仍然存在问题自动缩放：
- HPA 根据 CPU/内存使用情况扩展 pod 副本的数量。
- 垂直 Pod 自动扩缩器 (VPA) 为现有 Pod 分配更多（或更少）的 CPU 或内存。
- 集群自动扩缩器 (CA) 根据待处理的 Pod 扩缩集群节点。

使用上述一种或多种方法的组合来动态扩展您的集群，而无需手动设置。

如果有帮助的话请告诉我。

Google Cloud Kuberbetes 失控 systemd CPU 使用率 100%

答案1

长版本

根本原因

解决问题

答案2

相关内容