Worker节点进入“未就绪”状态，并在 kubectl describe节点的输出中出现错误：
ContainerGCFailed rpc错误：代码= DeadlineExceeded desc =超出了上下文期限
环境：
Ubuntu，16.04 LTS
Kubernetes版本：v1.13.3
Docker版本：18.06.1-ce
Kubernetes GitHub k8 git上存在一个已关闭的问题，该问题因与Docker问题相关而被关闭。
解决该问题的步骤：
journalctl -u kubelet -显示以下相关消息：
跳过pod同步-[容器运行时状态检查可能尚未完成，但PLEG运行不正常：pleg尚未成功]
这与k8公开这个问题Ready/NotReady with PLEG issues
使用cloudwatch检查AWS上的节点运行状况-一切似乎都很好。
当我将更多的Pod部署到节点（接近其资源容量，但不认为它是直接依赖项）或正在停止/启动实例（重启后就可以了，但是经过一段时间后，一切似乎都开始了）节点未就绪）。
问题：
该错误的根本原因是什么？
如何监视此类问题并确保不会发生？
有没有解决此问题的方法？
答案 0 :(得分：0)
该错误的根本原因是什么？
从我发现的情况来看，当联系Docker时出现问题时，似乎发生了错误，原因可能是因为它过载或没有响应。这是基于我的经验以及您提供的GitHub问题中提到的内容。
如何监视此类问题并确保不会发生？
似乎没有明确的缓解措施或监控措施。但是，似乎最好的方法似乎是确保您的节点不会因Pod而过载。我已经看到它并不总是显示在节点的磁盘或内存压力上-但这可能是分配给Docker的资源不足的问题，并且它无法及时响应。建议的解决方案是为您的Pod设置限制，以防止Node过载。
如果在GKE中使用托管Kubernetes（不确定，但其他供应商可能具有类似功能），则有一个名为node auto-repair的功能。这不会阻止节点压力或与Docker相关的问题，但是当它检测到不正常的节点时，可以耗尽并重新部署该节点。
如果您已经有资源和限制，那么似乎最好的办法是增加对Pod的内存资源请求，以确保不会发生这种情况。这将意味着每个节点上的Pod更少，并且每个节点上的实际使用的内存应该更低。
另一种监视/识别此问题的方式可以通过SSH进入节点来检查内存，使用PS的进程，监视syslog和command $docker stats --all < / p>
答案 1 :(得分：0)
我有同样的问题。我已经封锁并驱逐了豆荚。 重新启动服务器。节点自动进入就绪状态。