使用 Amazon EKS 与 vCluster 优化 Kubernetes 测试环境配置

概述

在 Kubernetes 环境中，为开发、测试和 QA 工作快速、经济地创建隔离环境是一个常见的挑战。传统方法是为每个临时性需求创建独立的 Amazon EKS 集群，但这会带来高昂的成本、复杂的运维开销和漫长的配置时间。全球专业服务公司 Deloitte 面临此问题，他们通过结合 Amazon EKS 与 vCluster 技术，构建了一个基于共享主机集群的虚拟集群平台，从而将测试环境的配置时间从 45 分钟缩减至不到 5 分钟，实现了高达 89% 的效率提升。该方案为 SRE 实践提供了一种高效管理测试与预发布环境的范式，通过资源池化和自助服务显著提升了团队敏捷性。

核心概念

本方案的核心在于利用 vCluster 在单个 Kubernetes 主集群内创建多个轻量级、功能完整的虚拟集群。

vCluster: 它是一个开源项目，允许在现有 Kubernetes 集群（宿主集群）内部署完整的 Kubernetes 控制平面。每个 vCluster 就像一个独立的 Kubernetes 集群，拥有自己的 API 服务器、调度器等，但其工作负载最终由宿主集群调度。这提供了强大的隔离性（每个团队或项目都有自己的“集群”），同时共享宿主集群的计算、网络和存储资源，避免了为每个环境部署完整集群的开销。
Amazon EKS 主集群: 作为解决方案的基础层，它提供底层的计算、网络和存储资源。启用 Auto Mode 后，能动态扩展和缩减计算资源，进一步优化成本。
资源同步: vCluster 可以配置为从宿主集群同步资源（如 IngressClass、StorageClass）到虚拟集群，并将虚拟集群中的某些资源（如 Ingress）同步回宿主集群。这使得虚拟集群能够无缝使用宿主集群提供的基础设施服务，例如共享的应用负载均衡器（ALB）和持久卷存储。
共享控制平面服务: 关键的 Kubernetes 控制器（如 AWS Load Balancer Controller、存储控制器）仅在宿主集群部署一次，并为所有虚拟集群服务。这消除了每个环境重复部署这些组件的冗余，简化了运维。

实践

Deloitte 方案的部署是一个多阶段过程，旨在建立一个可供多个团队自助创建隔离测试环境的平台。以下流程概述了关键实施步骤。

1. 环境准备

在 Amazon EKS 主集群上进行基础配置：

网络与IAM: 确保 Amazon VPC、子网和必要的 IAM 角色（集群角色、节点角色）已就位。
存储与负载均衡类: 在宿主集群上配置默认的 StorageClass（使用 Amazon EBS CSI 驱动）和 IngressClass（使用 AWS Load Balancer Controller），为虚拟集群提供开箱即用的基础设施服务。
DNS与证书: 在 AWS Certificate Manager (ACM) 中为平台域名创建并验证 SSL/TLS 证书。

2. 部署 vCluster 平台

使用 Helm Chart 将 vCluster 平台部署到主集群。部署配置需指定：

资源限制: 为平台组件分配 CPU 和内存资源。
入口配置: 配置一个面向互联网的 Application Load Balancer (ALB)，并附加 ACM 证书，作为访问所有虚拟集群的统一入口点。
访问控制: 创建管理员账户。
亲和性: 建议将平台组件调度到由 Auto Mode 管理的节点上，以利用弹性伸缩。

3. 创建虚拟集群

平台部署完成后，用户（如 QA 工程师）可以通过 vCluster 提供的 Web 控制台自助操作：

登录平台控制台。
创建新的虚拟集群。创建时需应用特定的配置模板，以启用从宿主集群同步 IngressClass、StorageClass 以及从虚拟集群同步 Ingress 资源的功能。
等待虚拟集群状态变为健康。此过程通常在几分钟内完成，远快于创建新的 EKS 集群。

4. 部署与访问应用

在各自的虚拟集群中部署应用程序：

通过平台控制台下载特定虚拟集群的 kubeconfig 文件。
使用 kubectl 连接到该虚拟集群，并部署应用清单。清单应包含 Namespace、Deployment、Service、Ingress 和 PersistentVolumeClaim。
关键实践: 在 Ingress 资源的注解中，明确指定使用共享的 load-balancer-name（如 vcluster-alb），并定义基于路径的路由规则（如 /app1， /app2）。这样，来自同一域名不同路径的流量将被路由到不同虚拟集群中的应用，共享同一个 ALB。

5. 验证与清理

验证: 通过 ALB 的域名和不同的路径访问应用，确认所有虚拟集群中的应用均可通过单一入口点正常访问。检查 ALB 的监听器规则，确认为不同应用添加了正确的基于路径的规则。
清理: 当环境不再需要时，应卸载 vCluster Helm 发布，并删除相关的 Route53 DNS 记录和 ACM 证书，以避免产生不必要的费用。

SRE 要点

此方案从多个维度体现了 SRE 的核心原则：

与可靠性、可观测性、事件响应的关联

提升环境可靠性与一致性: 通过模板化创建虚拟集群，确保了测试环境的结构一致性，减少了因环境差异导致的“在我机器上能运行”类问题。每个虚拟集群的隔离性也防止了测试活动相互干扰。
简化可观测性: 所有虚拟集群共享宿主集群的监控基础设施（如日志、指标收集代理），SRE 团队只需在一个层面配置和监控核心平台健康状况，而无需为数十个独立集群重复配置。故障排查时，可以更清晰地定位问题是在平台层还是特定应用层。
加速事件响应: 快速创建和销毁环境的能力使得 SRE 和开发人员能够快速复现生产问题或测试修复补丁，缩短了事件响应和恢复时间。

最佳实践与常见反模式

最佳实践:
- 自助服务与赋能: 将环境创建能力下放给开发/QA团队，消除对平台团队的单点依赖，极大提升了组织敏捷性。
- 资源池化与共享: 通过共享核心组件（控制平面服务、负载均衡器）和底层资源，显著降低了总拥有成本（TCO）和运维复杂度。
- 基础设施即代码 (IaC): 所有配置（虚拟集群创建参数、应用部署清单）应版本化管理，确保可重复性和审计跟踪。
常见反模式:
- 过度隔离: 为每个微不足道的测试需求创建完全独立的集群，导致资源浪费和管理噩梦。vCluster 模式提供了“恰到好处”的隔离。
- 忽略平台治理: 虽然自助服务是好事，但仍需通过资源配额、命名空间规范等策略对虚拟集群的使用进行治理，避免资源争抢和成本失控。