worker节点正在进入"未准备就绪的"状态，在 kubectl的输出中有一个错误描述节点：
containerGcfailed rpc错误：代码= decarexceeded desc =上下文截止日期超过
环境：
ubuntu，16.04 lts
kubernetes版本：v1.13.3
Docker版本：18.06.1-CE
在Kubernetes Github K8 Git上存在一个封闭的问题，该问题是根据与Docker问题相关的优点而封闭的。
对问题进行故障排除的步骤：
- kubectl描述节点 - 发现了错误的错误（根本原因尚不清楚）。
-
Journalctl -U Kubelet - 显示此相关消息：
跳过POD同步 - [容器运行时状态检查可能尚未完成，但PLEG不健康：PLEG尚未成功]
它与此开放的K8问题有关/没有PLEG问题
-
使用CloudWatch在AWS上检查节点健康 - 一切似乎都很好。
- Journalctl -fu Docker.service ：检查Docker是否错误/问题 - 输出不显示与此相关的任何erros。
- SystemCtl重新启动Docker - 重新启动Docker后，节点进入"准备就绪"状态，但在3-5分钟内再次变为"未准备好"。
当我将更多的豆荚部署到节点时（接近其资源能力，但不认为它是直接依赖性）或正在停止/启动实例（重新启动后，但是一段时间后，这一切似乎都开始了节点还没有准备就绪）。
问题：
错误的根本原因是什么？
如何监视此类问题并确保不会发生？
这个问题有任何解决方法吗？
错误的根本原因是什么？
从我能够发现的情况下，当问题与Docker联系时，这似乎是因为它已超载或因为它没有反应而发生。这是基于我的经验以及您提供的GitHub问题中提到的内容。
如何监视此类问题并确保不会发生？
似乎没有澄清的缓解或监测。但这似乎最好的方法是确保您的节点不会被豆荚过载。我已经看到，它并不总是在节点的磁盘或内存压力上显示 - 但这可能是一个没有足够的资源的问题，分配给Docker，并且无法及时响应。建议的解决方案是为豆荚设置限制，以防止节点过载。
如果GKE中有托管的kubernetes（不确定其他供应商可能具有类似功能），则有一个名为Node Auto-Repair的功能。这将无法防止节点压力或与Docker相关的问题，但是当它检测到不健康的节点时，它会排出并重新部署节点/s。
如果您已经有资源和限制，则似乎确保这不发生的最佳方法是增加对Pods的内存资源请求。这将意味着每个节点的POD较少，并且每个节点上的实际使用内存应较低。
可以通过SSH进入节点的另一种监视/识别方法，请检查内存，使用PS的进程，监视syslog和命令$docker stats --all
我也遇到了同样的问题。我已经封锁并驱逐了豆荚。重新启动了服务器。自动节点进入就绪状态。