Kubernetes 节点未就绪:超出 ContainerGCFailed/ImageGCFailed 上下文截止日期

Ale*_*lex 8 kubernetes

工作节点进入“NotReady”状态,kubectl describe node的输出出现错误:

ContainerGCFailed rpc 错误:代码 = DeadlineExceeded desc = 超出上下文期限

环境:

Ubuntu,16.04 LTS

Kubernetes 版本:v1.13.3

Docker 版本:18.06.1-ce

在 Kubernetes GitHub k8 git上有一个关闭的问题,该问题由于与 Docker 问题相关的优点而被关闭。

解决问题的步骤:

  1. kubectl describe node - 发现有问题的错误(根本原因尚不清楚)。
  2. journalctl -u kubelet - 显示此相关消息:

    跳过 pod 同步 - [容器运行时状态检查可能尚未完成但 PLEG 不健康:pleg 尚未成功]

    它与这个开放的 k8 问题Ready/NotReady with PLEG 问题有关

  3. 使用 cloudwatch 检查 AWS 上的节点运行状况 - 一切似乎都很好。

  4. journalctl -fu docker.service:检查docker是否有错误/问题 - 输出没有显示任何与此相关的错误。
  5. systemctl restart docker - 重新启动 docker后,节点进入“就绪”状态,但 3-5 分钟后再次变为“未就绪”。

当我将更多 Pod 部署到节点(接近其资源容量但不认为它是直接依赖)或正在停止/启动实例(重新启动后就可以了,但一段时间后节点未就绪时,这一切似乎都开始了)。

问题:

错误的根本原因是什么?

如何监控此类问题并确保它不会发生?

这个问题有什么解决方法吗?

aur*_*ius 5

错误的根本原因是什么?

据我所知,当联系 Docker 出现问题时,似乎会发生错误,要么是因为它过载,要么是因为它没有响应。这是基于我的经验以及您提供的 GitHub 问题中提到的内容。

如何监控此类问题并确保它不会发生?

对此似乎没有明确的缓解或监控措施。但似乎最好的方法是确保您的节点不会因 Pod 而过载。我发现它并不总是显示在节点的磁盘或内存压力上 - 但这可能是分配给 Docker 的资源不足并且无法及时响应的问题。建议的解决方案是为 pod 设置限制,以防止节点过载。

对于 GKE 中的托管 Kubernetes(不确定,但其他供应商可能有类似的功能),有一个称为节点自动修复的功能。这不会阻止节点压力或 Docker 相关问题,但当它检测到不健康的节点时,它可以耗尽并重新部署节点。

如果您已经拥有资源和限制,那么确保这种情况不会发生的最佳方法似乎是增加 Pod 的内存资源请求。这意味着每个节点上的 Pod 会更少,并且每个节点上实际使用的内存应该会更低。

监视/识别这一点的另一种方法可以通过 SSH 进入节点检查内存、进程PS、监视syslog命令 $docker stats --all