Amazon EKS AMI中Inf2实例启动失败问题分析与解决

问题背景

在使用Amazon EKS优化计算AMI创建Inf2.xlarge实例组时，用户遇到了实例启动失败的问题。该问题表现为CloudFormation栈报错"Unable to satisfy 100% MinSuccessfulInstancesPercent requirement"，导致实例组创建失败。

问题现象分析

通过检查实例日志，发现主要问题出现在cloud-init执行过程中：

1. cloud-init.log显示脚本执行失败，特别是/var/lib/cloud/instance/scripts/part-001脚本退出码为1
2. cloud-init-output.log显示专用硬件引导助手检测到没有特定设备后正常退出(exit 0)
3. 但随后bootstrap.sh脚本在检查硬件状态时意外退出，并发送了失败信号给CloudFormation

根本原因

问题的核心在于bootstrap.sh脚本的设计缺陷：

1. 脚本错误地将特定硬件检查放在主流程中，而不是放在专用帮助脚本中
2. 当在不支持的实例类型上运行时，这个检查会导致脚本异常终止
3. 脚本随后通过cfn-signal发送失败信号，导致CloudFormation栈创建失败

技术原理

Amazon EKS优化计算AMI原本主要为特定计算实例设计，其bootstrap.sh脚本包含了对特定硬件的检查。然而，AWS Neuron设备(如Inf2实例)使用不同的架构，不应触发这些特定检查。

在当前的实现中：

• 硬件引导助手正确检测到不支持设备并正常退出
• 但主bootstrap脚本仍然执行了不适用于所有实例类型的通用检查
• 这种不恰当的检查导致脚本异常终止

解决方案

AWS团队已经确认这是一个需要修复的问题，并计划在下一版AMI中发布修复。修复方案包括：

1. 将特定硬件检查逻辑移到专用帮助脚本中
2. 确保主bootstrap脚本不会因为硬件类型检查而异常终止

临时解决方案

在官方修复发布前，用户可以采取以下临时措施：

1. 修改bootstrap.sh脚本，移除或注释掉导致问题的硬件检查
2. 禁用cfn-signal功能，避免发送失败信号给CloudFormation
3. 使用自定义AMI，在其中预先应用这些修改

最佳实践建议

为避免类似问题，建议：

1. 在使用特殊计算实例时，仔细检查AMI的兼容性说明
2. 对于生产环境，考虑先在小规模测试环境中验证实例启动流程
3. 监控AWS官方文档和AMI更新日志，及时获取最新修复
4. 对于关键业务，建立自定义AMI的构建流程，以便快速应用必要的修改

总结

这个问题展示了在支持多种计算架构时可能遇到的兼容性挑战。AWS团队已经确认问题并将发布修复，同时用户也可以采取临时措施绕过问题。对于依赖Inf2等特殊计算实例的用户，建议关注官方AMI更新，以便及时获取修复版本。