Figma从ECS迁移到Kubernetes以利用CNCF生态系统并降低成本
内容提要
Figma在不到12个月的时间内成功将计算平台从AWS ECS迁移到Kubernetes（EKS）。迁移的动机包括利用CNCF支持的大型生态系统、成本节约、改善开发者体验和增加可靠性。Figma在ECS中遇到了一些限制，如对StatefulSets和Helm charts的支持不足。通过切换到Kubernetes，Figma获得了高级自动缩放、服务网格和其他工具和功能。迁移项目的重点是尽量减少对服务的更改，并包括简化资源定义和提高可靠性等改进。Figma使用Karpenter进行节点自动缩放。公司进行了负载测试，并实施了逐步切换机制以实现成功的发布。初始迁移在不到12个月的时间内完成，后续活动包括引入基于Keda的自动缩放和简化开发工具。
延伸解读
迁移的核心动机：生态与成本
Figma从ECS转向Kubernetes，主要驱动力是CNCF生态的丰富工具链，如Keda、Karpenter、Istio/Envoy等，这些在ECS上难以获得。同时，ECS缺乏对StatefulSets和Helm charts的原生支持，限制了运行有状态服务和开源软件的能力。迁移还旨在降低成本和提升开发者体验，但Figma明确将成本优化限制在节点自动缩放上，避免迁移范围过度膨胀。
降低风险的关键实践
为确保迁移平稳，Figma采取了多项措施：组建专职团队并争取组织支持，提前在 staging 环境部署服务，进行负载测试，以及使用基于权重的DNS实现渐进式切换。此外，将部署拆分到三个Kubernetes集群，以减少bug或操作失误的影响。这些做法在不到12个月内完成迁移且对客户影响最小，表明充分的准备和渐进式发布是控制风险的有效手段。
成本优化的具体策略
Figma在ECS on EC2上曾过度配置资源以应对部署时的峰值，导致成本高昂。迁移时，团队决定支持节点自动缩放，采用CNCF项目Karpenter根据需求动态调整节点。这一改动虽然增加了迁移范围，但以较低的工作量换取了显著的成本节约。后续还引入了基于Keda的自动缩放，进一步优化资源利用。
迁移后的持续改进
初始迁移完成后，Figma并未停止优化。根据用户反馈，团队简化了开发工具以适配三个Kubernetes集群，并引入了细粒度的RBAC角色。同时，基于Keda的自动缩放被纳入后续计划。这些改进表明，迁移不是终点，而是持续提升开发者体验和平台可靠性的起点。
Q&A
Figma为什么选择从ECS迁移到Kubernetes？
Figma选择迁移到Kubernetes是为了利用CNCF支持的大型生态系统、节省成本、改善开发者体验和提高可靠性。
Figma在ECS中遇到了哪些限制？
Figma在ECS中遇到的限制包括对StatefulSets和Helm charts的支持不足，以及难以运行开源软件。
Figma如何确保迁移项目的成功？
Figma通过创建专门团队、进行负载测试、实施逐步切换机制和早期部署服务来确保迁移项目的成功。
Figma在迁移后获得了哪些新功能？
迁移后，Figma获得了高级自动缩放、服务网格等工具和功能，提升了整体性能和可靠性。
Figma使用了什么工具进行节点自动缩放？
Figma使用开源项目Karpenter进行节点自动缩放，以根据需求动态调整节点数量。
Figma的迁移项目花费了多长时间？
Figma的初始迁移项目在不到12个月内完成。
