Amazon EKS AMI 中 nodeadm 服务与 containerd 初始化顺序问题解析

问题背景

在使用 Amazon EKS AMI 构建自定义节点镜像时，一个常见的问题出现在 nodeadm-run 服务与 containerd 容器运行时的初始化顺序上。当节点启动时，如果 containerd 尚未完全初始化完成，nodeadm-run 服务尝试拉取 pause 镜像的操作就会失败，导致节点无法正常加入 Kubernetes 集群。

问题现象

节点启动过程中，nodeadm-run 服务会在 containerd 完全就绪前尝试拉取 pause 镜像。由于 containerd 尚未准备好，连接其 Unix 套接字会失败，错误信息通常表现为：

1. "transport: Error while dialing: dial unix /run/containerd/containerd.sock: connect: no such file or directory"
2. "server is not initialized yet"

nodeadm 默认会进行三次重试，如果都失败，则整个服务会退出，导致节点无法加入集群。这种情况在节点启动时随机发生，大约影响25%的节点。

技术分析

这个问题本质上是一个服务依赖和初始化顺序的问题。在系统启动过程中，多个服务并行启动，而 nodeadm-run 服务没有明确声明对 containerd 服务的依赖关系。

从技术实现角度看，nodeadm 通过 CRI (Container Runtime Interface) 与 containerd 交互。当 containerd 尚未完成初始化时，其 gRPC 服务不可用，导致任何 CRI 操作都会失败。

解决方案演进

临时解决方案

在等待官方修复期间，可以通过修改 systemd 单元文件来解决问题：

1. 在 nodeadm-run.service 的 After 指令中添加 containerd.service 依赖
2. 配置服务失败时自动重试

这种方案虽然有效，但属于临时性解决方案，需要手动维护系统配置。

官方修复方案

Amazon EKS AMI 团队在后续版本中修复了这个问题，主要改进包括：

1. 在 nodeadm 代码中添加了对 containerd 服务可用性的检查
2. 实现了更智能的重试机制，确保在 containerd 完全就绪后才进行操作

这种方案更加健壮，不需要用户进行任何额外配置。

最佳实践建议

对于使用 Amazon EKS AMI 的用户，建议：

1. 使用最新版本的 AMI，确保包含此问题的修复
2. 如果必须使用旧版本，可以采用修改 systemd 单元文件的临时方案
3. 监控节点加入集群的成功率，及时发现类似问题

技术启示

这个问题展示了在分布式系统中服务启动顺序的重要性。在设计系统服务时，应该：

1. 明确定义服务间的依赖关系
2. 对依赖服务进行健康检查
3. 实现合理的重试机制
4. 提供足够的错误信息和日志

这些原则不仅适用于容器编排系统，也适用于任何复杂的分布式系统设计。

通过这个案例，我们可以更好地理解容器运行时与集群管理组件之间的交互机制，以及如何构建更加健壮的云原生基础设施。