[SoftServe]：在aws上部署的定制ci/cd解决方案帮助送餐服务转变微服务架构

客户背景与业务挑战

客户为美国领先的餐食配送服务公司，其微服务架构平台部分需与本地设备及软件通信。当前解决方案采用半手动部署的 AWS Kubernetes 集群，混合使用开源工具和 Terraform 配置。由于业务对可靠性要求严格，集群版本及其核心组件无法在运行时更新，存在更新失败导致集群丢失的风险，且其他限制阻碍了基础设施改进。项目启动时，客户失去了对基础设施历史、架构驱动因素和决策的深入了解的员工，导致生产事件频发，涉及特定开发团队处理。

Chef 编排工具配置存在严重问题，新实例（包括 Kubernetes 实例）仅一半能成功启动。此外，自定义 CI/CD 解决方案对应用交付施加了严格限制，难以实现非标准 CI 用例。尽管该 CI 工具质量良好，但阻碍了开发者对 Docker、Kubernetes 及相关开源工具的实际了解。为满足日益增长的内部开发和业务需求，客户需要更新 Kubernetes 集群部署架构并准备符合当前行业标准的灵活 CI/CD 解决方案。

项目描述与改进措施

项目包含多个部分，部分（如日志系统改进）提前进行。主要改进包括：

网络架构变更：在生产环境准备两个额外的网络段，为未来 Kubernetes 安装提供平滑、安全的迁移路径，支持架构实验且不影响所有用户。
采用 AWS EKS：选择云原生 Kubernetes 服务 AWS EKS，将集群核心组件维护责任转移给云提供商，并集成 AWS VPC 以提升网络性能。
配置代码化：EKS 安装的所有配置均以代码形式体现（Terraform 配置、CI/CD 作业、Helm 图或 YAML 配置），存储在源代码仓库中，确保透明度、灾难恢复能力，消除意外变更风险。
角色基础认证：配置基于现有 SAML 提供商与 IAM 角色结合的 Kubernetes RBAC 设置，提升集群整体安全性。
负载均衡改进：将旧集群的 Traefik Ingress 控制器替换为新设置的 ALB Ingress 控制器，提升可靠性和网络性能。
支持 gRPC 通信：新集群设置中包含 Linkerd 服务网格组件（第二代），确保服务间通信稳定透明。
替换遗留 CI 工具：采用基于 Helm 和 Jenkins 功能的新多功能解决方案，开发自定义 CI 库，实现灵活、透明、可重复、可扩展的 CI/CD，遵循“约定优于配置”原则，支持开发者自主实现非标准 CI/CD 流水线，并支持 CI/CD 进化而无需强制更新所有微服务。
改进节点引导过程：Chef 仍用于安装辅助工具、改进监控等，但配置错误不再阻止实例加入集群，显著缩短了添加新实例的时间。

迁移过程

迁移过程复杂，涉及约 150 个独立微服务分析、准备和转换。采用 Strangler 模式，将服务按公私关系分组，进行分批迁移。过程中密切合作，克服了各种障碍，最终在实时负载下完成迁移，请求中断最小。

价值交付

项目克服了实施中的“预期意外”，成功构建并部署了新环境，并替换了所有基于 Kubernetes 的项目的遗留 CI。客户团队获得了有效使用系统的知识。更新后的集群包含先进的架构堆栈，可升级、可靠、维护工作量少，且在所有方面均透明，大部分配置通过 Git 代码控制。集群工作节点数量减半，EC2 实例替换为更现代的预留实例以降低成本，每个节点资源利用率提升。迁移在实时负载下完成，请求中断极少。新 Chef 配置不再关键，可随时替换其他框架。密钥存储也已解耦，可按需替换。解决方案极其灵活，设计用于满足未来需求。