当 Kubernetes 集群、账号、网络和平台组件不断增加时，团队很容易从“交付应用”滑向“维护一大片基础设施”。Equinix 的做法是以 Amazon EKS 为运行底座，采用多账号 North Star 架构，把治理能力和共享服务集中起来，减少自建 Kubernetes 环境带来的运维蔓延。
根据案例摘要，这种架构带来了两个醒目的结果：部署速度提升 4 倍，运维开销降低 40%。关键并不只是把集群迁移到 EKS，而是重新划分平台职责：哪些能力应该集中管理，哪些能力应该留在业务账号和应用团队手中。
从“每个团队一套平台”转向共享服务
在自管理 Kubernetes 环境中，平台团队往往需要重复处理相同问题：集群升级、控制面高可用、节点生命周期、权限配置、日志采集、监控接入和网络连通性。每增加一个团队或环境，这些工作就会成倍扩散。
共享服务架构的核心思路是把高复用、强治理属性的能力集中起来，例如：
- 身份与访问控制
- 日志、指标和审计数据采集
- 镜像仓库与制品管理
- DNS、网络连接和安全策略
- 集群基线、策略检查和合规控制
- 常用的入口、证书和服务发现能力
应用团队仍然可以在自己的 AWS 账号和 EKS 集群中部署服务，但不必为每个集群重新搭建一套基础平台。这样既保留了账号隔离，也避免了平台能力的重复建设。
这里的“共享”不等于“所有应用共用一个集群”。更合理的边界通常是：账号和集群负责业务隔离，共享服务账号或平台层负责统一能力，应用团队通过标准接口消费这些能力。
多账号 North Star 架构解决了什么问题
多账号架构的价值在于把隔离、治理和复用放到同一个设计里。一个可供实践参考的逻辑分层如下：
- 组织与治理层：通过 AWS Organizations、服务控制策略和账号基线约束风险边界。
- 共享服务层：集中提供日志、监控、镜像、网络、身份和安全相关能力。
- 平台集群层：为不同环境或业务域提供 EKS 集群，并执行统一的集群基线。
- 应用账号层：业务团队在授权范围内交付工作负载，使用统一的发布和观测入口。
这种设计降低了“平台团队必须直接管理所有应用”的耦合度。平台团队发布标准、策略和服务目录；应用团队按照约定接入，而不是通过人工工单申请每一个基础组件。
不过，集中化也有边界。如果所有共享服务都依赖单一账号、单一网络或单一平台团队，平台可能成为新的瓶颈。因此，实际落地时需要明确服务等级、故障域、数据隔离和灾备策略。能集中治理的能力集中治理，必须贴近应用的数据和高频变更则保留在业务侧。
4 倍部署速度背后的工程机制
部署速度提升通常不是某一个 Kubernetes 参数带来的，而是标准化和自动化共同作用的结果。共享服务架构可以让交付流程从“为每个环境临时搭建依赖”变成“从模板创建并复用平台能力”。
例如，团队可以把集群接入、命名空间、工作负载身份和基础观测配置固化为可审查的清单。下面是一个简化的示例，假设集群已经创建完成，并且当前身份拥有目标集群的访问权限。运行前请替换区域、集群名和 AWS 账号相关变量：
#!/usr/bin/env bash
set -euo pipefail
AWS_REGION="ap-southeast-1"
EKS_CLUSTER="platform-dev"
NAMESPACE="orders"
# 将当前终端切换到目标 EKS 集群的 kubeconfig 上下文
aws eks update-kubeconfig \\
--region "${AWS_REGION}" \\
--name "${EKS_CLUSTER}"
# 创建业务命名空间；生产环境建议由 GitOps 或 IaC 管理
kubectl create namespace "${NAMESPACE}" --dry-run=client -o yaml | kubectl apply -f -
# 为工作负载预留统一的标签，便于策略、成本和观测系统识别
kubectl label namespace "${NAMESPACE}" \\
platform.example.com/managed-by=shared-platform \\
platform.example.com/environment=dev \\
--overwrite
kubectl get namespace "${NAMESPACE}"
这段命令本身不是完整的平台方案，但体现了共享服务架构中的一个重要原则：接入步骤应该短、稳定、可重复。更完整的实现可以把它封装到 Terraform、CloudFormation、Backstage 模板或 GitOps 流程中，并在流水线中自动完成权限、网络、日志和策略校验。
一个适合团队落地的发布路径可以是：
应用代码提交
-> 自动测试与镜像构建
-> 镜像推送到统一制品仓库
-> 策略与安全检查
-> GitOps 更新目标环境
-> EKS 集群部署
-> 共享监控、日志与告警系统接收信号
流程越标准化，平台团队越少需要为单个应用编写特殊脚本，应用团队也越少需要等待人工操作。
如何避免共享平台变成新的单点瓶颈
共享服务不是“集中所有权力”，而是“集中重复能力”。落地时可以从以下几项开始：
- 定义服务目录：明确哪些能力由平台提供，输入是什么，输出是什么，服务等级如何衡量。
- 提供自助式入口：用模板、API 或 Git 仓库接口替代手工工单。
- 保留账号隔离：按环境、业务域或合规边界拆分账号，避免共享服务破坏故障和权限边界。
- 统一可观测性：共享日志和指标管道，但保留租户、账号、集群和命名空间维度，确保问题可以追溯到责任团队。
- 把策略写进流水线：在部署前检查镜像、权限、资源限制和网络暴露，而不是上线后再人工补救。
- 测量平台效果：除了部署次数，还应跟踪交付前置时间、变更失败率、恢复时间、集群升级耗时和平台工单量。
尤其要注意，统一标准不代表所有业务必须使用完全相同的运行时配置。共享平台应提供安全的默认值和清晰的扩展点，否则团队可能绕开平台，重新建设自己的“影子平台”。
采用建议：先统一重复劳动，再扩大共享范围
如果团队正在从自管理 Kubernetes 迁移到 Amazon EKS，可以按下面的顺序推进：
- 盘点当前每个集群重复维护的组件和人工步骤。
- 将日志、监控、身份、镜像和策略等横向能力列为候选共享服务。
- 设计 AWS 多账号边界，明确平台账号、共享服务账号和业务账号的职责。
- 先为一个非关键环境建立标准 EKS 基线和自助接入流程。
- 用部署速度、运维工单量和故障恢复时间验证收益。
- 在边界清晰、指标改善后，再扩展到更多业务域和生产环境。
Equinix 案例最值得借鉴的地方，不只是“使用 EKS”，而是通过多账号和共享服务重新组织平台能力。当治理、交付和运行边界被标准化后，团队才能在不持续增加运维人员的情况下扩大 Kubernetes 使用规模。代价是需要前期投入架构设计、自动化和服务目录建设；但对于拥有大量集群和业务团队的组织，这种投入往往比长期维护重复平台更可控。