K8S 从懵圈到熟练：读懂此文，集群节点不下线！

Containerd 作为一个 gRPC 的服务器，会在接到 docker daemon 的远程调用之后，新建一个线程去处理这次请求。关于 gRPC 的细节，我们这里其实不用太多关注。在这次请求的客户端调用栈上，可以看到这次调用的核心函数在 Start 一个Process 。我们在 containerd 的调用栈里搜索 Start，Process 以及 process.go 等字段，很容易发现下边这个线程。

这个线程的核心任务，就是依靠 runC 去创建容器进程。而在容器启动之后，runC 进程会退出。所以下一步，我们自然而然会想到，runC 是不是有顺利完成自己的任务。查看进程列表，我们会发现，系统中有个别 runC 进程还在执行，这不是预期的行为。容器的启动，跟进程的启动，耗时应该是差不多数量级的，系统里有正在运行的 runC 进程，则说明 runC 不能正常启动容器。

什么是D-Bus?

RunC请求D-Bus

容器 runtime 的 runC 命令，是 libcontainer 的一个简单的封装。这个工具可以用来管理单个容器，比如容器创建和容器删除。在上节的最后，我们发现 runC 不能完成创建容器的任务。我们可以把对应的进程杀掉，然后在命令行用同样的命令启动容器，同时用 strace 追踪整个过程。

分析发现，runC 停在了向带有 org.free 字段的 dbus socket 写数据的地方。那什么是 dbus 呢?在 Linux 上，dbus 是一种进程间进行消息通信的机制。

原因并不在 D-Bus

我们可以使用 busctl 命令列出系统现有的所有 bus 。如下图，在问题发生的时候，我看到问题节点 bus name 编号非常大。所以我倾向于认为，dbus 某些相关的数据结构，比如 name，耗尽了引起了这个问题。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!