尧图网页设计 
Cilium 遗留 Ginkgo E2E 测试框架实战指南从本地 Qemu 复现 CI 到多环境执行【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇围绕 Cilium 仓库中的遗留LegacyGinkgo 端到端测试框架展开完整覆盖其在两种模式下的本地运行方式基于 kubeconfig 对接既有集群以及通过 Qemu Kind 在本地复现 GitHub ActionsGHA环境。读完后你将能够独立搭建 Ginkgo 测试环境、精确聚焦目标用例、在 GKE/AKS/EKS 等环境中执行测试集并理解 Cilium 对 Ginkgo 所做的BeforeAll/AfterAll/JustAfterEach/AfterFailed扩展机制的源码级实现。一、框架定位遗留但仍在服役首先需要明确当前状态仓库文档开头即声明Ginkgo 端到端测试框架已被弃用deprecated新的端到端测试应当使用cilium-cli的 connectivity 测试框架见 e2e.rst。但 Ginkgo 套件目前仍支撑着大量 CI 工作流如 conformance-ginkgo.yaml维护存量用例、排查 CI 失败、理解测试基础设施都绕不开本文介绍的内容。测试代码位于仓库的test/目录入口是 test_suite_test.go其中通过包导入副作用引入全部测试包// These packages are where Ginkgo test specs live. They are declared as blank // (_) global variables and are pulled in using package import side effects. _ github.com/cilium/cilium/test/k8s所有测试名必须以以下两个前缀之一开头Ginkgo 的focus概念据此决定需要哪些 Kubernetes 节点Runtime在单节点 runtime 环境中测试 CiliumK8s搭建小型多节点 Kubernetes 环境测试跨主机特性与 Kubernetes 专属功能。从源码结构看Test()函数会在未指定 scope/focus 时直接t.Skip避免go test ./...误拉起整套集成测试当CNI_INTEGRATION为microk8s或minikube时会自动关闭多节点测试config.CiliumTestConfig.Multinode false。二、两种本地运行模式概览模式适用场景环境来源GHA 相似模式Qemu Kind在本地精确复现 GitHub Actions 的 CI 环境自行用 Qemu 启动 VMVM 内再跑 Kind 集群kubeconfig 模式在任意已有集群云厂商托管 K8s、本地 Kind 等上跑测试复用现成集群框架只负责部署 Cilium 并执行用例两种模式都要求先熟悉 Ginkgo 本身其 Getting-Started 与 Focused Specs 概念是后续所有操作的基础。三、GHA 相似模式用 Qemu 在本地复现 CI文档明确指出conformance-ginkgo.yaml与conformance-runtime.yaml两个工作流无法在本地直接运行但可以手工搭建一个与之高度相似的环境。以下示例对应 focusf10-agent-hubble-bandwidth、Kubernetes1.27、内核net-next、commit SHA7b368923823e63c9824ea2b5ee4dc026bc4d5cd8。这些步骤也可以用脚本contrib/scripts/run-gh-ginkgo-workflow.sh自动完成-h查看用法。3.1 下载依赖helm、ginkgoGinkgo 版本需与 GitHub Actions 保持一致v1.16.5$ HELM_VERSIONv3.13.1 $ wget https://get.helm.sh/helm-${HELM_VERSION}-linux-amd64.tar.gz $ tar -xf helm-v${HELM_VERSION}-linux-amd64.tar.gz $ mv linux-amd64/helm ./helm $ cd ~/ $ go install github.com/onsi/ginkgo/ginkgov1.16.5 $ ${GOPATH}/bin/ginkgo version Ginkgo Version 1.16.5这些依赖存放在一个特定目录下供后续 Qemu 通过共享挂载使用。3.2 本地编译 Ginkgo 测试在test/目录执行ginkgo build生成二进制test.test等价于 test/Makefile 的build目标即ginkgo build$ cd github.com/cilium/cilium/test $ ${GOPATH}/bin/ginkgo build注意当前仓库 test/Makefile 的test目标已不再通过 make 直接运行测试执行时会提示改用本文档指引直接调用 ginkgo而k8s-kind目标则提供了针对本地 Kind 的现成封装见第七节。3.3 用 Qemu 供给 VM获取镜像 tag查阅 .github/actions/ginkgo/main-k8s-versions.yaml 获取内核与 K8s 版本对应的镜像 tag例如kernel:bpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411k8s:kindest/node:v1.27.1sha256:b7d12ed662b873bd8510879c1846e87c7e676a79fefc93e17b2a52989d3ff42b取出压缩的 VM 镜像$ mkdir -p /tmp/_images $ kernel_tagbpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411 $ docker run -v /tmp/_images:/mnt/images \ quay.io/lvh-images/kind:${kernel_tag} \ cp -r /data/images/. /mnt/images/解压并用 Qemu 启动 VMQemu 会使用当前终端供给 VM并把当前目录挂载到 VM 内的/host$ zstd -d /tmp/_images/kind_*.qcow2.zst -o /tmp/_images/ginkgo-tests.qcow2 $ qemu-system-x86_64 \ -nodefaults \ -no-reboot \ -smp 4 \ -m 12G \ -enable-kvm \ -cpu host \ -drive file/tmp/_images/ginkgo-tests.qcow2,ifvirtio,index0,mediadisk \ -netdev user,iduser.0,hostfwdtcp::2222-:22 \ -device virtio-net-pci,netdevuser.0 \ -fsdev local,idhost_id,path./,security_modelnone \ -device virtio-9p-pci,fsdevhost_id,mount_taghost_mount \ -serial mon:stdio3.4 VM 内安装依赖并供给 Kind$ ssh -p 2222 -o StrictHostKeyCheckingno rootlocalhost # echo nameserver 8.8.8.8 /etc/resolv.conf # git config --global --add safe.directory /host # cp /host/helm /usr/bin与 GitHub Action 一样CI 在 VM 内用 Kind 跑集群。Kind 的供给方式取决于内核版本——bpf-next 下的供给方式与其他内核不同$ ssh -p 2222 -o StrictHostKeyCheckingno rootlocalhost # cd /host/ # kernel_tagbpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411 # kubernetes_imagekindest/node:v1.27.1sha256:b7d12ed662b873bd8510879c1846e87c7e676a79fefc93e17b2a52989d3ff42b # ip_familydual # replace with ipv4 if k8s 1.19 # # if [[ ${kernel_tag} bpf-next-* ]]; then # ./contrib/scripts/kind.sh 2 ${kubernetes_image} none ${ip_family} # kubectl label node kind-worker2 cilium.io/ci-nodekind-worker2 # # Avoid re-labeling this node by setting node-role.kubernetes.io/controlplane # kubectl label node kind-worker2 node-role.kubernetes.io/controlplane # else # ./contrib/scripts/kind.sh 1 ${kubernetes_image} iptables ${ip_family} # fi # git config --global --add safe.directory /cilium验证 Kind 已在 VM 内运行$ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-787d4945fb-hqzpb 0/1 Pending 0 42s kube-system etcd-kind-control-plane 1/1 Running 0 57s kube-system kube-apiserver-kind-control-plane 1/1 Running 0 57s kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 56s kube-system kube-scheduler-kind-control-plane 1/1 Running 0 56s local-path-storage local-path-provisioner-6bd6454576-648bk 0/1 Pending 0 42s3.5 在 VM 内执行测试先取 focus 正则在 .github/actions/ginkgo/main-focus.yaml 中f10-agent-hubble-bandwidth对应的cliFocus为K8sAgentHubbleTest仓库当前配置文件中可确认该映射依然存在。运行前面编译出的test.test。该命令与 GitHub workflow 完全一致唯一区别是额外加了-cilium.holdEnvironmenttrue——测试失败时保留测试环境以便进一步诊断。从源码看这个开关在 test_suite_test.go 中生效if config.CiliumTestConfig.HoldEnvironment { RegisterFailHandler(helpers.Fail) } else { RegisterFailHandler(Fail) }helpers.Fail会标记失败但不拆除环境而 Ginkgo 原生Fail会触发 panic 并进入清理流程。$ ssh -p 2222 -o StrictHostKeyCheckingno rootlocalhost # cd /host/test # kernel_tagbpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411 # k8s_version1.27 # # export K8S_NODES2 # export NETNEXT0 # export K8S_VERSION${k8s_version} # export CNI_INTEGRATIONkind # export INTEGRATION_TESTStrue # # if [[ ${kernel_tag} bpf-next-* ]]; then # export KERNELnet-next # export NETNEXT1 # export KUBEPROXY0 # export K8S_NODES3 # export NO_CILIUM_ON_NODESkind-worker2 # elif [[ ${kernel_tag} 5.4-* ]]; then # export KERNEL54 # fi # # # GitHub actions do not support IPv6 connectivity to outside # # world. If the infrastructure environment supports it, then # # this line can be removed # export CILIUM_NO_IPV6_OUTSIDEtrue # # commit_sha7b368923823e63c9824ea2b5ee4dc026bc4d5cd8 # cliFocusK8sAgentHubbleTest # quay_orgcilium # # ./test.test \ --ginkgo.focus${cliFocus} \ --ginkgo.skip \ --ginkgo.seed1679952881 \ --ginkgo.v -- \ -cilium.imagequay.io/${quay_org}/cilium-ci \ -cilium.tag${commit_sha} \ -cilium.operator-imagequay.io/${quay_org}/operator \ -cilium.operator-tag${commit_sha} \ -cilium.hubble-relay-imagequay.io/${quay_org}/hubble-relay-ci \ -cilium.hubble-relay-tag${commit_sha} \ -cilium.kubeconfig/root/.kube/config \ -cilium.operator-suffix-ci \ -cilium.holdEnvironmenttrue Using CNI_INTEGRATIONkind Running Suite: Suite-k8s-1.27 Random Seed: 1679952881 Will run 7 of 132 specs注意几处环境变量的语义bpf-next内核时不设 kube-proxyKUBEPROXY0、节点数扩到 3并把kind-worker2列入NO_CILIUM_ON_NODES——该节点专门用于验证无 Cilium 节点场景test/helpers/kubectl.go 中可见NO_CILIUM_ON_NODE会参与 Cilium 调度与日志采集器的节点选择逻辑。等待执行完成预期输出Ran 7 of 132 Specs in 721.007 seconds SUCCESS! -- 7 Passed | 0 Failed | 0 Pending | 125 Skipped3.6 清理与环境复用测试结束后终止 Qemu 即可停止 VM$ pkill qemu-system-x86VM 状态保存在/tmp/_images/ginkgo-tests.qcow2中依赖也已安装完毕。因此下次运行时可以直接从供给 Kind这一步开始跳过依赖下载与 VM 供给实现环境状态复用。四、Runtime 测试单节点快速执行在test/目录下执行全部 runtime 测试INTEGRATION_TESTStrue ginkgo --focusRuntimeGinkgo 会在所有子目录中查找名称以Runtime开头且其后还有任意字符的测试。用--dryRun可以只做匹配演练而不真正执行$ INTEGRATION_TESTStrue ginkgo --focusRuntime -dryRun Running Suite: runtime Random Seed: 1516125117 Will run 42 of 164 specs ................ RuntimePolicyEnforcement Policy Enforcement Always Always to Never with policy /Users/ianvernon/go/src/github.com/cilium/cilium/test/runtime/Policies.go:258 • ------------------------------ ... Ran 42 of 164 Specs in 0.002 seconds SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 122 Skipped PASS Ginkgo ran 1 suite in 1.830262168s Test Suite Passed五、CLI 选项全览-cilium.help在test/目录下直接查看 Cilium 框架注册的全部自定义选项$ cd test/ $ ginkgo . -- -cilium.help文档中记录的选项如下选项说明-cilium.SSHConfig string指定获取 SSH 配置的命令如vagrant ssh-config-cilium.help显示帮助信息-cilium.holdEnvironment失败时保留环境现场-cilium.hubble-relay-image/-cilium.hubble-relay-tag测试使用的 hubble-relay 镜像与 tag-cilium.image/-cilium.tag测试使用的 cilium 镜像与 tag-cilium.kubeconfigk8s 测试使用的 kubeconfig-cilium.multinode启用多节点测试禁用后多节点检查可能被静默跳过默认true-cilium.operator-image/-cilium.operator-tagcilium-operator 镜像与 tag-cilium.passCLIEnvironment将调用 ginkgo 的环境含 PATH传递给子命令-cilium.showCommands把执行的命令打印到 stdout-cilium.skipLogs测试失败时跳过日志收集-cilium.testScope指定测试 scopek8s, runtime-cilium.timeout duration测试运行超时默认 24h需要注意当前源码中ParseFlags()还注册了文档未列出的若干选项见 test/config/config.go-cilium.kubectl-path版本相关 kubectl 二进制的存放路径默认/tmp/kubectl-cilium.registryCredentials拉取私有镜像的 registry 凭据-cilium.install-helm-overrides以逗号分隔的cilium install helm --set覆盖项优先级高于测试自身设置的任何值-cilium.extra-opts原样透传给cilium-agent启动的额外选项。-cilium.help的实现方式是扫描os.Args命中-cilium.help时打印flagset默认值后退出ParseFlags()中会先剥离所有含-cilium的参数再解析因此它输出的是源码注册表永远与当前代码同步。六、精确选择测试与纯编译校验6.1 通过代码聚焦给目标测试加FIt前缀即可Ginkgo 的 Focused Specs 机制会跳过其余测试It(Example test, func(){ Expect(true).Should(BeTrue()) }) FIt(Example focused test, func(){ Expect(true).Should(BeTrue()) })6.2 通过命令行聚焦--focus接受正则表达式含空格时必须加引号*也需避免被 shell 展开INTEGRATION_TESTStrue ginkgo --focus Runtime.*L76.3 只编译不运行验证测试代码语法正确而不跑完整套件make -C test/ build七、构建并更新本地 Cilium 测试镜像开发中常需要把改过的 Cilium 推给 CI 环境。文档给出在k8s1VM 上的操作源自早期的test/provision/compile.sh脚本该脚本路径在仓库中已不保留cd go/src/github.com/cilium/cilium make LOCKDEBUG1 docker-cilium-image docker tag quay.io/cilium/cilium:latest \ k8s1:5000/cilium/cilium-dev:latest docker push k8s1:5000/cilium/cilium-dev:latest make -B LOCKDEBUG1 docker-operator-generic-image docker tag quay.io/cilium/operator-generic:latest \ k8s1:5000/cilium/operator-generic:latest docker push k8s1:5000/cilium/operator-generic:latest当前 test/Makefile 中保留了更现成的k8s-kind目标它会自动从kubectl version取 K8S_VERSION、固定DOCKER_REGISTRYlocalhost:5000并指定本地镜像cilium/cilium-dev:localFOCUSK8sFoo make k8s-kind # 等价于 # CNI_INTEGRATIONkind K8S_VERSION... NETNEXT... KUBEPROXY1 \ # NO_CILIUM_ON_NODES... INTEGRATION_TESTStrue ginkgo --focus $(FOCUS) -v -- \ # -cilium.testScopek8s -cilium.kubeconfig$$(echo ~/.kube/config) \ # -cilium.passCLIEnvironmenttrue -cilium.imagelocalhost:5000/cilium/cilium-dev \ # -cilium.taglocal -cilium.operator-imagequay.io/cilium/operator \ # -cilium.operator-suffix-ci -cilium.holdEnvironmenttrue八、JUnit 测试报告与调试8.1 JUnit 报告Cilium 的 Ginkgo 框架为每个测试生成 JUnit 报告。文档记录的输出文件为runtime.xml与K8s.xml。从源码看报告名实际由 scope 拼接版本动态生成见 test_suite_test.gojunitReporter : NewJUnitReporter(fmt.Sprintf( %s.xml, helpers.GetScopeWithVersion()))因此 K8s 套件会产出类似K8s-1.27.xml的文件k8s-*.xml也列入 Makefile 的TEST_ARTIFACTS清理清单。8.2 测试日志目录所有执行过的命令及其输出保存在报告目录./test/test_results每个测试创建独立文件夹内含log文件保存全部信息失败测试会追加详尽数据。例如$ head test/test_results/RuntimeKafkaKafkaPolicyIngress/logs levelinfo msgStarting testNameRuntimeKafka levelinfo msgVagrant: running command \vagrant ssh-config runtime\ cmd: sudo cilium-dbg status exitCode: 0 KVStore: Ok Etcd: 172.17.0.3:4001 Kubernetes: Disabled ...8.3 用 Delve 调试在测试代码中插入runtime.BreakPoint()断点然后用dlv运行 ginkgodlv test . -- --ginkgo.focusRuntime -ginkgo.vtrue此外 test_suite_test.go 的init()还会启动gopsagent 监听 socket在测试死锁时可用于抓取 stack trace——这与后文JustAfterEach用于死锁检测的设计互为呼应。九、Ginkgo 扩展BeforeAll / AfterAll / JustAfterEach / AfterFailedCilium 在test/ginkgo-ext包中扩展了 Ginkgo补齐了 Ginkgo 原版缺失的容器级一次性 setup/teardown能力。实现集中在 test/ginkgo-ext/scopes.go其核心是一个scope 树BeforeAll在某个Describe/Context内所有BeforeEach之前执行一次等价于常见框架的SetUpAfterAll在该容器内所有It跑完、所有AfterEach执行完毕后再运行用于拆除被多个It共享的容器/Pod 等资源JustAfterEach紧跟每个测试之后、AfterFailed与AfterEach之前运行适合做一组测试的统一断言例如死锁检测检查测试期间 Cilium 日志是否出现死锁AfterFailed位于JustAfterEach之后、AfterEach之前仅当测试失败时调用用于收集日志、Cilium 状态等失败分析数据。文档给出的测试布局示例Describe BeforeAll(A) AfterAll(A) AfterFailed(A) AfterEach(A) JustAfterEach(A) TESTA1 TESTA2 TESTA3 Context BeforeAll(B) AfterAll(B) AfterFailed(B) AfterEach(B) JustAfterEach(B) TESTB1 TESTB2 TESTB3执行流程Describe BeforeAll TESTA1; JustAfterEach(A), AfterFailed(A), AfterEach(A) TESTA2; JustAfterEach(A), AfterFailed(A), AfterEach(A) TESTA3; JustAfterEach(A), AfterFailed(A), AfterEach(A) Context BeforeAll(B) TESTB1: JustAfterEach(B); JustAfterEach(A) AfterFailed(B); AfterFailed(A); AfterEach(B) ; AfterEach(A); TESTB2: 同 TESTB1 TESTB3: 同 TESTB1 AfterAll(B) AfterAll(A)源码级实现要点scopes.gowrapContextFunc在注册Describe/Context时创建新的scope节点记录父指针、测试计数器、失败标记It/Measure经由wrapItFunc/wrapMeasureFunc计入所在 scope 的normalTests/focusedTestscalculateCounters在BeforeSuite阶段递归统计本次会运行多少测试AfterAll只有在对应 scope 计数器归零cs.isZero()且所有AfterEach执行完毕后才触发——这就是等所有 It 跑完的实现RunAfterEach统一编排收尾顺序runAllJustAfterEach→runAllAfterFail→runAllAfterEach→ 若AfterEach中出错则补跑AfterFailed→ 最后才可能是AfterAll与文档流程图逐行对应FailWithToggle包内导出为Fail在AfterEach阶段被调用时不会立即 panicfailEnabled false而是把失败记入afterEachFailed在全部收尾函数跑完后才真正ginkgo.Fail保证失败日志收集不被中断——这是-cilium.skipLogs、AfterFailed等机制能稳定工作的底层保障。同包还提供条件跳过工具SkipDescribeIf、SkipContextIf、SkipItIf以及Failf格式化失败函数供测试代码按条件整体跳过容器或用例。十、测试编写最佳实践用By输出信息性步骤日志降低他人理解测试的门槛。源码中By会带时间戳前缀写入GinkgoWriterscopes.go 中的By()实现保持环境原状测试结束时删除资源、重置配置恢复到开始前的状态失败必留日志Ginkgo 失败后必须做 postmortem把日志 dump 到 Ginkgo 能收集的位置。在AfterFailed中使用AfterFailed(func() { vm.ReportFailed() })十一、kubeconfig 模式在任意既有集群上运行通过--cilium.kubeconfig指定任意 kubeconfig 即可运行端到端测试此时框架跳过环境供给与节点打标签等准备工作。该模式的预期前提当前目录是cilium/test必须传--focus如--focusK8s选中全部 K8s 测试若 focus 不覆盖 scope则需另传-cilium.testScopeK8s用--cilium.image与--cilium.operator-image以完整 URL 形式提供 Cilium 镜像可用的 kubeconfig 通过--cilium.kubeconfig提供设置K8S_VERSION环境变量与集群版本一致源码中经helpers.GetCurrentK8SEnv()读取视环境设置CNI_INTEGRATION为gke、eks、eks-chaining、microk8s或minikube之一以选中匹配的 Cilium 配置覆盖项不匹配时留空也是正确做法。集成常量定义见 test/helpers/kubectl.go如CIIntegrationKind kind对 EKS 这类需要认证代理如aws-iam-authenticator的环境设置--cilium.passCLIEnvironmenttrue。通用示例EKS 风格INTEGRATION_TESTStrue CNI_INTEGRATIONeks K8S_VERSION1.16 ginkgo --focusK8s -- \ -cilium.kubeconfigecho ~/.kube/config \ -cilium.imagequay.io/cilium/cilium-ci \ -cilium.operator-imagequay.io/cilium/operator \ -cilium.operator-suffix-ci \ -cilium.passCLIEnvironmenttrue本地 Kind 示例对应第七节的本地镜像K8S_VERSION1.25 ginkgo --focusK8s -- \ --cilium.imagelocalhost:5000/cilium/cilium-dev -cilium.taglocal \ --cilium.operator-imagelocalhost:5000/cilium/operator -cilium.operator-taglocal \ --cilium.kubeconfigecho ~/.kube/config \ -cilium.testScopeK8s -cilium.operator-suffix从源码看kubeconfig 模式下BeforeAll依然会执行 K8s scope 的初始化链路PrepareCluster()集群准备、CleanupCiliumComponents()清理上一次本地运行残留的 Cilium 组件、应用 Prometheus 监控示例examples/kubernetes/addons/prometheus/monitoring-example.yaml并启动PprofReport()协程。GKE按 Kubernetes 安装文档建集群或复用现有集群。无需手动部署 Cilium框架会负责部署节点规格要求大于n1-standard-4建集群时--machine-type指定测试要求NATIVE_CIDR环境变量等于gcloud container clusters describe返回的集群 IPv4 CIDR。export CLUSTER_NAMEcluster1 export CLUSTER_ZONEus-west2-a export NATIVE_CIDR$(gcloud container clusters describe $CLUSTER_NAME \ --zone $CLUSTER_ZONE --format value(clusterIpv4Cidr)) INTEGRATION_TESTStrue CNI_INTEGRATIONgke K8S_VERSION1.17 ginkgo --focusK8sDemo -- \ -cilium.kubeconfigecho ~/.kube/config \ -cilium.imagequay.io/cilium/cilium-ci \ -cilium.operator-imagequay.io/cilium/operator \ -cilium.operator-suffix-ci \ -cilium.hubble-relay-imagequay.io/cilium/hubble-relay-ci \ -cilium.passCLIEnvironmenttrue文档注明 K8s 版本默认 1.23可配置范围为 1.161.23且应与kubectl version报告的 server 版本一致此为文档历史说明当前代码中DefaultSettings的K8S_VERSION默认值已是 1.36。AKS实验性同样要求设置NATIVE_CIDR且无需预装 Ciliumexport NATIVE_CIDR10.241.0.0/16 INTEGRATION_TESTStrue CNI_INTEGRATIONaks K8S_VERSION1.17 ginkgo --focusK8s -- \ -cilium.kubeconfigecho ~/.kube/config -cilium.passCLIEnvironmenttrue \ -cilium.imagemcr.microsoft.com/oss/cilium/cilium -cilium.tag1.12.1 \ -cilium.operator-imagemcr.microsoft.com/oss/cilium/operator \ -cilium.operator-suffix -cilium.operator-tag1.12.1AWS EKS实验性并非所有测试都能在 EKS 上成功但相当一部分可以运行且仍有价值文档指向 GitHub issue #9678 的评论作为仍失败用例的清单。步骤建集群或复用现有集群同样无需预装 Ciliumsourcecontrib/testing/integrations.sh测试集成脚本调用gks函数传入 Cilium 镜像与 focus也可追加 ginkgo 参数gks quay.io/cilium/cilium:latest K8sDemo新增托管 Kubernetes Provider 的步骤所有托管 K8s 测试支持都基于预配置 kubeconfig但往往需要 provider 专属默认值。文档以当年添加 GKE 支持的提交为参照给出四步扩展流程涉及文件均为当前仓库可定位的 test/helpers/kubectl.go 与test/helpers包在该 provider 的 helm 设置覆盖表中新增一项生成该 provider 的 cilium specs 时使用的 helm 参数新增唯一的CI Integration常量经CNI_INTEGRATION环境变量传入 ginkgo更新 helm overrides 映射把常量与 helm 设置关联需要按条件跳过用例时用SkipIfIntegration跳过整个 Context 用SkipContextIf更复杂的逻辑用IsIntegration一类函数表达——它们都位于test/helpers包容器级跳过则由 ginkgo-ext 的SkipContextIf/SkipDescribeIf实现。十二、SSH 模式在任意可 SSH 环境运行用--cilium.SSHConfig提供测试目标机器的 SSH 配置。测试假定远程实例满足Cilium 源码位于/home/$USER/go/src/github.com/cilium/cilium/Cilium 已安装并正在运行。ssh-config文件需要定义以下目标runtime运行 runtime 测试k8s{1..2}-${K8S_VERSION}运行 Kubernetes 测试实例须已装好并运行 Kubernetes。示例ssh-configHost runtime HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile /home/eloy/.go/src/github.com/cilium/cilium/test/.vagrant/machines/runtime/virtualbox/private_key IdentitiesOnly yes LogLevel FATAL运行命令-cilium.SSHConfig的值是获取 ssh-config 的命令与 config.go 中该 flag 的描述一致ginkgo -- --cilium.SSHConfigcat ssh-config从 test_suite_test.go 的BeforeAll可印证该模式的行为一旦设置了SSHConfig框架直接return不再执行 VM 供给与集群准备逻辑——即完全信任远端环境已就绪。十三、环境变量速查表文档记录的常用环境变量ENV 变量默认值取值说明K8S_NODES20..100集群中的 Kubernetes 节点数NO_CILIUM_ON_NODE[S]无*不应运行 Cilium 的 K8s 节点逗号分隔K8S_VERSION1.181.18安装的 Kubernetes 版本KUBEPROXY10-1为 0 时不安装 kube-proxy两处源码补充test/Makefile 在k8s-kind目标中默认KUBEPROXY1、NO_CILIUM_ON_NODES为空串并透传NETNEXTtest_suite_test.go 的DefaultSettings会把未设置的K8S_VERSION兜底为1.36即当前仓库默认值文档表格中的 1.18 为历史默认。十四、失败排查与进一步支持现场保留加-cilium.holdEnvironmenttrue失败后环境不拆解可kubectl直接进集群诊断对应helpers.Fail不 panic 的机制命令留痕-cilium.showCommands会把所有执行的命令打印到 stdout配合test/test_results/TestName/下的log与cmds.log源码中AfterEach会将SSHMetaLogs落盘为cmds.log还原完整执行轨迹日志收集开关-cilium.skipLogs可跳过失败时的日志收集以加快迭代死锁/挂起JustAfterEach中内置的死锁检测 init()启动的 gops agent双管齐下定位 hang 住的测试文档建议对测试框架机制有疑问或想改进测试基础设施时可到 Cilium Slack 的#testing频道交流。结语这份遗留 Ginkgo E2E 框架文档的价值在于它完整描述了一套CI 可复现、多环境可插拔的端到端测试体系——GHA 相似模式保证本地与 CI 结果一致kubeconfig/SSH 模式把同一套用例投射到 GKE、AKS、EKS 等真实环境而ginkgo-ext包用 scope 树 有序收尾钩子解决了 Ginkgo v1 缺乏容器级 setup/teardown 的历史缺陷。即便新测试已迁移到cilium-cliconnectivity 框架理解这套机制仍然是阅读 Cilium 历史用例、排查 CI 失败、扩展托管云 provider 支持的基础。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cilium 遗留 Ginkgo E2E 测试框架实战指南：从本地 Qemu 复现 CI 到多环境执行
Cilium 遗留 Ginkgo E2E 测试框架实战指南从本地 Qemu 复现 CI 到多环境执行【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇围绕 Cilium 仓库中的遗留LegacyGinkgo 端到端测试框架展开完整覆盖其在两种模式下的本地运行方式基于 kubeconfig 对接既有集群以及通过 Qemu Kind 在本地复现 GitHub ActionsGHA环境。读完后你将能够独立搭建 Ginkgo 测试环境、精确聚焦目标用例、在 GKE/AKS/EKS 等环境中执行测试集并理解 Cilium 对 Ginkgo 所做的BeforeAll/AfterAll/JustAfterEach/AfterFailed扩展机制的源码级实现。一、框架定位遗留但仍在服役首先需要明确当前状态仓库文档开头即声明Ginkgo 端到端测试框架已被弃用deprecated新的端到端测试应当使用cilium-cli的 connectivity 测试框架见 e2e.rst。但 Ginkgo 套件目前仍支撑着大量 CI 工作流如 conformance-ginkgo.yaml维护存量用例、排查 CI 失败、理解测试基础设施都绕不开本文介绍的内容。测试代码位于仓库的test/目录入口是 test_suite_test.go其中通过包导入副作用引入全部测试包// These packages are where Ginkgo test specs live. They are declared as blank // (_) global variables and are pulled in using package import side effects. _ github.com/cilium/cilium/test/k8s所有测试名必须以以下两个前缀之一开头Ginkgo 的focus概念据此决定需要哪些 Kubernetes 节点Runtime在单节点 runtime 环境中测试 CiliumK8s搭建小型多节点 Kubernetes 环境测试跨主机特性与 Kubernetes 专属功能。从源码结构看Test()函数会在未指定 scope/focus 时直接t.Skip避免go test ./...误拉起整套集成测试当CNI_INTEGRATION为microk8s或minikube时会自动关闭多节点测试config.CiliumTestConfig.Multinode false。二、两种本地运行模式概览模式适用场景环境来源GHA 相似模式Qemu Kind在本地精确复现 GitHub Actions 的 CI 环境自行用 Qemu 启动 VMVM 内再跑 Kind 集群kubeconfig 模式在任意已有集群云厂商托管 K8s、本地 Kind 等上跑测试复用现成集群框架只负责部署 Cilium 并执行用例两种模式都要求先熟悉 Ginkgo 本身其 Getting-Started 与 Focused Specs 概念是后续所有操作的基础。三、GHA 相似模式用 Qemu 在本地复现 CI文档明确指出conformance-ginkgo.yaml与conformance-runtime.yaml两个工作流无法在本地直接运行但可以手工搭建一个与之高度相似的环境。以下示例对应 focusf10-agent-hubble-bandwidth、Kubernetes1.27、内核net-next、commit SHA7b368923823e63c9824ea2b5ee4dc026bc4d5cd8。这些步骤也可以用脚本contrib/scripts/run-gh-ginkgo-workflow.sh自动完成-h查看用法。3.1 下载依赖helm、ginkgoGinkgo 版本需与 GitHub Actions 保持一致v1.16.5$ HELM_VERSIONv3.13.1 $ wget https://get.helm.sh/helm-${HELM_VERSION}-linux-amd64.tar.gz $ tar -xf helm-v${HELM_VERSION}-linux-amd64.tar.gz $ mv linux-amd64/helm ./helm $ cd ~/ $ go install github.com/onsi/ginkgo/ginkgov1.16.5 $ ${GOPATH}/bin/ginkgo version Ginkgo Version 1.16.5这些依赖存放在一个特定目录下供后续 Qemu 通过共享挂载使用。3.2 本地编译 Ginkgo 测试在test/目录执行ginkgo build生成二进制test.test等价于 test/Makefile 的build目标即ginkgo build$ cd github.com/cilium/cilium/test $ ${GOPATH}/bin/ginkgo build注意当前仓库 test/Makefile 的test目标已不再通过 make 直接运行测试执行时会提示改用本文档指引直接调用 ginkgo而k8s-kind目标则提供了针对本地 Kind 的现成封装见第七节。3.3 用 Qemu 供给 VM获取镜像 tag查阅 .github/actions/ginkgo/main-k8s-versions.yaml 获取内核与 K8s 版本对应的镜像 tag例如kernel:bpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411k8s:kindest/node:v1.27.1sha256:b7d12ed662b873bd8510879c1846e87c7e676a79fefc93e17b2a52989d3ff42b取出压缩的 VM 镜像$ mkdir -p /tmp/_images $ kernel_tagbpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411 $ docker run -v /tmp/_images:/mnt/images \ quay.io/lvh-images/kind:${kernel_tag} \ cp -r /data/images/. /mnt/images/解压并用 Qemu 启动 VMQemu 会使用当前终端供给 VM并把当前目录挂载到 VM 内的/host$ zstd -d /tmp/_images/kind_*.qcow2.zst -o /tmp/_images/ginkgo-tests.qcow2 $ qemu-system-x86_64 \ -nodefaults \ -no-reboot \ -smp 4 \ -m 12G \ -enable-kvm \ -cpu host \ -drive file/tmp/_images/ginkgo-tests.qcow2,ifvirtio,index0,mediadisk \ -netdev user,iduser.0,hostfwdtcp::2222-:22 \ -device virtio-net-pci,netdevuser.0 \ -fsdev local,idhost_id,path./,security_modelnone \ -device virtio-9p-pci,fsdevhost_id,mount_taghost_mount \ -serial mon:stdio3.4 VM 内安装依赖并供给 Kind$ ssh -p 2222 -o StrictHostKeyCheckingno rootlocalhost # echo nameserver 8.8.8.8 /etc/resolv.conf # git config --global --add safe.directory /host # cp /host/helm /usr/bin与 GitHub Action 一样CI 在 VM 内用 Kind 跑集群。Kind 的供给方式取决于内核版本——bpf-next 下的供给方式与其他内核不同$ ssh -p 2222 -o StrictHostKeyCheckingno rootlocalhost # cd /host/ # kernel_tagbpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411 # kubernetes_imagekindest/node:v1.27.1sha256:b7d12ed662b873bd8510879c1846e87c7e676a79fefc93e17b2a52989d3ff42b # ip_familydual # replace with ipv4 if k8s 1.19 # # if [[ ${kernel_tag} bpf-next-* ]]; then # ./contrib/scripts/kind.sh 2 ${kubernetes_image} none ${ip_family} # kubectl label node kind-worker2 cilium.io/ci-nodekind-worker2 # # Avoid re-labeling this node by setting node-role.kubernetes.io/controlplane # kubectl label node kind-worker2 node-role.kubernetes.io/controlplane # else # ./contrib/scripts/kind.sh 1 ${kubernetes_image} iptables ${ip_family} # fi # git config --global --add safe.directory /cilium验证 Kind 已在 VM 内运行$ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-787d4945fb-hqzpb 0/1 Pending 0 42s kube-system etcd-kind-control-plane 1/1 Running 0 57s kube-system kube-apiserver-kind-control-plane 1/1 Running 0 57s kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 56s kube-system kube-scheduler-kind-control-plane 1/1 Running 0 56s local-path-storage local-path-provisioner-6bd6454576-648bk 0/1 Pending 0 42s3.5 在 VM 内执行测试先取 focus 正则在 .github/actions/ginkgo/main-focus.yaml 中f10-agent-hubble-bandwidth对应的cliFocus为K8sAgentHubbleTest仓库当前配置文件中可确认该映射依然存在。运行前面编译出的test.test。该命令与 GitHub workflow 完全一致唯一区别是额外加了-cilium.holdEnvironmenttrue——测试失败时保留测试环境以便进一步诊断。从源码看这个开关在 test_suite_test.go 中生效if config.CiliumTestConfig.HoldEnvironment { RegisterFailHandler(helpers.Fail) } else { RegisterFailHandler(Fail) }helpers.Fail会标记失败但不拆除环境而 Ginkgo 原生Fail会触发 panic 并进入清理流程。$ ssh -p 2222 -o StrictHostKeyCheckingno rootlocalhost # cd /host/test # kernel_tagbpf-next-20230526.105339sha256:4133d4e09b1e86ac175df8d899873180281bb4220dc43e2566c47b0241637411 # k8s_version1.27 # # export K8S_NODES2 # export NETNEXT0 # export K8S_VERSION${k8s_version} # export CNI_INTEGRATIONkind # export INTEGRATION_TESTStrue # # if [[ ${kernel_tag} bpf-next-* ]]; then # export KERNELnet-next # export NETNEXT1 # export KUBEPROXY0 # export K8S_NODES3 # export NO_CILIUM_ON_NODESkind-worker2 # elif [[ ${kernel_tag} 5.4-* ]]; then # export KERNEL54 # fi # # # GitHub actions do not support IPv6 connectivity to outside # # world. If the infrastructure environment supports it, then # # this line can be removed # export CILIUM_NO_IPV6_OUTSIDEtrue # # commit_sha7b368923823e63c9824ea2b5ee4dc026bc4d5cd8 # cliFocusK8sAgentHubbleTest # quay_orgcilium # # ./test.test \ --ginkgo.focus${cliFocus} \ --ginkgo.skip \ --ginkgo.seed1679952881 \ --ginkgo.v -- \ -cilium.imagequay.io/${quay_org}/cilium-ci \ -cilium.tag${commit_sha} \ -cilium.operator-imagequay.io/${quay_org}/operator \ -cilium.operator-tag${commit_sha} \ -cilium.hubble-relay-imagequay.io/${quay_org}/hubble-relay-ci \ -cilium.hubble-relay-tag${commit_sha} \ -cilium.kubeconfig/root/.kube/config \ -cilium.operator-suffix-ci \ -cilium.holdEnvironmenttrue Using CNI_INTEGRATIONkind Running Suite: Suite-k8s-1.27 Random Seed: 1679952881 Will run 7 of 132 specs注意几处环境变量的语义bpf-next内核时不设 kube-proxyKUBEPROXY0、节点数扩到 3并把kind-worker2列入NO_CILIUM_ON_NODES——该节点专门用于验证无 Cilium 节点场景test/helpers/kubectl.go 中可见NO_CILIUM_ON_NODE会参与 Cilium 调度与日志采集器的节点选择逻辑。等待执行完成预期输出Ran 7 of 132 Specs in 721.007 seconds SUCCESS! -- 7 Passed | 0 Failed | 0 Pending | 125 Skipped3.6 清理与环境复用测试结束后终止 Qemu 即可停止 VM$ pkill qemu-system-x86VM 状态保存在/tmp/_images/ginkgo-tests.qcow2中依赖也已安装完毕。因此下次运行时可以直接从供给 Kind这一步开始跳过依赖下载与 VM 供给实现环境状态复用。四、Runtime 测试单节点快速执行在test/目录下执行全部 runtime 测试INTEGRATION_TESTStrue ginkgo --focusRuntimeGinkgo 会在所有子目录中查找名称以Runtime开头且其后还有任意字符的测试。用--dryRun可以只做匹配演练而不真正执行$ INTEGRATION_TESTStrue ginkgo --focusRuntime -dryRun Running Suite: runtime Random Seed: 1516125117 Will run 42 of 164 specs ................ RuntimePolicyEnforcement Policy Enforcement Always Always to Never with policy /Users/ianvernon/go/src/github.com/cilium/cilium/test/runtime/Policies.go:258 • ------------------------------ ... Ran 42 of 164 Specs in 0.002 seconds SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 122 Skipped PASS Ginkgo ran 1 suite in 1.830262168s Test Suite Passed五、CLI 选项全览-cilium.help在test/目录下直接查看 Cilium 框架注册的全部自定义选项$ cd test/ $ ginkgo . -- -cilium.help文档中记录的选项如下选项说明-cilium.SSHConfig string指定获取 SSH 配置的命令如vagrant ssh-config-cilium.help显示帮助信息-cilium.holdEnvironment失败时保留环境现场-cilium.hubble-relay-image/-cilium.hubble-relay-tag测试使用的 hubble-relay 镜像与 tag-cilium.image/-cilium.tag测试使用的 cilium 镜像与 tag-cilium.kubeconfigk8s 测试使用的 kubeconfig-cilium.multinode启用多节点测试禁用后多节点检查可能被静默跳过默认true-cilium.operator-image/-cilium.operator-tagcilium-operator 镜像与 tag-cilium.passCLIEnvironment将调用 ginkgo 的环境含 PATH传递给子命令-cilium.showCommands把执行的命令打印到 stdout-cilium.skipLogs测试失败时跳过日志收集-cilium.testScope指定测试 scopek8s, runtime-cilium.timeout duration测试运行超时默认 24h需要注意当前源码中ParseFlags()还注册了文档未列出的若干选项见 test/config/config.go-cilium.kubectl-path版本相关 kubectl 二进制的存放路径默认/tmp/kubectl-cilium.registryCredentials拉取私有镜像的 registry 凭据-cilium.install-helm-overrides以逗号分隔的cilium install helm --set覆盖项优先级高于测试自身设置的任何值-cilium.extra-opts原样透传给cilium-agent启动的额外选项。-cilium.help的实现方式是扫描os.Args命中-cilium.help时打印flagset默认值后退出ParseFlags()中会先剥离所有含-cilium的参数再解析因此它输出的是源码注册表永远与当前代码同步。六、精确选择测试与纯编译校验6.1 通过代码聚焦给目标测试加FIt前缀即可Ginkgo 的 Focused Specs 机制会跳过其余测试It(Example test, func(){ Expect(true).Should(BeTrue()) }) FIt(Example focused test, func(){ Expect(true).Should(BeTrue()) })6.2 通过命令行聚焦--focus接受正则表达式含空格时必须加引号*也需避免被 shell 展开INTEGRATION_TESTStrue ginkgo --focus Runtime.*L76.3 只编译不运行验证测试代码语法正确而不跑完整套件make -C test/ build七、构建并更新本地 Cilium 测试镜像开发中常需要把改过的 Cilium 推给 CI 环境。文档给出在k8s1VM 上的操作源自早期的test/provision/compile.sh脚本该脚本路径在仓库中已不保留cd go/src/github.com/cilium/cilium make LOCKDEBUG1 docker-cilium-image docker tag quay.io/cilium/cilium:latest \ k8s1:5000/cilium/cilium-dev:latest docker push k8s1:5000/cilium/cilium-dev:latest make -B LOCKDEBUG1 docker-operator-generic-image docker tag quay.io/cilium/operator-generic:latest \ k8s1:5000/cilium/operator-generic:latest docker push k8s1:5000/cilium/operator-generic:latest当前 test/Makefile 中保留了更现成的k8s-kind目标它会自动从kubectl version取 K8S_VERSION、固定DOCKER_REGISTRYlocalhost:5000并指定本地镜像cilium/cilium-dev:localFOCUSK8sFoo make k8s-kind # 等价于 # CNI_INTEGRATIONkind K8S_VERSION... NETNEXT... KUBEPROXY1 \ # NO_CILIUM_ON_NODES... INTEGRATION_TESTStrue ginkgo --focus $(FOCUS) -v -- \ # -cilium.testScopek8s -cilium.kubeconfig$$(echo ~/.kube/config) \ # -cilium.passCLIEnvironmenttrue -cilium.imagelocalhost:5000/cilium/cilium-dev \ # -cilium.taglocal -cilium.operator-imagequay.io/cilium/operator \ # -cilium.operator-suffix-ci -cilium.holdEnvironmenttrue八、JUnit 测试报告与调试8.1 JUnit 报告Cilium 的 Ginkgo 框架为每个测试生成 JUnit 报告。文档记录的输出文件为runtime.xml与K8s.xml。从源码看报告名实际由 scope 拼接版本动态生成见 test_suite_test.gojunitReporter : NewJUnitReporter(fmt.Sprintf( %s.xml, helpers.GetScopeWithVersion()))因此 K8s 套件会产出类似K8s-1.27.xml的文件k8s-*.xml也列入 Makefile 的TEST_ARTIFACTS清理清单。8.2 测试日志目录所有执行过的命令及其输出保存在报告目录./test/test_results每个测试创建独立文件夹内含log文件保存全部信息失败测试会追加详尽数据。例如$ head test/test_results/RuntimeKafkaKafkaPolicyIngress/logs levelinfo msgStarting testNameRuntimeKafka levelinfo msgVagrant: running command \vagrant ssh-config runtime\ cmd: sudo cilium-dbg status exitCode: 0 KVStore: Ok Etcd: 172.17.0.3:4001 Kubernetes: Disabled ...8.3 用 Delve 调试在测试代码中插入runtime.BreakPoint()断点然后用dlv运行 ginkgodlv test . -- --ginkgo.focusRuntime -ginkgo.vtrue此外 test_suite_test.go 的init()还会启动gopsagent 监听 socket在测试死锁时可用于抓取 stack trace——这与后文JustAfterEach用于死锁检测的设计互为呼应。九、Ginkgo 扩展BeforeAll / AfterAll / JustAfterEach / AfterFailedCilium 在test/ginkgo-ext包中扩展了 Ginkgo补齐了 Ginkgo 原版缺失的容器级一次性 setup/teardown能力。实现集中在 test/ginkgo-ext/scopes.go其核心是一个scope 树BeforeAll在某个Describe/Context内所有BeforeEach之前执行一次等价于常见框架的SetUpAfterAll在该容器内所有It跑完、所有AfterEach执行完毕后再运行用于拆除被多个It共享的容器/Pod 等资源JustAfterEach紧跟每个测试之后、AfterFailed与AfterEach之前运行适合做一组测试的统一断言例如死锁检测检查测试期间 Cilium 日志是否出现死锁AfterFailed位于JustAfterEach之后、AfterEach之前仅当测试失败时调用用于收集日志、Cilium 状态等失败分析数据。文档给出的测试布局示例Describe BeforeAll(A) AfterAll(A) AfterFailed(A) AfterEach(A) JustAfterEach(A) TESTA1 TESTA2 TESTA3 Context BeforeAll(B) AfterAll(B) AfterFailed(B) AfterEach(B) JustAfterEach(B) TESTB1 TESTB2 TESTB3执行流程Describe BeforeAll TESTA1; JustAfterEach(A), AfterFailed(A), AfterEach(A) TESTA2; JustAfterEach(A), AfterFailed(A), AfterEach(A) TESTA3; JustAfterEach(A), AfterFailed(A), AfterEach(A) Context BeforeAll(B) TESTB1: JustAfterEach(B); JustAfterEach(A) AfterFailed(B); AfterFailed(A); AfterEach(B) ; AfterEach(A); TESTB2: 同 TESTB1 TESTB3: 同 TESTB1 AfterAll(B) AfterAll(A)源码级实现要点scopes.gowrapContextFunc在注册Describe/Context时创建新的scope节点记录父指针、测试计数器、失败标记It/Measure经由wrapItFunc/wrapMeasureFunc计入所在 scope 的normalTests/focusedTestscalculateCounters在BeforeSuite阶段递归统计本次会运行多少测试AfterAll只有在对应 scope 计数器归零cs.isZero()且所有AfterEach执行完毕后才触发——这就是等所有 It 跑完的实现RunAfterEach统一编排收尾顺序runAllJustAfterEach→runAllAfterFail→runAllAfterEach→ 若AfterEach中出错则补跑AfterFailed→ 最后才可能是AfterAll与文档流程图逐行对应FailWithToggle包内导出为Fail在AfterEach阶段被调用时不会立即 panicfailEnabled false而是把失败记入afterEachFailed在全部收尾函数跑完后才真正ginkgo.Fail保证失败日志收集不被中断——这是-cilium.skipLogs、AfterFailed等机制能稳定工作的底层保障。同包还提供条件跳过工具SkipDescribeIf、SkipContextIf、SkipItIf以及Failf格式化失败函数供测试代码按条件整体跳过容器或用例。十、测试编写最佳实践用By输出信息性步骤日志降低他人理解测试的门槛。源码中By会带时间戳前缀写入GinkgoWriterscopes.go 中的By()实现保持环境原状测试结束时删除资源、重置配置恢复到开始前的状态失败必留日志Ginkgo 失败后必须做 postmortem把日志 dump 到 Ginkgo 能收集的位置。在AfterFailed中使用AfterFailed(func() { vm.ReportFailed() })十一、kubeconfig 模式在任意既有集群上运行通过--cilium.kubeconfig指定任意 kubeconfig 即可运行端到端测试此时框架跳过环境供给与节点打标签等准备工作。该模式的预期前提当前目录是cilium/test必须传--focus如--focusK8s选中全部 K8s 测试若 focus 不覆盖 scope则需另传-cilium.testScopeK8s用--cilium.image与--cilium.operator-image以完整 URL 形式提供 Cilium 镜像可用的 kubeconfig 通过--cilium.kubeconfig提供设置K8S_VERSION环境变量与集群版本一致源码中经helpers.GetCurrentK8SEnv()读取视环境设置CNI_INTEGRATION为gke、eks、eks-chaining、microk8s或minikube之一以选中匹配的 Cilium 配置覆盖项不匹配时留空也是正确做法。集成常量定义见 test/helpers/kubectl.go如CIIntegrationKind kind对 EKS 这类需要认证代理如aws-iam-authenticator的环境设置--cilium.passCLIEnvironmenttrue。通用示例EKS 风格INTEGRATION_TESTStrue CNI_INTEGRATIONeks K8S_VERSION1.16 ginkgo --focusK8s -- \ -cilium.kubeconfigecho ~/.kube/config \ -cilium.imagequay.io/cilium/cilium-ci \ -cilium.operator-imagequay.io/cilium/operator \ -cilium.operator-suffix-ci \ -cilium.passCLIEnvironmenttrue本地 Kind 示例对应第七节的本地镜像K8S_VERSION1.25 ginkgo --focusK8s -- \ --cilium.imagelocalhost:5000/cilium/cilium-dev -cilium.taglocal \ --cilium.operator-imagelocalhost:5000/cilium/operator -cilium.operator-taglocal \ --cilium.kubeconfigecho ~/.kube/config \ -cilium.testScopeK8s -cilium.operator-suffix从源码看kubeconfig 模式下BeforeAll依然会执行 K8s scope 的初始化链路PrepareCluster()集群准备、CleanupCiliumComponents()清理上一次本地运行残留的 Cilium 组件、应用 Prometheus 监控示例examples/kubernetes/addons/prometheus/monitoring-example.yaml并启动PprofReport()协程。GKE按 Kubernetes 安装文档建集群或复用现有集群。无需手动部署 Cilium框架会负责部署节点规格要求大于n1-standard-4建集群时--machine-type指定测试要求NATIVE_CIDR环境变量等于gcloud container clusters describe返回的集群 IPv4 CIDR。export CLUSTER_NAMEcluster1 export CLUSTER_ZONEus-west2-a export NATIVE_CIDR$(gcloud container clusters describe $CLUSTER_NAME \ --zone $CLUSTER_ZONE --format value(clusterIpv4Cidr)) INTEGRATION_TESTStrue CNI_INTEGRATIONgke K8S_VERSION1.17 ginkgo --focusK8sDemo -- \ -cilium.kubeconfigecho ~/.kube/config \ -cilium.imagequay.io/cilium/cilium-ci \ -cilium.operator-imagequay.io/cilium/operator \ -cilium.operator-suffix-ci \ -cilium.hubble-relay-imagequay.io/cilium/hubble-relay-ci \ -cilium.passCLIEnvironmenttrue文档注明 K8s 版本默认 1.23可配置范围为 1.161.23且应与kubectl version报告的 server 版本一致此为文档历史说明当前代码中DefaultSettings的K8S_VERSION默认值已是 1.36。AKS实验性同样要求设置NATIVE_CIDR且无需预装 Ciliumexport NATIVE_CIDR10.241.0.0/16 INTEGRATION_TESTStrue CNI_INTEGRATIONaks K8S_VERSION1.17 ginkgo --focusK8s -- \ -cilium.kubeconfigecho ~/.kube/config -cilium.passCLIEnvironmenttrue \ -cilium.imagemcr.microsoft.com/oss/cilium/cilium -cilium.tag1.12.1 \ -cilium.operator-imagemcr.microsoft.com/oss/cilium/operator \ -cilium.operator-suffix -cilium.operator-tag1.12.1AWS EKS实验性并非所有测试都能在 EKS 上成功但相当一部分可以运行且仍有价值文档指向 GitHub issue #9678 的评论作为仍失败用例的清单。步骤建集群或复用现有集群同样无需预装 Ciliumsourcecontrib/testing/integrations.sh测试集成脚本调用gks函数传入 Cilium 镜像与 focus也可追加 ginkgo 参数gks quay.io/cilium/cilium:latest K8sDemo新增托管 Kubernetes Provider 的步骤所有托管 K8s 测试支持都基于预配置 kubeconfig但往往需要 provider 专属默认值。文档以当年添加 GKE 支持的提交为参照给出四步扩展流程涉及文件均为当前仓库可定位的 test/helpers/kubectl.go 与test/helpers包在该 provider 的 helm 设置覆盖表中新增一项生成该 provider 的 cilium specs 时使用的 helm 参数新增唯一的CI Integration常量经CNI_INTEGRATION环境变量传入 ginkgo更新 helm overrides 映射把常量与 helm 设置关联需要按条件跳过用例时用SkipIfIntegration跳过整个 Context 用SkipContextIf更复杂的逻辑用IsIntegration一类函数表达——它们都位于test/helpers包容器级跳过则由 ginkgo-ext 的SkipContextIf/SkipDescribeIf实现。十二、SSH 模式在任意可 SSH 环境运行用--cilium.SSHConfig提供测试目标机器的 SSH 配置。测试假定远程实例满足Cilium 源码位于/home/$USER/go/src/github.com/cilium/cilium/Cilium 已安装并正在运行。ssh-config文件需要定义以下目标runtime运行 runtime 测试k8s{1..2}-${K8S_VERSION}运行 Kubernetes 测试实例须已装好并运行 Kubernetes。示例ssh-configHost runtime HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile /home/eloy/.go/src/github.com/cilium/cilium/test/.vagrant/machines/runtime/virtualbox/private_key IdentitiesOnly yes LogLevel FATAL运行命令-cilium.SSHConfig的值是获取 ssh-config 的命令与 config.go 中该 flag 的描述一致ginkgo -- --cilium.SSHConfigcat ssh-config从 test_suite_test.go 的BeforeAll可印证该模式的行为一旦设置了SSHConfig框架直接return不再执行 VM 供给与集群准备逻辑——即完全信任远端环境已就绪。十三、环境变量速查表文档记录的常用环境变量ENV 变量默认值取值说明K8S_NODES20..100集群中的 Kubernetes 节点数NO_CILIUM_ON_NODE[S]无*不应运行 Cilium 的 K8s 节点逗号分隔K8S_VERSION1.181.18安装的 Kubernetes 版本KUBEPROXY10-1为 0 时不安装 kube-proxy两处源码补充test/Makefile 在k8s-kind目标中默认KUBEPROXY1、NO_CILIUM_ON_NODES为空串并透传NETNEXTtest_suite_test.go 的DefaultSettings会把未设置的K8S_VERSION兜底为1.36即当前仓库默认值文档表格中的 1.18 为历史默认。十四、失败排查与进一步支持现场保留加-cilium.holdEnvironmenttrue失败后环境不拆解可kubectl直接进集群诊断对应helpers.Fail不 panic 的机制命令留痕-cilium.showCommands会把所有执行的命令打印到 stdout配合test/test_results/TestName/下的log与cmds.log源码中AfterEach会将SSHMetaLogs落盘为cmds.log还原完整执行轨迹日志收集开关-cilium.skipLogs可跳过失败时的日志收集以加快迭代死锁/挂起JustAfterEach中内置的死锁检测 init()启动的 gops agent双管齐下定位 hang 住的测试文档建议对测试框架机制有疑问或想改进测试基础设施时可到 Cilium Slack 的#testing频道交流。结语这份遗留 Ginkgo E2E 框架文档的价值在于它完整描述了一套CI 可复现、多环境可插拔的端到端测试体系——GHA 相似模式保证本地与 CI 结果一致kubeconfig/SSH 模式把同一套用例投射到 GKE、AKS、EKS 等真实环境而ginkgo-ext包用 scope 树 有序收尾钩子解决了 Ginkgo v1 缺乏容器级 setup/teardown 的历史缺陷。即便新测试已迁移到cilium-cliconnectivity 框架理解这套机制仍然是阅读 Cilium 历史用例、排查 CI 失败、扩展托管云 provider 支持的基础。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考