Karpenter E2E 测试体系全解析GitHub Actions 触发机制、AWS 环境搭建与测试套件架构【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-awsKarpenter 作为 Kubernetes 节点自动扩缩容器其正确性高度依赖真实 AWS 集群上的端到端验证。本文以 test/README.md 为骨架系统讲解 karpenter-provider-aws 仓库的 E2E 测试体系测试由什么事件触发、测试代码如何组织、如何在自己的 AWS 账户中搭建可运行 GitHub Actions E2E 的完整环境并结合仓库源码剖析测试基础设施的底层实现。读完本文你将掌握 Karpenter E2E 测试的触发方式、环境变量配置、CloudFormation 一键部署以及测试套件的扩展思路。E2E 测试的定位与触发机制Karpenter 的 E2E 测试不是简单的单元测试而是将真实 Karpenter 控制器部署到 AWS 上的真实 EKS 集群通过创建 NodePool、EC2NodeClass 并调度真实工作负载来验证整个节点生命周期行为。仓库通过 GitHub Actions 承载这些测试套件触发方式在 test/README.md 中明确列为三种周期性定时调度每 8 小时自动运行一次对应.github/workflows下的定时 workflowmain 分支新提交代码合入主干后立即触发回归验证维护者在 Pull Request 上评论/karpenter snapshot按需对特定 PR 的中间态代码运行测试保证合入前的可靠性。从 .github/workflows 目录看E2E 相关 workflow 全部以e2e-前缀命名如 e2e.yaml、e2e-matrix.yaml、e2e-upgrade.yaml 等并且存在独立的触发型 workflowe2e-*-trigger.yaml与执行型 workflowe2e-matrix.yaml等分离的设计便于跨仓库复用与编排。此外还配套了 snapshot.yaml、snapshot-pr.yaml 来处理快照构建与 PR 评论联动。下图展示了 GitHub Actions 的整体架构图片来源 test/assets/gha_architecture.png即原文档内嵌架构图测试仓库的目录结构test/README.md 对测试相关目录给出了清晰的划分结合仓库实际内容可以进一步精确到每个目录的作用目录职责.github/workflows仓库内的 workflow 文件E2E 相关文件以e2e-前缀命名.github/actions/e2eE2E workflow 复用的复合 Actioncomposite actions包括setup-cluster、install-karpenter、install-prometheus、run-tests-private-cluster、dump-logs、cleanup、upgrade-crds、slack等子目录test/cloudformation测试用 IAM Roles、Managed Prometheus Workspace、Managed Grafana Workspace 的 CloudFormation 模板test/suites定义各测试套件的目录每个子目录即一类场景test/pkg通用工具与期望校验common utilities and expectationstest/hack测试辅助脚本其中 test/pkg 内部又分为debug事件/监控调试工具与environmentcommon通用环境、awsAWS 环境两层test/hack/e2e_scripts 提供install_karpenter.sh、install_helm.sh、install_prometheus.sh、configure_private_cluster.sh、clean_private_cluster.sh、diff_karpenter.sh、noderole_bootstrap_permission.sh等脚本覆盖从集群准备到 Karpenter 安装再到私网集群处理的完整链路。在自己的 AWS 账户中启用 GitHub Actions E2E原文档给出了四步启用流程下面结合 test/cloudformation/README.md 与源码展开每一步的完整操作。第一步部署 CloudFormation 栈在目标 AWS 账户中依次部署 test/cloudformation 下的四个模板。1. 部署 Managed Prometheus 及其策略aws cloudformation deploy \ --stack-name GithubActionsManagedPrometheus \ --template-file prometheus_cloudformation.yaml \ --capabilities CAPABILITY_NAMED_IAM对应模板文件为 test/cloudformation/prometheus_cloudformation.yaml。该栈创建托管 Prometheus 工作区及供 GitHub Actions runner 访问的策略为后续的指标采集与断言提供存储后端。2. 部署 Timestreamaws cloudformation deploy \ --stack-name GithubActionsTimestream \ --template-file timestream_cloudformation.yaml \ --parameter-overrides DatabaseNamekarpenterTesting TableNamescaleTestDurations SweeperTableNamesweeperCleanedResources ResourceCountTableNameresourceCount对应模板 test/cloudformation/timestream_cloudformation.yaml。Timestream 用于持久化规模化测试scale test的耗时数据、sweeper 清理的资源计数以及资源计数统计参数中四个表名分别承载不同的时序数据。3.可选部署 Managed Grafana 及其策略aws cloudformation deploy \ --stack-name GithubActionsManagedGrafana \ --template-file grafana_cloudformation.yaml \ --parameter-overrides PrometheusWorkspaceIDworkspace-id \ --capabilities CAPABILITY_NAMED_IAM对应模板 test/cloudformation/grafana_cloudformation.yaml。需要把第一步得到的 Prometheus 工作区 ID 通过PrometheusWorkspaceID参数传入将托管 Grafana 与 Prometheus 打通。4. 部署 IAM 策略与 OIDC Provideraws cloudformation deploy --stack-name GithubActionsIAM \ --template-file iam_cloudformation.yaml \ --parameter-overrides DatabaseNamekarpenterTesting TableNamescaleTestDurations SweeperTableNamesweeperCleanedResources ResourceCountTableNameresourceCount Repositoryaws/karpenter-provider-aws Branches* PrometheusWorkspaceIDworkspace-id Regionsus-east-2,us-west-2,... \ --capabilities CAPABILITY_NAMED_IAM对应模板 test/cloudformation/iam_cloudformation.yaml。这是最关键的一步它部署 GitHub Actions runner 所需的 IAM 策略并创建 OIDC Provider 以支持 GitHub Actions 通过 OIDC 身份联邦换取临时 AWS 凭证。原文档特别强调如果要在自己的 fork 仓库中使用必须把Repository参数替换为你自己的仓库全限定名格式为organization/repo-name。该参数与Branches参数共同决定 OIDC Provider 信任哪些仓库、哪些分支签发的 token——这是保障安全性的核心配置务必按需收窄。第二步配置 GitHub Actions 环境变量在 fork 仓库的Settings/Secrets and Variables/Actions中配置以下环境变量Configuration variables而非 SecretsAWS_REGION: region ACCOUNT_ID: account-id ROLE_NAME: github-actions-role-name PROMETHEUS_REGION: managed-prometheus-hosted-region TIMESTREAM_REGION: timestream-hosted-region WORKSPACE_ID: managed-prometheus-workspace-id各变量含义AWS_REGION运行 EKS 集群与测试的主区域ACCOUNT_ID测试所用 AWS 账户 IDROLE_NAMEGitHub Actions 运行时扮演的 IAM 角色名由GithubActionsIAM栈创建PROMETHEUS_REGION托管 Prometheus 所在区域TIMESTREAM_REGIONTimestream 所在区域WORKSPACE_ID托管 Prometheus 工作区 ID。除上述文档列出的变量外从测试基础设施源码可以确认测试运行期还会读取一批环境变量CLUSTER_NAME与CLUSTER_ENDPOINT在 test/pkg/environment/aws/environment.go 中通过os.LookupEnv强制读取缺失即 panicINTERRUPTION_QUEUE用于初始化 SQS 中断队列 ProviderENABLE_ZONAL_SHIFTtrue时才会创建 Zonal Shift Provider见 test/pkg/environment/aws/environment.goENABLE_METRICS与METRICS_REGION控制是否向 Timestream 写入指标见 test/pkg/environment/aws/environment.goPRIVATE_CLUSTER存在时环境会切换为私网镜像地址见 test/pkg/environment/aws/environment.goGIT_REF则会注入测试 context 供结果标记使用见 test/pkg/environment/common/environment.go。第三步触发 workflow_dispatch配置完成后在你修改了 workflow 的分支上手动触发一次workflow_dispatch事件即可验证整条链路是否打通。此后可依赖定时调度或 PR 评论自动运行。第四步可选配置 Slack 通知如需将构建通知发布到自定义 Slack 频道可在 Actions 中新增SLACK_WEBHOOK_URLsecret指向你自己的 Slack Webhook 地址。对应实现位于 .github/actions/e2e/slack 下的复合 Action 中。测试基础设施的源码级剖析测试入口与 Ginkgo 生命周期每个测试套件都是一个标准的 Ginkgo 测试包。以集成测试套件为例test/suites/integration/suite_test.go 展示了统一的生命周期管理BeforeSuite中调用aws.NewEnvironment(t)创建完整测试环境AfterSuite中调用env.Stop()释放资源每个用例的BeforeEach会创建默认EC2NodeClass与默认NodePoolAfterEach依次执行env.Cleanup()与env.AfterEach()保证用例间环境隔离。通用环境common.Environmenttest/pkg/environment/common/environment.go 定义了通用测试环境结构包含 controller-runtime 的Client、RESTConfig、原生KubeClient以及Monitor。关键实现细节高 QPS 客户端NewConfig将 QPS 与 Burst 均设为1e6L92-L98避免大规模节点创建时客户端限流拖慢测试缓存索引NewClient为 Pod 的spec.nodeName、Event 的involvedObject.kind、Node 的spec.unschedulable与karpenter.sh/disruptedtaint 建立缓存索引L100-L131供测试断言高效查询宽松的等待超时gomega.SetDefaultEventuallyTimeout(16 * time.Minute)L76——考虑到真实 AWS 上节点从启动到就绪需要数分钟等待阈值必须足够宽裕默认 NodePoolDefaultNodePool构造一个限定 Linux、按需容量、c/m/r 系列且代数大于 4并排除与 AL2023 AMI 不兼容的 a1 系列的 NodePool关闭 consolidation设置 1000 CPU / 1000Gi 的资源上限L133-L175。AWS 环境aws.Environmenttest/pkg/environment/aws/environment.go 在通用环境之上叠加 AWS 能力持有 STS、EC2、SSM、IAM、FIS、EKS、ARC Zonal Shift、Timestream 等 SDK 客户端并缓存ZoneInfo区域内的可用区、AZ ID 与 AZ 类型来自DescribeAvailabilityZones。其DefaultEC2NodeClassL156-L178默认使用al2023latestAMI 别名、按karpenter.sh/discovery标签选择安全组与子网并区分私网集群使用 InstanceProfile与公网集群使用 Node Role两种配置。集群状态监控器Monitortest/pkg/environment/common/monitor.go 中的Monitor是断言的基础设施它在每个测试开始前Reset()记录当前节点集合测试过程中通过poll()周期性 List Nodes/PodsL168-L199并对外提供NodeCount/NodeCountAtReset/CreatedNodeCount/CreatedNodes/DeletedNodes精确量化测试期间节点的创建与删除PendingPods/RunningPods按 label selector 统计待调度与运行中的 PodRestartCount按命名空间汇总容器重启次数AvgUtilization/MinUtilization计算 Karpenter 管理节点上某资源的平均/最小利用率L201-L234用于 consolidation 等场景的期望校验。调试工具debug 包test/pkg/debug/setup.go 提供按 Ginkgo label 控制的调试能力默认情况下每个用例会启动Monitor实时 watch 集群状态、并收集集群事件若用例带有NoWatchlabel 则仅做一次性 List带有NoEventslabel 则跳过事件导出。AfterEach中会调用e.DumpEvents将事件转储便于失败时回溯。测试套件全景test/suites 下每个子目录代表一类端到端场景覆盖 Karpenter 的核心能力面套件验证主题integration综合集成场景含 AMI、实例 Profile、kubelet 配置、启动模板、网络接口、安全组、子网、标签、容量缓冲区、修复策略等见 integration 目录 下大量*_test.goscheduling、scheduling-strict、scheduling-besteffort调度语义、严格调度与尽力而为调度consolidation节点合并/缩容行为drift漂移检测与替换interruption中断处理Spot 中断、健康事件等nodeclaimNodeClaim 生命周期ipv6、localzone、storage、ami网络协议、边缘可用区、存储、AMI 专项scale规模化扩缩容provisioning_test.go 与 deprovisioning_test.go耗时数据写入 Timestream此外 .github/workflows 中还存在e2e-soak-trigger.yamlsoak 浸泡测试长期运行观察稳定性、e2e-version-compatibility-trigger.yaml版本兼容矩阵、e2e-upgrade.yaml升级路径与e2e-private-cluster-trigger.yaml私网集群等专项流水线配合 test/hack/soak 下的 soak 工具使用。用 Helm 在测试集群中安装 Karpentertest/hack/e2e_scripts/install_karpenter.sh 展示了 E2E 测试中 Karpenter 的实际安装方式也是理解测试部署形态的最佳样例。脚本核心是一条helm upgrade --install命令helm upgrade --install karpenter ${CHART} \ -n kube-system \ --version 0-$(git rev-parse HEAD) \ --set logLeveldebug \ --set settings.isolatedVPC${PRIVATE_CLUSTER} \ --set settings.clusterName$CLUSTER_NAME \ --set settings.interruptionQueue$CLUSTER_NAME \ --set settings.enableZonalShifttrue \ --set settings.featureGates.spotToSpotConsolidationtrue \ --set settings.featureGates.nodeRepairtrue \ --set settings.featureGates.reservedCapacitytrue \ --set settings.featureGates.nodeOverlaytrue \ --set settings.featureGates.staticCapacitytrue \ --set settings.featureGates.capacityBuffertrue \ --set settings.awsFeatureGates.nodeClassCELtrue \ --set controller.resources.requests.cpu5 \ --set controller.resources.requests.memory3Gi \ --set controller.resources.limits.cpu5 \ --set controller.resources.limits.memory3Gi \ --set serviceMonitor.enabledtrue \ --wait值得注意的细节Chart 来源默认从oci://$ECR_ACCOUNT_ID.dkr.ecr.$ECR_REGION.amazonaws.com/karpenter/snapshot/karpenter拉取由 CI 构建的 snapshot 镜像私网集群PRIVATE_CLUSTERtrue时切换为本账户 ECR并额外通过ADDITIONAL_FLAGS覆写 controller 与 postInstallHook 的镜像仓库与 digestL5-L8版本串--version 0-$(git rev-parse HEAD)将 git commit 直接作为 chart 版本保证测试镜像与源码一一对应功能开关全开一次性开启spotToSpotConsolidation、nodeRepair、reservedCapacity、nodeOverlay、staticCapacity、capacityBuffer等 feature gates以及nodeClassCELAWS 功能开关使测试覆盖最新的实验性能力观测注入启用 ServiceMonitor并通过relabelings把clusterName、gitRef、mostRecentTag、commitsAfterTag等标签写入抓取指标L31-L40让 Prometheus 中的指标可关联到具体的集群与代码版本资源保障controller 请求与限制均为 5 CPU / 3Gi 内存配合--wait等待部署就绪后再执行测试。对应的 helm 安装脚本 test/hack/e2e_scripts/install_helm.sh 通过官方 get-helm-3 脚本按$HELM_VERSION安装指定版本 HelmPrometheus 的部署则由 install_prometheus.sh 与 .github/actions/e2e/install-prometheus 复合 Action 完成。编写与扩展 E2E 测试的要点从源码结构可以总结出新增一个测试套件的惯用模式在 test/suites 下新建目录编写suite_test.go仿照 test/suites/integration/suite_test.go 注册 Ginkgo 生命周期在BeforeEach中通过env.DefaultEC2NodeClass()与env.DefaultNodePool(nodeClass)获取基线对象再按场景修改利用env.Monitor的CreatedNodes/PendingPods等 API 做行为断言并借助gomega的Eventually配合 16 分钟默认超时等待真实集群收敛若需要记录规模化指标通过 Timestream API 写入由 test/pkg/environment/aws 封装新套件如需接入 CI在 .github/workflows 中补充e2e-*workflow 或在现有矩阵 workflow 中登记。小结Karpenter 的 E2E 测试体系是一套面向真实 AWS 集群的完整工程质量保障设施GitHub Actions 提供三种触发入口8 小时定时、main 提交、/karpenter snapshotPR 评论CloudFormation 模板一键供给 Prometheus/Grafana/Timestream/IAM/OIDC 等依赖test/pkg提供高并发客户端、集群状态监控与调试工具test/suites覆盖调度、合并、漂移、中断、扩容等核心场景。无论是为 Karpenter 贡献代码还是 fork 后定制验证自己的改动本文梳理的目录结构、环境变量与部署命令都是你接入这套测试体系的最短路径。【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Karpenter E2E 测试体系全解析：GitHub Actions 触发机制、AWS 环境搭建与测试套件架构
Karpenter E2E 测试体系全解析GitHub Actions 触发机制、AWS 环境搭建与测试套件架构【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-awsKarpenter 作为 Kubernetes 节点自动扩缩容器其正确性高度依赖真实 AWS 集群上的端到端验证。本文以 test/README.md 为骨架系统讲解 karpenter-provider-aws 仓库的 E2E 测试体系测试由什么事件触发、测试代码如何组织、如何在自己的 AWS 账户中搭建可运行 GitHub Actions E2E 的完整环境并结合仓库源码剖析测试基础设施的底层实现。读完本文你将掌握 Karpenter E2E 测试的触发方式、环境变量配置、CloudFormation 一键部署以及测试套件的扩展思路。E2E 测试的定位与触发机制Karpenter 的 E2E 测试不是简单的单元测试而是将真实 Karpenter 控制器部署到 AWS 上的真实 EKS 集群通过创建 NodePool、EC2NodeClass 并调度真实工作负载来验证整个节点生命周期行为。仓库通过 GitHub Actions 承载这些测试套件触发方式在 test/README.md 中明确列为三种周期性定时调度每 8 小时自动运行一次对应.github/workflows下的定时 workflowmain 分支新提交代码合入主干后立即触发回归验证维护者在 Pull Request 上评论/karpenter snapshot按需对特定 PR 的中间态代码运行测试保证合入前的可靠性。从 .github/workflows 目录看E2E 相关 workflow 全部以e2e-前缀命名如 e2e.yaml、e2e-matrix.yaml、e2e-upgrade.yaml 等并且存在独立的触发型 workflowe2e-*-trigger.yaml与执行型 workflowe2e-matrix.yaml等分离的设计便于跨仓库复用与编排。此外还配套了 snapshot.yaml、snapshot-pr.yaml 来处理快照构建与 PR 评论联动。下图展示了 GitHub Actions 的整体架构图片来源 test/assets/gha_architecture.png即原文档内嵌架构图测试仓库的目录结构test/README.md 对测试相关目录给出了清晰的划分结合仓库实际内容可以进一步精确到每个目录的作用目录职责.github/workflows仓库内的 workflow 文件E2E 相关文件以e2e-前缀命名.github/actions/e2eE2E workflow 复用的复合 Actioncomposite actions包括setup-cluster、install-karpenter、install-prometheus、run-tests-private-cluster、dump-logs、cleanup、upgrade-crds、slack等子目录test/cloudformation测试用 IAM Roles、Managed Prometheus Workspace、Managed Grafana Workspace 的 CloudFormation 模板test/suites定义各测试套件的目录每个子目录即一类场景test/pkg通用工具与期望校验common utilities and expectationstest/hack测试辅助脚本其中 test/pkg 内部又分为debug事件/监控调试工具与environmentcommon通用环境、awsAWS 环境两层test/hack/e2e_scripts 提供install_karpenter.sh、install_helm.sh、install_prometheus.sh、configure_private_cluster.sh、clean_private_cluster.sh、diff_karpenter.sh、noderole_bootstrap_permission.sh等脚本覆盖从集群准备到 Karpenter 安装再到私网集群处理的完整链路。在自己的 AWS 账户中启用 GitHub Actions E2E原文档给出了四步启用流程下面结合 test/cloudformation/README.md 与源码展开每一步的完整操作。第一步部署 CloudFormation 栈在目标 AWS 账户中依次部署 test/cloudformation 下的四个模板。1. 部署 Managed Prometheus 及其策略aws cloudformation deploy \ --stack-name GithubActionsManagedPrometheus \ --template-file prometheus_cloudformation.yaml \ --capabilities CAPABILITY_NAMED_IAM对应模板文件为 test/cloudformation/prometheus_cloudformation.yaml。该栈创建托管 Prometheus 工作区及供 GitHub Actions runner 访问的策略为后续的指标采集与断言提供存储后端。2. 部署 Timestreamaws cloudformation deploy \ --stack-name GithubActionsTimestream \ --template-file timestream_cloudformation.yaml \ --parameter-overrides DatabaseNamekarpenterTesting TableNamescaleTestDurations SweeperTableNamesweeperCleanedResources ResourceCountTableNameresourceCount对应模板 test/cloudformation/timestream_cloudformation.yaml。Timestream 用于持久化规模化测试scale test的耗时数据、sweeper 清理的资源计数以及资源计数统计参数中四个表名分别承载不同的时序数据。3.可选部署 Managed Grafana 及其策略aws cloudformation deploy \ --stack-name GithubActionsManagedGrafana \ --template-file grafana_cloudformation.yaml \ --parameter-overrides PrometheusWorkspaceIDworkspace-id \ --capabilities CAPABILITY_NAMED_IAM对应模板 test/cloudformation/grafana_cloudformation.yaml。需要把第一步得到的 Prometheus 工作区 ID 通过PrometheusWorkspaceID参数传入将托管 Grafana 与 Prometheus 打通。4. 部署 IAM 策略与 OIDC Provideraws cloudformation deploy --stack-name GithubActionsIAM \ --template-file iam_cloudformation.yaml \ --parameter-overrides DatabaseNamekarpenterTesting TableNamescaleTestDurations SweeperTableNamesweeperCleanedResources ResourceCountTableNameresourceCount Repositoryaws/karpenter-provider-aws Branches* PrometheusWorkspaceIDworkspace-id Regionsus-east-2,us-west-2,... \ --capabilities CAPABILITY_NAMED_IAM对应模板 test/cloudformation/iam_cloudformation.yaml。这是最关键的一步它部署 GitHub Actions runner 所需的 IAM 策略并创建 OIDC Provider 以支持 GitHub Actions 通过 OIDC 身份联邦换取临时 AWS 凭证。原文档特别强调如果要在自己的 fork 仓库中使用必须把Repository参数替换为你自己的仓库全限定名格式为organization/repo-name。该参数与Branches参数共同决定 OIDC Provider 信任哪些仓库、哪些分支签发的 token——这是保障安全性的核心配置务必按需收窄。第二步配置 GitHub Actions 环境变量在 fork 仓库的Settings/Secrets and Variables/Actions中配置以下环境变量Configuration variables而非 SecretsAWS_REGION: region ACCOUNT_ID: account-id ROLE_NAME: github-actions-role-name PROMETHEUS_REGION: managed-prometheus-hosted-region TIMESTREAM_REGION: timestream-hosted-region WORKSPACE_ID: managed-prometheus-workspace-id各变量含义AWS_REGION运行 EKS 集群与测试的主区域ACCOUNT_ID测试所用 AWS 账户 IDROLE_NAMEGitHub Actions 运行时扮演的 IAM 角色名由GithubActionsIAM栈创建PROMETHEUS_REGION托管 Prometheus 所在区域TIMESTREAM_REGIONTimestream 所在区域WORKSPACE_ID托管 Prometheus 工作区 ID。除上述文档列出的变量外从测试基础设施源码可以确认测试运行期还会读取一批环境变量CLUSTER_NAME与CLUSTER_ENDPOINT在 test/pkg/environment/aws/environment.go 中通过os.LookupEnv强制读取缺失即 panicINTERRUPTION_QUEUE用于初始化 SQS 中断队列 ProviderENABLE_ZONAL_SHIFTtrue时才会创建 Zonal Shift Provider见 test/pkg/environment/aws/environment.goENABLE_METRICS与METRICS_REGION控制是否向 Timestream 写入指标见 test/pkg/environment/aws/environment.goPRIVATE_CLUSTER存在时环境会切换为私网镜像地址见 test/pkg/environment/aws/environment.goGIT_REF则会注入测试 context 供结果标记使用见 test/pkg/environment/common/environment.go。第三步触发 workflow_dispatch配置完成后在你修改了 workflow 的分支上手动触发一次workflow_dispatch事件即可验证整条链路是否打通。此后可依赖定时调度或 PR 评论自动运行。第四步可选配置 Slack 通知如需将构建通知发布到自定义 Slack 频道可在 Actions 中新增SLACK_WEBHOOK_URLsecret指向你自己的 Slack Webhook 地址。对应实现位于 .github/actions/e2e/slack 下的复合 Action 中。测试基础设施的源码级剖析测试入口与 Ginkgo 生命周期每个测试套件都是一个标准的 Ginkgo 测试包。以集成测试套件为例test/suites/integration/suite_test.go 展示了统一的生命周期管理BeforeSuite中调用aws.NewEnvironment(t)创建完整测试环境AfterSuite中调用env.Stop()释放资源每个用例的BeforeEach会创建默认EC2NodeClass与默认NodePoolAfterEach依次执行env.Cleanup()与env.AfterEach()保证用例间环境隔离。通用环境common.Environmenttest/pkg/environment/common/environment.go 定义了通用测试环境结构包含 controller-runtime 的Client、RESTConfig、原生KubeClient以及Monitor。关键实现细节高 QPS 客户端NewConfig将 QPS 与 Burst 均设为1e6L92-L98避免大规模节点创建时客户端限流拖慢测试缓存索引NewClient为 Pod 的spec.nodeName、Event 的involvedObject.kind、Node 的spec.unschedulable与karpenter.sh/disruptedtaint 建立缓存索引L100-L131供测试断言高效查询宽松的等待超时gomega.SetDefaultEventuallyTimeout(16 * time.Minute)L76——考虑到真实 AWS 上节点从启动到就绪需要数分钟等待阈值必须足够宽裕默认 NodePoolDefaultNodePool构造一个限定 Linux、按需容量、c/m/r 系列且代数大于 4并排除与 AL2023 AMI 不兼容的 a1 系列的 NodePool关闭 consolidation设置 1000 CPU / 1000Gi 的资源上限L133-L175。AWS 环境aws.Environmenttest/pkg/environment/aws/environment.go 在通用环境之上叠加 AWS 能力持有 STS、EC2、SSM、IAM、FIS、EKS、ARC Zonal Shift、Timestream 等 SDK 客户端并缓存ZoneInfo区域内的可用区、AZ ID 与 AZ 类型来自DescribeAvailabilityZones。其DefaultEC2NodeClassL156-L178默认使用al2023latestAMI 别名、按karpenter.sh/discovery标签选择安全组与子网并区分私网集群使用 InstanceProfile与公网集群使用 Node Role两种配置。集群状态监控器Monitortest/pkg/environment/common/monitor.go 中的Monitor是断言的基础设施它在每个测试开始前Reset()记录当前节点集合测试过程中通过poll()周期性 List Nodes/PodsL168-L199并对外提供NodeCount/NodeCountAtReset/CreatedNodeCount/CreatedNodes/DeletedNodes精确量化测试期间节点的创建与删除PendingPods/RunningPods按 label selector 统计待调度与运行中的 PodRestartCount按命名空间汇总容器重启次数AvgUtilization/MinUtilization计算 Karpenter 管理节点上某资源的平均/最小利用率L201-L234用于 consolidation 等场景的期望校验。调试工具debug 包test/pkg/debug/setup.go 提供按 Ginkgo label 控制的调试能力默认情况下每个用例会启动Monitor实时 watch 集群状态、并收集集群事件若用例带有NoWatchlabel 则仅做一次性 List带有NoEventslabel 则跳过事件导出。AfterEach中会调用e.DumpEvents将事件转储便于失败时回溯。测试套件全景test/suites 下每个子目录代表一类端到端场景覆盖 Karpenter 的核心能力面套件验证主题integration综合集成场景含 AMI、实例 Profile、kubelet 配置、启动模板、网络接口、安全组、子网、标签、容量缓冲区、修复策略等见 integration 目录 下大量*_test.goscheduling、scheduling-strict、scheduling-besteffort调度语义、严格调度与尽力而为调度consolidation节点合并/缩容行为drift漂移检测与替换interruption中断处理Spot 中断、健康事件等nodeclaimNodeClaim 生命周期ipv6、localzone、storage、ami网络协议、边缘可用区、存储、AMI 专项scale规模化扩缩容provisioning_test.go 与 deprovisioning_test.go耗时数据写入 Timestream此外 .github/workflows 中还存在e2e-soak-trigger.yamlsoak 浸泡测试长期运行观察稳定性、e2e-version-compatibility-trigger.yaml版本兼容矩阵、e2e-upgrade.yaml升级路径与e2e-private-cluster-trigger.yaml私网集群等专项流水线配合 test/hack/soak 下的 soak 工具使用。用 Helm 在测试集群中安装 Karpentertest/hack/e2e_scripts/install_karpenter.sh 展示了 E2E 测试中 Karpenter 的实际安装方式也是理解测试部署形态的最佳样例。脚本核心是一条helm upgrade --install命令helm upgrade --install karpenter ${CHART} \ -n kube-system \ --version 0-$(git rev-parse HEAD) \ --set logLeveldebug \ --set settings.isolatedVPC${PRIVATE_CLUSTER} \ --set settings.clusterName$CLUSTER_NAME \ --set settings.interruptionQueue$CLUSTER_NAME \ --set settings.enableZonalShifttrue \ --set settings.featureGates.spotToSpotConsolidationtrue \ --set settings.featureGates.nodeRepairtrue \ --set settings.featureGates.reservedCapacitytrue \ --set settings.featureGates.nodeOverlaytrue \ --set settings.featureGates.staticCapacitytrue \ --set settings.featureGates.capacityBuffertrue \ --set settings.awsFeatureGates.nodeClassCELtrue \ --set controller.resources.requests.cpu5 \ --set controller.resources.requests.memory3Gi \ --set controller.resources.limits.cpu5 \ --set controller.resources.limits.memory3Gi \ --set serviceMonitor.enabledtrue \ --wait值得注意的细节Chart 来源默认从oci://$ECR_ACCOUNT_ID.dkr.ecr.$ECR_REGION.amazonaws.com/karpenter/snapshot/karpenter拉取由 CI 构建的 snapshot 镜像私网集群PRIVATE_CLUSTERtrue时切换为本账户 ECR并额外通过ADDITIONAL_FLAGS覆写 controller 与 postInstallHook 的镜像仓库与 digestL5-L8版本串--version 0-$(git rev-parse HEAD)将 git commit 直接作为 chart 版本保证测试镜像与源码一一对应功能开关全开一次性开启spotToSpotConsolidation、nodeRepair、reservedCapacity、nodeOverlay、staticCapacity、capacityBuffer等 feature gates以及nodeClassCELAWS 功能开关使测试覆盖最新的实验性能力观测注入启用 ServiceMonitor并通过relabelings把clusterName、gitRef、mostRecentTag、commitsAfterTag等标签写入抓取指标L31-L40让 Prometheus 中的指标可关联到具体的集群与代码版本资源保障controller 请求与限制均为 5 CPU / 3Gi 内存配合--wait等待部署就绪后再执行测试。对应的 helm 安装脚本 test/hack/e2e_scripts/install_helm.sh 通过官方 get-helm-3 脚本按$HELM_VERSION安装指定版本 HelmPrometheus 的部署则由 install_prometheus.sh 与 .github/actions/e2e/install-prometheus 复合 Action 完成。编写与扩展 E2E 测试的要点从源码结构可以总结出新增一个测试套件的惯用模式在 test/suites 下新建目录编写suite_test.go仿照 test/suites/integration/suite_test.go 注册 Ginkgo 生命周期在BeforeEach中通过env.DefaultEC2NodeClass()与env.DefaultNodePool(nodeClass)获取基线对象再按场景修改利用env.Monitor的CreatedNodes/PendingPods等 API 做行为断言并借助gomega的Eventually配合 16 分钟默认超时等待真实集群收敛若需要记录规模化指标通过 Timestream API 写入由 test/pkg/environment/aws 封装新套件如需接入 CI在 .github/workflows 中补充e2e-*workflow 或在现有矩阵 workflow 中登记。小结Karpenter 的 E2E 测试体系是一套面向真实 AWS 集群的完整工程质量保障设施GitHub Actions 提供三种触发入口8 小时定时、main 提交、/karpenter snapshotPR 评论CloudFormation 模板一键供给 Prometheus/Grafana/Timestream/IAM/OIDC 等依赖test/pkg提供高并发客户端、集群状态监控与调试工具test/suites覆盖调度、合并、漂移、中断、扩容等核心场景。无论是为 Karpenter 贡献代码还是 fork 后定制验证自己的改动本文梳理的目录结构、环境变量与部署命令都是你接入这套测试体系的最短路径。【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考