云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载Prometheus Operator 的端到端E2E测试是一套以 Go test 形式编写、在真实 Kubernetes 集群上运行的自动化测试用于验证 Operator 在真实用户场景下的完整行为。本指南将围绕 test/e2e/README.md 的核心说明结合仓库中的测试框架源码与 Makefile 构建目标系统讲解 E2E 测试的前置条件、构建与运行方式、测试套件的组织与筛选、镜像准备以及失败诊断方法帮助你从零开始在本机复现并调试这套与 CI 完全一致的测试体系。E2E 测试是什么端到端End-to-endE2E测试是面向真实用户场景的自动化测试。与单元测试在隔离环境下验证单个函数不同E2E 测试会启动一个真实的 Kubernetes 集群在其中部署 Prometheus Operator、CRD、Prometheus/Alertmanager/ThanosRuler 等资源并验证从用户提交 CR 资源到Operator 完成协调并产生预期效果的完整链路。在 Prometheus Operator 仓库中E2E 测试与单元测试、长时测试共同构成完整的测试矩阵这一点在 TESTING.md 中有明确说明单元测试在隔离环境下测试特定代码片段反馈循环最快长时测试long tests包含耗时更长的单元测试用例E2E 测试在真实 Kubernetes 集群中验证 Operator 的整体行为也是 Pull Request 流水线中运行的那套测试。从 Makefile 可以看到三者可通过make test一键串联执行.PHONY: test test: test-unit test-long test-e2e ## Run all tests (unit, long, and e2e).运行 E2E 测试的前置条件根据 test/e2e/README.md运行 E2E 测试需要满足三个前置条件一个正在运行的 Kubernetes 集群以及对应的 kubeconfig测试时需要把 kubeconfig 作为参数传入kubeconfig 文件就绪测试框架需要通过它连接集群的 API ServerPrometheus Operator 镜像就绪用于在集群内拉起 Operator 的 Deployment。E2E 测试本身是标准的 Go test 程序因此 Go 测试的所有技术手段例如选择运行哪些用例、控制超时时长都同样适用。最简单的运行方式是直接调用go test$ go test -v ./test/e2e/ --kubeconfig $HOME/.kube/config --operator-imagequay.io/prometheus-operator/prometheus-operator其中--kubeconfig指定 kubeconfig 文件的路径--operator-image指定要部署到集群中的 Operator 镜像-v输出每个测试用例的详细运行结果。这两个自定义 flag 是在 test/e2e/main_test.go 的TestMain中通过标准库flag包注册的这也是E2E 测试是标准 Go test这一说法的源码依据func TestMain(m *testing.M) { kubeconfig : flag.String( kubeconfig, , kube config path, e.g. $HOME/.kube/config, ) opImage flag.String( operator-image, , operator image, e.g. quay.io/prometheus-operator/prometheus-operator, ) flag.Parse() // ... }需要说明的是直接运行go test时 Operator 镜像是已存在的可以是本地构建并导入 kind 的镜像也可以是远程仓库中的镜像。测试框架会把该镜像写入 Operator 的 Deployment 清单中具体逻辑见下文测试框架如何拉起 Operator一节。推荐实践通过 Makefile 运行 E2E 测试虽然go test命令可以直接运行但仓库在 Makefile 中封装了更完整的test-e2e目标它会自动处理 kubeconfig 默认值、instrumented-sample-app 证书生成、镜像 tag 拼接等细节.PHONY: test-e2e test-e2e: KUBECONFIG?$(HOME)/.kube/config test-e2e: test/instrumented-sample-app/certs/cert.pem test/instrumented-sample-app/certs/key.pem ## Run end-to-end tests. go test -timeout 120m -v ./test/e2e/ $(TEST_RUN_ARGS) --kubeconfig$(KUBECONFIG) --operator-image$(IMAGE_OPERATOR):$(TAG) -count1该目标的几个关键点KUBECONFIG默认取$(HOME)/.kube/config可通过环境变量覆盖依赖test/instrumented-sample-app/certs/下的证书缺失时会通过 test/instrumented-sample-app/Makefile 的generate-certs目标自动生成测试整体超时上限为120 分钟-timeout 120m-count1禁用 Go 测试缓存确保每次都是真实执行$(IMAGE_OPERATOR):$(TAG)中的镜像仓库默认为quay.io/prometheus-operator/prometheus-operatorTAG默认为当前 git 短提交哈希见 Makefile预留了TEST_RUN_ARGS变量可向go test追加参数例如只运行某个测试见下文。也就是说最直接的运行方式就是make test-e2emake test-e2e会运行完整的 E2E 测试套件与 Pull Request 流水线中执行的测试完全一致确保所有控制器的功能需求都得到验证。分控制器运行按需裁剪测试范围完整测试套件运行时间很长即使在高配笔记本上也需要几十分钟甚至更久而一次改动通常只会影响某一个控制器。为此Makefile 提供了多个按控制器裁剪的目标其实现原理是通过设置排除类环境变量来跳过不相关的测试套件MakefileMakefile 目标运行内容等价环境变量组合其余 EXCLUDE 变量设为非空make test-e2e-alertmanager仅 Alertmanager 相关测试EXCLUDE_ALERTMANAGER_TESTS不排除其他全排除make test-e2e-prometheusPrometheus 测试有限命名空间权限场景EXCLUDE_PROMETHEUS_TESTS不排除make test-e2e-prometheus-all-namespaces常规 Prometheus 测试全命名空间EXCLUDE_PROMETHEUS_ALL_NS_TESTS不排除make test-e2e-thanos-rulerThanosRuler 相关测试EXCLUDE_THANOSRULER_TESTS不排除make test-e2e-operator-upgrade验证由上一版本 Operator 管理的监控栈升级到当前版本后仍正常EXCLUDE_OPERATOR_UPGRADE_TESTS不排除make test-e2e-prometheus-upgrade验证兼容矩阵内一系列 Prometheus 版本可依次升级EXCLUDE_PROMETHEUS_UPGRADE_TESTS不排除make test-e2e-feature-gates验证处于 feature gate 之后的特性EXCLUDE_FEATURE_GATED_TESTS不排除这些排除变量的作用在 test/e2e/main_test.go 中实现例如func skipPrometheusAllNSTests(t *testing.T) { if os.Getenv(EXCLUDE_PROMETHEUS_ALL_NS_TESTS) ! { t.Skip(Skipping Prometheus all namespace tests) } }当对应环境变量非空时相关测试套件会被t.Skip跳过。CI 中始终运行全部测试但本地开发时通过跳过无关套件可以显著缩短反馈循环。只运行单个测试如果正在调试某个具体用例可以结合TEST_RUN_ARGS与 Go 的-run参数精确锁定目标。例如只运行TestPrometheusRuleCRDValidation/valid-rule-names子测试TEST_RUN_ARGS-run TestPrometheusRuleCRDValidation/valid-rule-names make test-e2e-prometheusTEST_RUN_ARGS会被拼接到go test命令中配合-run正则即可只执行匹配的测试函数。搭建本地测试集群与准备镜像推荐使用 KindE2E 测试需要在真实集群上运行官方推荐使用 KinDKubernetes in Docker它足够轻量能在小型笔记本上运行同时也是项目 CI 使用的集群方案。Minikube 也是可选方案。仓库在 test/e2e/kind-conf.yaml 中提供了 CI 所用的集群配置包含两个关键设计kubelet 同步频率降为 10 秒将 kubelet 同步挂载的 ConfigMap 与 Secret 的间隔从默认 1 分钟降到 10 秒加速配置变更在容器中的传播从而加快测试速度worker 节点打上可用区标签两个 worker 分别标记为topology.kubernetes.io/zone: zone-a与zone-b用于拓扑感知分片topology sharding类测试。使用该配置创建集群kind create cluster --config test/e2e/kind-conf.yaml构建镜像并加载到集群在运行自动化 E2E 测试之前需要先构建镜像并把它们加载进本地集群。使用 Docker 时执行KIND_CONTEXTe2e make test-e2e-imagestest-e2e-images目标Makefile会依次构建三个镜像并通过kind load加载进名为e2e的 kind 集群prometheus-operatorDockerfileprometheus-config-reloadercmd/prometheus-config-reloader/Dockerfileadmission-webhookcmd/admission-webhook/DockerfileKIND_CONTEXT的默认值就是e2eMakefile因此如果集群名不是e2e需要显式覆盖。使用 podman 的注意事项在 macOS 上使用 podman 运行 kind 时建议用4个 CPU 和8 GiB内存创建 podman machine资源不足会导致 E2E 测试因集群资源匮乏而失败podman machine init --cpus4 --memory8192 --rootful --now随后用 podman 构建并加载镜像CONTAINER_CLIpodman KIND_CONTEXTe2e make test-e2e-images设置CONTAINER_CLIpodman后Makefile 会改用podman save导出镜像归档再用kind load image-archive加载。测试套件的组织与测试入口顶层测试函数一览test/e2e/main_test.go 是 E2E 测试的入口文件其中定义了多个顶层测试函数每个函数对应一类测试场景顶层测试函数验证场景源码位置TestAllNSOperator 监听全部命名空间含 Alertmanager、Prometheus、ThanosRuler、多 Operator 并存main_test.go#L168-L225TestMultiNSOperator 只监听指定命名空间main_test.go#L360-L369TestDenylistOperator 配置了拒绝监听的命名空间main_test.go#L372-L383TestPromInstanceNs设置--prometheus-instance-namespace时的多场景行为main_test.go#L386-L401TestRepairPolicyOperator 能修复损坏的 StatefulSetmain_test.go#L404-L413TestAlertmanagerInstanceNs设置--alertmanager-instance-namespace时的多场景行为main_test.go#L416-L427TestOperatorUpgrade从上一稳定小版本升级 Operator 后监控栈仍正常main_test.go#L430-L440TestGatedFeaturesfeature gate 之后的特性DaemonSet Agent、status 子资源、拓扑分片等main_test.go#L447-L487TestPrometheusVersionUpgrade兼容矩阵中各 Prometheus 版本可依次升级main_test.go#L490-L506其中TestAllNS内部的 Prometheus 套件覆盖了非常广泛的场景从 main_test.go#L264-L335 可以看到包括但不限于CRD 校验、RemoteWrite 与 TLS、集群创建/删除/扩缩容、ServiceMonitor/PodMonitor 选择、Sharding/Resharding、Thanos 集成、UTF-8 指标与标签支持、状态条件Degraded/Unavailable等。TestMain测试的初始化与升级测试基础TestMain 除了注册 flag还做了两件关键的事情读取../../VERSION确定当前版本并计算出上一稳定小版本与下一小版本当前开发目标版本。VERSION文件当前内容为0.94.0见 VERSION。初始化两套测试框架previousVersionFramework使用上一稳定版本如v0.93.x的 Operator 镜像与示例资源目录服务于 Operator 升级测试framework使用传入的--operator-image与当前仓库的example/目录、test/framework/resources/目录服务于常规测试。这也解释了升级类测试的运作方式它们会先用旧版本 Operator 部署并管理一套监控栈再升级到当前版本验证旧资源在升级后依旧被正确协调。测试框架如何工作Framework 对象与客户端初始化E2E 测试的底层能力由 test/framework 包提供。Framework结构体framework.go#L66-L81聚合了与 Kubernetes 交互所需的全部客户端KubeClient标准 Kubernetes clientMonClientV1/MonClientV1alpha1/MonClientV1beta1monitoring 组 v1 / v1alpha1 / v1beta1 三个 API 版本的客户端对应pkg/apis/monitoring下的 CRD 类型APIServerClientAPI 扩展客户端用于操作 CRD 本身HTTPClient复用 API Server 的 HTTP 客户端MasterHost、RestConfigAPI Server 地址与 REST 配置。New()framework.go#L84-L143通过clientcmd.BuildConfigFromFlags(, kubeconfig)从 kubeconfig 构建连接配置创建上述所有客户端并校验集群至少存在一个节点否则直接报错。拉起 OperatorCreateOrUpdatePrometheusOperatorWithOpts每个测试在运行前都会通过CreateOrUpdatePrometheusOperatorWithOptsframework.go#L254-L557在集群中完整部署一套 Prometheus Operator其流程包括基于 example/rbac/prometheus-operator/prometheus-operator-deployment.yaml 等清单创建 ServiceAccount、ClusterRole、ClusterRoleBinding依次创建并等待所有 CRD 就绪Alertmanager、PodMonitor、Probe、Prometheus、PrometheusRule、ServiceMonitor、ThanosRuler、AlertmanagerConfigv1alpha1/v1beta1、PrometheusAgent以及可选的 ScrapeConfig通过EnableScrapeConfigs控制为 Operator 生成自签名证书并写入 Secret将 Operator Deployment 的镜像替换为--operator-image传入的镜像并同步推导prometheus-config-reloader与admission-webhook的镜像 tag根据测试需要注入启动参数例如--namespaces、--deny-namespaces、--prometheus-instance-namespaces、--alertmanager-instance-namespaces、--feature-gates等若开启EnableAdmissionWebhook还会部署 admission-webhook 服务并配置 PrometheusRule 的变更/校验 webhook、AlertmanagerConfig 的校验 webhook 与 v1alpha1/v1beta1 转换 webhook返回一组 finalizer 函数供测试结束Cleanup时回收资源。PrometheusOperatorOptsframework.go#L207-L218集中表达了上述可配置项包括命名空间白名单/黑名单、Prometheus/Alertmanager 实例命名空间、是否启用 admission webhook、ClusterRoleBinding、ScrapeConfig、附加参数与启用的 feature gate。例如TestAllNS中通过如下方式部署 Operatormain_test.go#L176-L184finalizers, err : framework.CreateOrUpdatePrometheusOperatorWithOpts( ctx, operatorFramework.PrometheusOperatorOpts{ Namespace: ns, EnableAdmissionWebhook: true, ClusterRoleBindings: true, EnableScrapeConfigs: true, }, )测试上下文与失败诊断每个测试还会通过framework.NewTestCtx(t)context.go#L103-L196创建独立的TestCtx其职责包括生成唯一的命名空间以测试名加时间戳为前缀保证测试之间互不干扰管理资源回收所有创建的集群资源都通过AddFinalizerFn注册清理函数测试结束无论成功失败时由Cleanup并行执行失败诊断收集当测试失败时自动收集当前集群中的关键信息用于排查包括工作负载资源Alertmanager/Prometheus/ThanosRuler/PrometheusAgent、配置资源ServiceMonitor/PodMonitor/Probe/PrometheusRule/ScrapeConfig/AlertmanagerConfig、Kubernetes 资源StatefulSet/DaemonSet/Pod/Service/ConfigMap/Secret其中 Secret 中的内容会被脱敏为obfuscated、Pod 日志与事件。诊断信息默认输出到 stdout设置环境变量E2E_DIAGNOSTIC_DIRECTORY后会改为按测试名分目录写入文件便于归档分析E2E_DIAGNOSTIC_DIRECTORY/tmp/e2e-diag make test-e2e-prometheus手动运行 Operatorrun-external.sh除了完整的自动化测试scripts/run-external.sh 提供了手动测试场景它会在你的 kind 集群中检查所有前置条件然后以本地编译的 Operator 二进制直接运行适合开发调试。./scripts/run-external.sh -c该脚本的主要行为-c / --use-default-context使用当前 kubeconfig 的默认 context也可以直接传入 context 名-f / --no-operator-run-check跳过集群中不能已有 prometheus-operator 运行的检查脚本默认会检查并拒绝在已有 Operator 的集群上运行避免冲突从 kubeconfig 中提取 API Server 地址、CA、客户端证书与密钥执行make operator构建本地二进制通过kubectl apply --server-side --force-conflicts安装 example/prometheus-operator-crd-full 下的全部 CRD并等待其 Established以前台方式运行./operator日志输出到tmp/operator.log。它支持通过环境变量定制运行参数例如REPAIR_POLICYStatefulSet 修复策略、FEATURE_GATESfeature gate 列表、LOG_LEVEL日志级别等。常见问题与调试建议测试总是超时或卡住检查 kind 集群资源是否充足尤其是 podman 场景建议 4 CPU / 8 GiB以及镜像是否已正确加载进集群——go test不会自动构建镜像遗漏make test-e2e-images是常见原因。kubeconfig 路径错误直接运行go test时必须显式传--kubeconfig使用make test-e2e时默认取$HOME/.kube/config可用KUBECONFIG...覆盖。只想跑某类测试优先选择 Makefile 中对应的分目标或自行组合EXCLUDE_*环境变量调试单个用例用TEST_RUN_ARGS-run 测试名。测试失败需要排查设置E2E_DIAGNOSTIC_DIRECTORY让框架在失败时把集群状态、Pod 日志、事件落盘也可以参照TestAllNS末尾对 Operator Pod 重启次数的断言逻辑main_test.go#L211-L224自行检查 Operator 是否意外重启。小结Prometheus Operator 的 E2E 测试是一套完整的、可在本机复现的自动化测试体系以 test/e2e/README.md 的三条前置条件与一条go test命令为起点配合 Makefile 的test-e2e系列目标、test/e2e/main_test.go 的套件编排与EXCLUDE_*跳过机制、test/framework 的集群操作能力你可以在本机完整复现 CI 中的验证流程也可以精确裁剪测试范围来加速开发反馈循环。无论是提交新功能、修复缺陷还是验证 Operator 升级兼容性这套 E2E 测试都能在真实集群环境中给出最可信的答案。赞分享云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载相关推荐eCapture 端到端E2E测试全指南从环境搭建、测试架构到 CI/CD 集成eCapture 端到端E2E测试全指南从环境搭建、测试架构到 CI/CD 集成 导读 本文基于 eCapture 仓库中的端到端测试套件 docs/e网络安全网络可观测性系统编程Vertical Pod Autoscaler 开发与端到端测试完全指南本地 e2e 测试环境搭建与运行详解Vertical Pod Autoscaler 开发与端到端测试完全指南本地 e2e 测试环境搭建与运行详解 导读 本指南以 Kubernetes Autos弹性伸缩云原生容器编排Kubernetes 动态资源分配DRA端到端测试指南Kind 集群搭建、代理式测试驱动与 e2e 运行全流程Kubernetes 动态资源分配DRA端到端测试指南Kind 集群搭建、代理式测试驱动与 e2e 运行全流程 动态资源分配Dynamic Resour云原生容器编排集群管理微服务上一篇使用 SpeechBrain 在 CommonVoice 14.0 上训练 CTC 注意力 Seq2Seq 多语言语音识别系统下一篇OpenMontage Remotion 技能实战共享组件、自定义转场与项目时序约定全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考