Velero 1.15.0 数据迁移组件与Azure Workload Identity的兼容性问题分析

在Kubernetes集群中使用Velero进行持久化卷备份时，Azure用户可能会遇到数据迁移组件与工作负载身份认证的兼容性问题。本文将深入分析该问题的技术背景、产生原因及解决方案。

问题背景

Velero 1.15.0版本引入了一个重要的架构变更：将数据上传操作从节点代理(node-agent)中分离出来，改为由专门的微服务Pod处理每个数据上传任务(DataUpload)。这一设计变更提升了系统的可扩展性和可靠性，但也带来了新的配置挑战。

在Azure Kubernetes Service(AKS)环境中，当用户使用CSI快照和数据迁移功能备份Azure Disk持久化卷时，通常会配置Azure Workload Identity来实现对Azure Blob存储的身份认证。这种认证机制要求Pod必须带有特定标签azure.workload.identity/use: "true"，才能从服务账户中获取客户端ID。

问题现象

升级到Velero 1.15.0后，用户发现数据迁移任务失败。根本原因是新引入的数据迁移微服务Pod没有继承主Velero Pod的工作负载身份标签。这些Pod虽然正确使用了velero-server服务账户，但由于缺少必要的标签，无法完成对Azure Blob存储的身份认证。

技术分析

数据迁移微服务Pod由CSI快照暴露器(csiSnapshotExposer)通过Expose方法创建。该方法目前仅添加了两个标签：

• velero.io/data-upload：标识特定的数据上传任务
• velero.io/exposer-pod-group：标识快照暴露器Pod组

这种设计是出于安全考虑，避免无意中泄露敏感信息或配置。然而，这也导致了Azure Workload Identity所需的关键标签被遗漏。

解决方案

Velero团队经过讨论后决定采用白名单机制来解决这个问题。在即将发布的1.15.1版本中，将把azure.workload.identity/use标签加入白名单，确保数据迁移Pod能够正确继承这一关键配置。

这种白名单方式相比黑名单有以下优势：

1. 更可控：明确知道哪些标签会被传播
2. 更安全：避免意外传播敏感或不必要的标签
3. 更稳定：减少因标签传播导致的意外行为

最佳实践建议

对于需要使用Azure Workload Identity的用户，建议：

1. 等待Velero 1.15.1版本发布后再进行升级
2. 如果必须使用1.15.0版本，可以考虑临时解决方案：
   • 修改Velero控制器代码，手动添加所需标签
   • 使用其他认证方式（如存储账户密钥）
3. 定期检查Velero GitHub仓库的更新状态

总结

Velero 1.15.0的数据迁移架构改进带来了性能优势，但也需要注意与特定云提供商功能的兼容性。通过白名单机制控制标签传播是一个平衡安全性和功能性的合理方案。用户应关注后续版本更新，确保平滑升级体验。