Velero在AWS环境中IMDSv2配置问题解析与解决方案

背景介绍

Velero作为一款流行的Kubernetes备份恢复工具，在云原生环境中被广泛使用。近期有用户反馈在AWS环境中启用IMDSv2（Instance Metadata Service Version 2）时，Velero的S3备份存储位置(BSL)出现不可用状态，而当IMDSv2设为可选时则恢复正常。这一问题引起了我们对AWS元数据服务与Velero集成机制的深入探讨。

问题现象

用户在AWS EKS环境（Kubernetes 1.28.9）中部署Velero（测试版本包括1.11、1.13和1.14 RC1）时发现：

• 当强制要求IMDSv2时，S3备份存储位置显示为"Unavailable"
• 当IMDSv2设为可选时，S3备份存储位置恢复正常
• 使用kube2iam或IRSA等替代方案在特定环境中不可行

技术分析

IMDSv2是AWS推出的增强型元数据服务，相比v1版本提供了更高的安全性。它采用会话令牌机制，要求客户端首先获取临时令牌，然后才能访问实例元数据。Velero需要正确获取EC2实例的IAM角色凭证才能访问S3存储桶。

经过深入排查，发现问题核心在于网络跳数限制。AWS IMDS服务默认通过链路本地地址(169.254.169.254)访问，当实例的IMDS hop limit（跳数限制）被设置为1时，容器内的Velero Pod无法通过多跳网络访问实例元数据服务。

解决方案

1. 调整IMDS跳数限制：

   • 通过AWS CLI或控制台将实例的IMDS hop limit设置为至少2（推荐3）
   • 这允许容器网络中的请求能够正确到达实例元数据服务

2. 验证配置：

   • 在Pod内执行curl命令测试IMDS访问
   • 检查Velero日志确认凭证获取情况
   • 使用velero backup-location get命令验证BSL状态

最佳实践建议

1. 在生产环境中建议同时配置：

   • 适当的IMDSv2跳数限制（通常3足够）
   • 网络策略确保元数据服务访问安全
   • 定期轮换IAM角色凭证

2. 对于安全敏感环境，可考虑：

   • 使用IRSA（IAM Roles for Service Accounts）方案
   • 通过Pod身份关联更细粒度的权限

总结

Velero完全支持IMDSv2协议，但需要确保网络配置正确。跳数限制是容易被忽视的关键参数，特别是在容器化环境中。通过合理配置IMDS参数，可以在保证安全性的同时确保Velero的正常运行。这也提醒我们在云原生环境中，网络拓扑和权限传递机制需要特别关注。

对于遇到类似问题的用户，建议首先检查实例元数据的可达性，再逐步排查Velero的凭证获取流程，这样可以快速定位问题根源。