由于docker数据目录在节点上移动，服务/部署间歇性地停留在ContainerCreating上的问题

Question

在8个节点上运行kubeadm集群（版本v1.13.1）（7个运行RHEL 7.x，一个运行Ubuntu 18.04.2;在API上的docker版本1.13.1 w / API在Ver.1.26上具有API ver 1.26）版本1.39）。

直到第二天，主节点由于docker-current耗尽内存而使机器变得混乱，所有机器都运转良好，这需要重新启动。

现在一切都已备份并运行，我再次开始测试集群。但是，胡言乱语的行为开始发生：在某些使用Pod服务在Pod之间进行通信的Pod中，服务名称未作为主机名（如svc_name.default）被拾取，并且当我提交服务/部署时，部署卡在{{ 1}}。如果我在尝试将Pod部署到的节点上重新启动ContainerCreating，则它将经历下一次尝试，并且部署Pod不会出现问题。

我只是根据kubelet至--system-reserved=cpu=500m,memory=1Gi在内存/ cpu受限的节点上添加了资源限制，但这根本没有帮助。

我正在使用MetricsServer和仪表板监视群集，没有发现任何异常。我还使用/etc/systemd/system/kubelet.service.d/10-kubeadm.conf清理了日志，没有弹出任何内容。

我已经按照dns debugging检查了DNS，一切都很好。因此，虽然我怀疑在主节点锁定时引入了一些潜在的问题，但是不确定为什么不总是选择作为主机的服务名称。

我很想重建群集，但也很犹豫，尤其是如果这些问题可以解决的话。

有什么想法吗？我搜索的所有内容都不适用于此问题。我们即将进行生产，而且时间安排不是很好。

编辑

以下是对吊舱旋转失败的描述，这很有意义：

journalctl

问题是我更改了节点Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 25s default-scheduler Successfully assigned default/nlp-adapt-wf-wmw6r-2161497416 to bpb.X.X.X Warning FailedMount 9s (x6 over 25s) kubelet, bpb.X.X.X MountVolume.SetUp failed for volume "docker-lib" : hostPath type check failed: /var/lib/docker is not a directory 上的docker数据目录的默认位置，但是显然kubernetes不够聪明。

对此我的谷歌搜索没有产生任何有价值的结果。

如何让kubernetes知道该节点上的docker数据现在位于何处？ Docker本身在此节点上运行良好。

Answer 1

创建从docker数据文件夹的新位置到/var/lib/docker的符号链接似乎已经解决了该问题。