Kubernetes 节点的自动修复

我们使用Kubernetes运行许多不同的服务我们控制 Cloudflare 的边缘我们有五个地理上不同的集群在我们最大的集群中有数百个节点。这些集群在裸机上进行自我管理，这为我们在软件和与 Kubernetes 的集成方面提供了强大的功能和灵活性。但是，这也意味着我们没有可依赖的云提供商来虚拟化或管理节点。当考虑到节点降级的所有不同原因时，这种区别变得更加突出。对于自我管理的裸机，导致节点变得不健康的原因列表包括： 硬件故障 内核级软件故障 Kubernetes 集群级软件故障 网络通信降级 需要软件更新 资源枯竭。

不开心的节点 在上述类别中我们有很多失败的例子但有一个例子处理起来特别乏味它从内核的以下日志行开始 随着容器网络 印度尼西亚电话号码 接口 (CNI) 插件拥有的节点上的网络接口数量与正在运行的 pod 数量不成比例，进一步观察到该问题这是出乎意料的，因为它不应超过节点上允许的最大 pod 数（我们使用默认限制 110）。虽然这个问题很有趣，也许值得单独写一篇博客，但不足之处在于 CNI 拥有的 Linux 网络接口在 Pod 终止后没有得到清理。 可以在Docker GitHub 问题中阅读有关这方面的一些历史。



我们发现这似乎困扰着正常运行时间较长的节点并且在重新启动节点后它可以正常运行大约一个月但是由于节点数量众多这种情况每天会发生多次。每个实例都需要重新启动，这意味着通过我们的工作人员重新启动过程，如下所示： 封锁受影响的节点以防止新的工作负载在其上调度。 收集任何诊断信息以供以后调查。 排空当前工作负载的节点。 重新启动并等待节点恢复。 验证节点是否健康。 重新启用对节点的新工作负载调度。 虽然解决根本问题是理想的，但我们需要一种缓解措施以避免同时劳累——一个自动化的节点修复过程。