服务网格云原生可观测性【免费下载链接】linkerd2Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.项目地址https://gitcode.com/gh_mirrors/li/linkerd2点击查看免费下载policy-testlinkerd-policy-test是 Linkerd 2.x 仓库中专门为**策略控制器policy controller**编写的 Rust 集成测试 crate它通过真实 Kubernetes 集群本地 k3d 或 CI 集群验证策略控制器对各类策略资源的准入校验、路由状态上报与出入站 gRPC 策略下发行为。本文以 policy-test/README.md 为主线结合仓库源码梳理该 crate 的定位、测试组织方式、运行入口just policy-test以及本地与 CI 两种执行路径帮助读者理解并上手这套测试体系。一、policy-test 是什么定位与核心目标policy-test/README.md 开宗明义地指出Thepolicy-testcrate includes integration tests for the policy controller——即这个 crate 的全部职责就是为 Linkerd 的策略控制器提供集成测试。它并不测试代理proxy本身也不测试 CLI 或仪表盘而是聚焦于策略控制器这一核心组件。从仓库结构看policy-test 与策略控制器的实现代码Rust 编写相邻而居策略控制器实现policy-controller/包含core/、grpc/、k8s/等子 crate策略控制器集成测试policy-test/本主题。两者的依赖关系在 policy-test/Cargo.toml 中一目了然linkerd-policy-controller-core { path ../policy-controller/core } linkerd-policy-controller-k8s-api { path ../policy-controller/k8s/api } linkerd-policy-controller-grpc { path ../policy-controller/grpc }即测试 crate 直接依赖策略控制器的核心逻辑、Kubernetes API 类型封装和 gRPC 服务定义这使得测试既可以驱动真实的 API Server 校验策略资源也可以通过 gRPC 客户端断言控制器下发的策略。一句话概括其价值在真实集群环境中端到端地确认用户创建的 Server、AuthorizationPolicy、HttpRoute、EgressNetwork 等资源能否被策略控制器正确接受/拒绝并转化为代理可见的策略配置。二、crate 的组成src 公共工具库与 tests 测试套件policy-test 目录内部划分为两层这种公共测试工具 独立测试用例的结构是 Rust 集成测试的标准做法policy-test/ ├── Cargo.toml # crate 元信息与 feature 开关 ├── README.md # 运行说明本文主体 ├── src/ # 可复用的测试工具库对外导出为 linkerd_policy_test │ ├── lib.rs # 公共 API命名空间管理、资源创建/删除/等待等 │ ├── admission.rs # 准入测试辅助accepts / rejects │ ├── bb.rs # blocks/breaks 测试辅助 │ ├── curl.rs # 在集群内运行 curl 并发起 HTTP 请求 │ ├── grpc.rs # 策略 gRPC 客户端inbound/outbound │ ├── outbound_api.rs │ ├── test_route.rs # 路由状态测试抽象 │ └── web.rs # 构造 web 测试工作负载Service/Pod └── tests/ # 实际集成测试用例每个文件一组主题 ├── admit_*.rs # 准入测试Server、ServerAuthorization、各类 Route 等 ├── e2e_*.rs # 端到端测试授权策略、HTTP 路由、限流等 ├── inbound_api*.rs / outbound_api*.rs # gRPC 策略 API 测试 └── ...2.1 src/lib.rs一切测试的地基policy-test/src/lib.rs 是测试公共库的入口其模块声明为pub mod admission; pub mod bb; pub mod curl; pub mod grpc; pub mod outbound_api; pub mod test_route; pub mod web;其中几个关键基础设施值得展开1. 临时命名空间机制with_temp_nslib.rs。几乎每个测试都以with_temp_ns(|client, ns| async move { ... })的形式运行它初始化一个 Kubernetes 客户端创建一个名为linkerd-policy-test-XXXXXX6 位随机小写字母数字后缀的命名空间等待 default ServiceAccount 就绪后执行测试闭包测试结束自动删除命名空间。这保证了测试之间互不干扰。两个环境变量控制其行为POLICY_TEST_CONTEXT指定 kubeconfig 中的 context缺省时用kube::Client::try_default()POLICY_TEST_NO_CLEANUP设置后保留测试命名空间便于失败后现场排查。2. 资源的创建/删除/更新辅助lib.rs。提供create、delete、update等泛型函数统一以linkerd-policy-test作为 field managerPostParams { field_manager: Some(linkerd-policy-test) }创建对象时用tracing::trace!(?obj, Creating)记录日志。对集群级资源如 Namespace则使用create_cluster_scoped/delete_cluster_scoped。3. 条件等待工具lib.rs。await_condition基于 kube 的kube::runtime::wait::await_condition封装超时 60 秒time::timeout( time::Duration::from_secs(60), kube::runtime::wait::await_condition(api, name, cond), ) .await .expect(condition timed out) .expect(API call failed)在此基础上派生了大量语义化等待函数create_ready_pod创建 Pod 并等待所有容器 ready见 lib.rs、await_pod_ip、await_route_acceptedHttpRoute 被策略控制器接受、await_gateway_route_status、await_grpc_route_status、await_tls_route_status、await_egress_net_status等以及endpoints_ready判断 Endpoints 是否已填充地址lib.rs。这些函数大量使用is_status_accepted检查资源的AcceptedTrue状态条件lib.rs。4. 服务与 EgressNetwork 构造器lib.rs。create_service、create_opaque_service带config.linkerd.io/opaque-ports注解、create_egress_network、create_annotated_service等直接构造并提交测试资源。默认的 EgressNetwork 使用TrafficPolicy::Allowlib.rs。2.2 admission.rs准入测试的两板斧policy-test/src/admission.rs 极其精简但非常关键它把资源能否通过准入校验抽象成两个函数accepts(f)在临时命名空间内创建资源并断言api.create(...)成功rejects(f)在临时命名空间内创建资源并断言api.create(...)失败res.expect_err(resource must not apply)。所有admit_*测试文件都是在这两个函数之上编写的。例如测试一个合法的 Server 应被接受、一个引用了不存在 Service 的 Server 应被拒绝等。2.3 grpc.rs直连策略 gRPC APIpolicy-test/src/grpc.rs 实现了一个策略 gRPC 客户端通过 Kubernetes API 发现 destination 控制器 Pod再利用 port-forward 连接运行中的实例进而调用InboundServerPoliciesClientinbound 服务器策略OutboundPoliciesClientoutbound 策略。该客户端还导出了两个断言宏用于校验默认策略的形状grpc.rsassert_is_default_all_unauthenticated!($config); // 断言 labels 正确且仅含 1 条 all-unauthenticated 授权 assert_default_all_unauthenticated_labels!($config); // 断言 labels 为 (group,)、(kind,default)、(name,all-unauthenticated)这组工具支撑了inbound_api*.rs、outbound_api*.rs等文件中对策略控制器 gRPC 输出的直接断言。2.4 curl.rs / web.rs / bb.rs端到端流量测试的抓手curl.rs在集群内启动 curl Pod向目标 URL 发起 HTTP 请求并收集状态码/响应是验证策略真正生效于数据面的关键手段web.rs构造标准的 web 测试工作负载Service Pod供 e2e 测试复用bb.rs提供blocks/breaks类辅助用于构造破坏性/边界场景。三、tests/ 目录四类测试主题policy-test/tests/下共有 30 个集成测试文件按文件名前缀可清晰分为四类类别文件节选验证目标准入校验admit_authorization_policy.rs、admit_server.rs、admit_server_authorization.rs、admit_egress_networks.rs、admit_network_authentication.rs、admit_meshtls_authentication.rs、admit_http_route.rs、admit_http_route_gateway.rs、admit_grpc_route.rs、admit_tcp_route.rs、admit_tls_route.rs、admit_http_local_ratelimit_policy.rs各种策略/路由资源的 Webhook 准入合法资源被接受、非法资源被拒绝端到端流量e2e_authorization_policy.rs、e2e_http_routing.rs、e2e_server_authorization.rs、e2e_egress_network.rs、e2e_failure_accrual.rs、e2e_http_local_ratelimit_policy.rs、e2e_appprotocol.rs、e2e_audit.rs通过真实 Pod curl 验证策略在数据面实际生效入站策略 APIinbound_api.rs、inbound_api_external_workload.rs、inbound_http_route_status.rs通过 gRPC 断言入站服务器策略内容与 HttpRoute 状态出站策略 APIoutbound_api.rs、outbound_api_http.rs、outbound_api_grpc.rs、outbound_api_tcp.rs、outbound_api_app_protocol.rs、outbound_api_egress_network.rs、outbound_api_failure_accrual.rs、outbound_http_route_status.rs通过 gRPC 断言出站策略HTTP/gRPC/TCP/Egress 等以e2e_http_routing.rs为例其测试流程完整呈现了建资源 → 起工作负载 → 发请求 → 断言结果的端到端模式e2e_http_routing.rs#[tokio::test(flavor current_thread)] async fn path_based_routing() { with_temp_ns(|client, ns| async move { // 1. 创建 policy.linkerd.io 的 HttpRoute/valid 路由到 web/invalid 路由到不存在的 foobar create(client, k8s::policy::HttpRoute { /* parent_refs 指向 core Service web端口 80 ... */ }).await; // 2. 创建 web Service 与 Pod并等待 Endpoints 就绪 tokio::join!( create(client, web::service(ns)), create_ready_pod(client, web::pod(ns)) ); await_condition(client, ns, web, endpoints_ready).await; // 3. 用集群内 curl 分别请求 /valid、/invalid、/notfound let curl curl::Runner::init(client, ns).await; let (valid, invalid, notfound) tokio::join!( curl.run(curl-valid, http://web/valid, LinkerdInject::Enabled), curl.run(curl-invalid, http://web/invalid, LinkerdInject::Enabled), curl.run(curl-notfound, http://web/notfound, LinkerdInject::Enabled), ); // 4. 断言各请求的 HTTP 状态码 let (valid_status, invalid_status, notfound_status) tokio::join!( valid.http_status_code(), invalid.http_status_code(), notfound.http_status_code() ); // ... 期望 /valid 成功、/invalid 与 /notfound 被路由规则拒绝 }).await; }可以看到测试会主动向策略控制器提交policy.linkerd.io/HttpRoute并用LinkerdInject::Enabled控制请求方是否注入 sidecar从而区分不同数据面行为。四、如何运行just policy-test一站式入口README 给出了本地运行方式一行命令即可:; just policy-test这行命令背后是 justfile 中的一个复合配方它把整套流程串联了起来policy-test: linkerd-install policy-test-deps-load policy-test-run policy-test-cleanup linkerd-uninstall即依次执行安装 Linkerd → 加载测试依赖镜像 → 运行测试 → 清理测试命名空间 → 卸载 Linkerd。配方中用到POLICY_TEST_CONTEXT环境变量默认指向k3d-k3d-name这个 k3d 集群 contextjustfile。4.1 子配方拆解justfile 中还有几个可以单独调用的子配方policy-test-run *flags只跑测试不装 Linkerdjustfile。实际执行cd policy-test cargo test feature-flags flagspolicy-test-build只编译测试cargo test --no-run用于提前暴露编译错误justfilepolicy-test-cleanup删除所有带linkerd-policy-test标签的命名空间并轮询等待删除完成justfile{{ _kubectl }} delete ns --selectorlinkerd-policy-test while [ $({{ _kubectl }} get ns --selectorlinkerd-policy-test -o json |jq .items | length) ! 0 ]; do sleep 1 ; donepolicy-test-deps-pull/policy-test-deps-load拉取并导入测试所需的镜像justfile包括chainguard/kubectl:latest-dev、curlimages/curl:latest、fortio/fortio:latest、ghcr.io/olix0r/hokay:latest等其中镜像加载带有重试逻辑失败后 sleep 1 重试最多 3 次。4.2 feature 开关Gateway API 版本适配由于不同版本的 Gateway API bundle 提供不同的 API 版本policy-test 通过 Cargo feature 控制测试范围policy-test/Cargo.toml[features] default [gateway-api-experimental, gateway-api-tls-route-v1] gateway-api-experimental [] # 启用仅存在于 Gateway API experimental 通道的资源测试 gateway-api-tls-route-v1 [gateway-api-tls-route] # 按 v1 版本测试 TLSRoute gateway-api-tls-route-v1alpha2 [gateway-api-tls-route] # 按 v1alpha2 版本测试 TLSRoute gateway-api-tls-route [] # 隐含标记TLSRoute 测试开启不应单独启用为什么 TLSRoute 需要如此细致的开关Cargo.toml 中的注释解释得很清楚TLSRoute 没有任何一个版本能被所有受支持的 Gateway API bundle 提供——v1alpha2是 v1.2~v1.4 以及 linkerd-crds chart 内嵌 CRD 唯一提供的版本而v1是 v1.5 标准通道唯一提供的版本。因此测试必须按实际部署的 Gateway API 版本用gateway-api-tls-route-v1或gateway-api-tls-route-v1alpha2来对齐要寻址的版本。对应地lib.rs 中用条件编译在两种 TLSRoute 类型之间做别名切换#[cfg(all(feature gateway-api-tls-route, not(feature gateway-api-tls-route-v1alpha2)))] pub use linkerd_policy_controller_k8s_api::gateway::TLSRoute; #[cfg(feature gateway-api-tls-route-v1alpha2)] pub use linkerd_policy_controller_k8s_api::gateway::TLSRouteV1Alpha2 as TLSRoute;justfile 会根据环境变量GATEWAY_API_TLS_ROUTE取值v1/v1alpha2/none和GATEWAY_API_CHANNELexperimental或其他动态拼出 feature 参数justfile_policy-test-flags : --no-default-features (if GATEWAY_API_CHANNEL experimental { --featuresgateway-api-experimental } else { }) _policy-test-tls-route-flags可见默认启用--no-default-features由外部显式指定测试目标版本以保证测试与集群中实际部署的 Gateway API 版本严格一致。五、在 CI 中如何运行README 提到 CI 运行方式参见工作流 integration.yml。该工作流中的 policy-test job 展示了完整的 CI 执行链integration.yml准备环境安装指定版本的 Rust 工具链、k3d、yq、cargo-nextest预编译just policy-test-build先编译测试避免运行阶段暴露编译问题创建测试集群just k3d-k8smatrix 版本 k3d-create并在不同 Kubernetes 版本矩阵上运行安装 Linkerd加载构建产物中的 controller/proxy 镜像后执行just linkerd-install加载依赖镜像policy-test-deps-load带有重试循环失败后 sleep 10 秒重试最多 6 次并注释说明镜像加载在 CI 中容易失败所以要重试运行测试just policy-test-run --jobs1并设置NEXTEST_RETRIES: 3让不稳定用例自动重试 3 次nexte.st 的 retries 机制。其中--jobs1与 nextest 的重试设置说明这套集成测试在真实集群环境下具有一定时序敏感性通过串行执行与自动重试来提高结果可靠性。六、自定义与调试实践综合以上源码细节可以总结出几条实用技巧指定集群 context本地有多个集群时用POLICY_TEST_CONTEXTcontext覆盖默认的k3d-name指向保留现场测试失败想排查时设置POLICY_TEST_NO_CLEANUP1命名空间与其中资源会保留with_temp_ns仅在未设置该变量时删除命名空间见 lib.rs同时with_temp_ns在测试失败后会自动打印命名空间内所有 Pod 的reason/message与各容器状态便于定位单独编译仅想验证代码可编译时使用just policy-test-build只跑测试集群已就绪、Linkerd 已安装时用just policy-test-run --jobs1直接执行配合NEXTEST_RETRIES处理偶发不稳定调整 Gateway API 目标版本根据集群部署的 Gateway API 版本设置GATEWAY_API_TLS_ROUTEv1|v1alpha2|none与GATEWAY_API_CHANNELexperimental|standard查看详细日志测试库默认的日志过滤为trace,towerinfo,hyperinfo,kubeinfo,h2infolib.rs可通过RUST_LOG覆盖帮助跟踪资源创建、等待条件与 gRPC 断言过程。七、总结policy-test 是 Linkerd 策略控制器质量保障的核心支柱。它以真实集群 真实流量的方式把策略控制器的准入校验、路由状态上报与 gRPC 策略下发三条链路全部纳入自动化测试通过临时命名空间、条件等待、feature 化版本适配等设计兼顾了测试的隔离性、稳定性和对不同 Gateway API 版本的兼容性。无论你是想为策略控制器贡献新测试还是想理解 Linkerd 策略体系的行为policy-test/README.md 与 policy-test/ 目录下的源码都是最佳起点。赞分享服务网格云原生可观测性【免费下载链接】linkerd2Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.项目地址https://gitcode.com/gh_mirrors/li/linkerd2点击查看免费下载相关推荐Spinnaker Clouddriver 的 Amazon ECS 集成测试测试架构、运行方式与编写指南Spinnaker Clouddriver 的 Amazon ECS 集成测试测试架构、运行方式与编写指南 导读 Spinnaker 的 clouddrive后端DevOps云原生微服务wasm-bindgen 测试框架的活教材深入解析 sample 测试 crate 与 wasm-bindgen-test 运行机制wasm bindgen 测试框架的活教材深入解析 sample 测试 crate 与 wasm bindgen test 运行机制 导读 wasm bind开发工具Pyrefly VSCode 扩展集成测试指南测试架构、运行方式与源码剖析Pyrefly VSCode 扩展集成测试指南测试架构、运行方式与源码剖析 本文以 Pyrefly 仓库中 lsp/src/test/README.md ht开发工具静态分析IDE代码质量创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考