Equinix 如何借助 Amazon EKS 上的共享服务架构降低运维开销
内容提要
Equinix 将自管 Kubernetes 迁移至 Amazon EKS，采用多账户共享服务架构，分离工作负载、平台、网络三类账户，由云运维团队集中治理基础设施，应用团队专注业务。成果包括运维开销降低 40%、部署频率提升 4 倍、架构统一，并改善可观测性、安全性与新团队上线速度。
延伸解读
从自管到托管：运维负担的转移
Equinix 此前在 EC2 上自管 Kubernetes，需自行维护 etcd、控制平面和工作节点，并依赖开源工具完成安装配置。迁移到 Amazon EKS 后，AWS 接管了升级、补丁和高可用性管理，这是运维开销降低 40% 的直接原因。对于面临类似集群生命周期复杂性的团队，这一转变意味着将底层基础设施的维护责任转移给云厂商，从而让云运维团队能专注于治理和共享服务，而非节点运维。
多账户隔离：安全与治理的结构性解法
Equinix 的 North Star 架构将环境划分为工作负载、平台和网络三个核心账户，分别承载应用服务、共享基础设施和跨账户连接。这种隔离不仅通过 Cilium 网络策略实现 Pod 级分段，还缩小了潜在安全事件的影响范围，并简化了合规执行。对于受监管行业或需要严格网络隔离的企业，这种账户级隔离模式提供了一种可复用的治理框架，但需注意其依赖 AWS Transit Gateway 和 Route 53 Resolver 等组件实现跨账户通信。
共享服务模型：效率提升与团队自治的平衡
平台账户集中提供 CI/CD（GitHub Runners）、可观测性（Hubble）和数据服务（RDS、MSK 等），应用团队通过自助命名空间部署，无需管理集群基础设施。这带来了部署频率提升 4 倍和新团队上线从数周缩短至数天的效果。然而，这种模型要求云运维团队承担起共享服务的可用性和性能责任，应用团队则需适应标准化的部署流程。适合已具备一定平台工程能力、且应用团队数量较多的组织。
架构统一后的扩展性与潜在考量
North Star 架构已在多个业务组织实现 100% 统一，并计划扩展到更多地区和业务线。统一架构降低了碎片化，但同时也意味着对平台账户和网络账户的集中依赖增强。如果共享服务出现故障，可能影响所有工作负载。因此，在采用类似模式时，需评估共享服务的冗余设计、跨账户监控以及故障隔离策略，确保集中化不会引入新的单点风险。
Q&A
Equinix 为什么要把自管 Kubernetes 迁移到 Amazon EKS？
Equinix 之前自管 Kubernetes 时，各应用团队独立管理集群，导致运维蔓延、缺乏集中治理、没有共享服务模型、集群生命周期复杂。为了从根本上解决这些问题，他们迁移到 Amazon EKS，采用共享服务架构，由云运维团队集中治理基础设施，应用团队专注业务。
Equinix 在 Amazon EKS 上的共享服务架构包含哪些核心账户？
架构包含三个核心 AWS 账户：Workloads 账户（运行应用服务，使用 ALB 和 Cilium 进行流量管理和网络策略）、Platform 账户（由云运维团队管理共享服务，如 RDS、MSK、OpenSearch、MQ、S3 和 GitHub Runners）、Network 账户（作为连接枢纽，通过 Transit Gateway 和 Direct Connect 实现跨账户和混合连接）。
迁移到 Amazon EKS 后，Equinix 取得了哪些可量化的成果？
运维开销降低了 40%，部署频率提升了 4 倍，100% 统一架构被多个业务组织采用。此外，还提升了开发人员生产力、可观测性、安全性，并加速了新团队上线（从数周缩短到数天）。
Equinix 的 North Star 架构如何提升安全性？
通过多账户隔离（应用与共享服务工作负载分离）和 Cilium 网络策略实现 Pod 级分段，减少了潜在安全事件的范围，并简化了合规性执行。
Equinix 如何加速新应用团队的上手过程？
新团队可以在几天内（而非几周）加入 North Star 架构，部署到预配置的命名空间中，并直接使用共享数据服务、CI/CD 流水线和可观测性工具，无需自行配置或管理集群基础设施。
Equinix 的 North Star 架构中，网络连接是如何实现的？
通过 Network 账户中的 AWS Transit Gateway 实现跨账户连接，连接 Workloads 和 Platform VPC；使用 Route 53 Resolver 端点进行 DNS 解析；通过 AWS Direct Connect Gateway 和双电路连接回本地 Equinix 边界路由器，实现混合连接。
