Figma从AWS ECS迁移到Kubernetes (EKS)的全面总结

迁移背景与动机

Figma在不到12个月的时间内，将其计算平台从AWS ECS迁移到Kubernetes (EKS)，且对客户的影响极小。公司决定采用Kubernetes主要基于以下几点原因：

1. 利用CNCF支持的庞大生态系统：Kubernetes拥有广泛的社区支持和丰富的工具链。
2. 成本节约：通过动态节点自动扩展等功能，优化资源使用，降低成本。
3. 提升开发者体验：简化资源配置，提供更友好的开发工具。
4. 增强系统弹性：通过多集群部署，减少由错误和操作失误带来的影响。

ECS的局限性

Figma在2023年初开始使用AWS的ECS作为容器编排平台，但很快遇到了以下问题：

• 缺乏对StatefulSets的支持：ECS无法有效管理有状态应用。
• 不支持Helm图表：ECS无法使用Helm进行应用部署和管理。
• 难以运行开源软件：如Temporal等开源工具在ECS上运行困难。
• 定制化成本高：需要大量工程投入来满足特定需求。

Kubernetes的优势

Figma认识到Kubernetes在以下方面的优势：

• 丰富的生态系统：包括Keda、Karpenter、Istio/Envoy等工具，支持高级自动扩展和服务网格功能。
• 工程师资源丰富：市场上熟悉Kubernetes的工程师较多，便于招聘和团队扩展。

迁移策略与实施

Figma在迁移过程中采取了以下策略：

1. 明确迁移范围：尽量减少对现有服务的改动，避免延迟和风险。
2. 改进资源定义：简化资源配置，提升开发者体验。
3. 多集群部署：将部署分成三个Kubernetes集群，提高系统可靠性。
4. 动态节点扩展：使用Karpenter实现基于需求的动态节点扩展，节省成本。

团队与协作

为确保迁移成功，Figma组建了专门的团队，并与整个组织进行沟通，确保各方支持。工程师们通过以下措施确保顺利迁移：

• 负载测试：在生产上线前对Kubernetes设置进行负载测试。
• 逐步切换机制：使用加权DNS记录实现逐步切换。
• 早期部署到测试集群：提前将服务部署到测试集群，解决潜在问题。
• 提供“黄金路径”：与各服务所有者合作，确保一致性和易于维护。

后续工作

核心服务迁移完成后，团队开始进行后续优化：

• 引入Keda自动扩展：进一步优化资源使用。
• 简化开发者工具：根据用户反馈，简化与三个Kubernetes集群的交互工具。
• 细粒度RBAC角色：引入更精细的权限管理，提升安全性。

结论

Figma通过精心规划和执行，成功在短时间内将计算平台从ECS迁移到Kubernetes，不仅提升了系统的弹性和开发者体验，还实现了显著的成本节约。这一迁移案例为其他企业提供了宝贵的经验和参考。