云原生测试核心

• envtest 的工作原理
• Reconcile 逻辑的测试方法
• fake client 与 envtest 的取舍

envtest 工作原理：启动轻量的 Kubernetes 控制平面组件（kube-apiserver 和 etcd）作为本地测试环境，不启动完整的 kubelet/controller-manager，让测试可以在真实 apiserver 语义下运行 Operator 的 Reconcile 逻辑。envtest 通过 controller-runtime 的 EnvTest 提供真实 apiserver，支持 CRD 安装、对象创建/更新、最终器（finalizer）、状态更新等真实的 API 语义。测试 Reconcile：创建 CR 对象→调用 Reconcile→断言状态/资源。fake client 与 envtest 取舍：fake client 是内存中的模拟客户端，速度快、无外部依赖，但真实语义弱（不校验校验 webhook、不触发 watch、controller 的最终器/状态行为受限于模拟）；envtest 是真实 apiserver + etcd，语义真实（能测 webhook、watch、变更校验），但较重、需下载 etcd/apiserver 二进制。取舍：快速单测用 fake client，需验证真实 API 语义/控制器行为用 envtest（集成测试）。

envtest 用真实 apiserver 提供真实 API 语义，fake client 用内存模拟。测试 Reconcile 逻辑时，需要真实语义验证控制器行为选 envtest，快速单测选 fake client。

• 集群升级演练的设计
• 应用兼容性验证
• 回滚预案

集群升级测试设计：1）升级演练——在预生产环境按生产流程升级（控制面升级、节点升级、kubelet 升级），验证各阶段集群健康；2）应用兼容性验证——验证运行中的应用在升级后的集群上兼容（API 版本、特性开关、CRD 兼容），重点验证 Kubernetes API 废弃/变更对应用的影响；3）回滚预案——设计升级失败时的回滚：降级控制面版本、恢复节点、回滚应用；4）验证升级期间的应用可用性（不中断、滚动）。升级前先做"兼容性预检"（kubectl convert、API 版本检查），升级后用"冒烟+回归"验证应用，失败则按预案回滚。测试要覆盖"升级前预检、升级中健康、升级后兼容、失败回滚"。

集群升级测试覆盖"升级演练、兼容性、回滚预案"三要素。重点是验证 API 版本兼容与升级失败时的安全回滚，保障升级不破坏应用。

• Istio 路由规则测试
• 重试策略与熔断配置验证
• 配置生效的验证方法

Service Mesh 配置测试：1）路由规则（VirtualService）——验证按权重/Header/URI 的路由规则正确生效（流量分配到预期版本、灰度流量比例正确）；2）重试策略——验证配置的重试次数、超时生效（注入故障后按预期重试），避免重试风暴；3）熔断配置（DestinationRule）——验证熔断阈值（maxConnections、最大并发数、错误率）生效，超限时触发熔断（快速失败/circuit breaker opens），恢复后自动关闭；4）验证配置在 mesh 中正确下发（control plane 校验、proxy 生效）。验证方法：构造请求/注入故障，观察流量分配、重试行为、熔断行为是否符合配置。用 VirtualService 的 fault 注入（Abort/Delay）验证重试与熔断，用流量统计验证路由。

Mesh 配置测试验证"配置是否真正生效"。用故障注入验证重试与熔断，用流量断言验证路由，确保 mesh 配置与预期一致。

• GitOps 漂移检测的验证
• 漂移检测的触发机制
• 修复策略

GitOps 漂移检测测试：1）验证检测——手动修改集群资源（绕过 Git），验证 ArgoCD/Flux 检测到偏差并标记 OutOfSync；2）验证触发机制——漂移检测的触发源（轮询间隔、Git push 事件、webhook），验证各触发方式能触发检测；3）验证修复策略——auto-sync 自动将集群拉回 Git 声明状态，或手动 sync；验证修复正确（不误删、按声明恢复）；4）验证修复的安全——prune 策略（删除 Git 中不存在的资源）是否正确，避免误删；5）验证敏感字段——secret 等字段的漂移处理（哈希对比）。测试要点：验证"Git 声明与集群状态的偏差能被检测、被修复，且修复不破坏系统"。

漂移检测测试验证"Git 即真相"闭环。验证检测、触发机制、修复策略、prune 安全，确保漂移能被正确发现并修复。

• NetworkPolicy 的测试
• 多租户隔离验证
• 跨命名空间访问的阻断验证

NetworkPolicy 测试：1）定义验证场景——验证允许/拒绝的流量是否符合 NetworkPolicy 规则（同命名空间、跨命名空间、指定标签/Pod/端口）；2）验证跨命名空间阻断——配置 NetworkPolicy 只允许特定命名空间/标签访问，验证其他命名空间的访问被阻断；3）验证白名单/黑名单——验证 NetworkPolicy 的 allow/deny 规则（默认拒绝 + 显式允许）正确生效；4）验证多租户隔离——不同租户（命名空间）的 Pod 相互隔离（不能互访），验证隔离策略；5）验证 CNI 生效——NetworkPolicy 由 CNI（Calico、Cilium）执行，验证策略实际生效（生成流量验证可达/不可达）。用网络探测（如 curl、nc、iperf）验证可达性断言，确认跨命名空间/跨租户访问被阻断。

NetworkPolicy 测试验证"策略是否真正阻断非法访问"。用真实流量验证可达性，确认跨命名空间、跨租户访问被正确阻断，白名单生效。

• Helm/Kustomize 渲染测试
• 渲染结果的断言方法
• golden file 管理

声明式配置测试：1）渲染验证——用 helm template/kustomize build 渲染模板，验证渲染结果符合预期（资源、标签、字段、值）；2）断言方法——用结构化断言（yq/jq 解析 yaml，断言字段值）、快照断言（渲染结果与期望文件对比）、schema 校验（kubeconform/kubectl apply --dry-run 校验合法性）；3）golden file 管理——将渲染结果保存为 golden file（基准快照），测试时渲染结果与 golden file 对比，变更时更新 golden file（需人工审查）；4）值组合测试——用不同 values 组合渲染，验证各组合结果正确；5）模板错误测试——验证模板语法错误、缺失值、非法值能被捕获。golden file 管理要点：变更需审查、误更新会掩盖回归、要纳入版本控制。

声明式配置测试用"渲染断言 + golden file 快照"验证模板正确性。golden file 提供稳定基准，变更需审查，防止配置回归。

• OPA/Gatekeeper 策略测试
• 规则单测
• 准入拦截验证

OPA/Gatekeeper 策略测试：1）规则单测——用 OPA 的测试框架（opa test）对 rego 策略写单元测试，给定输入（资源对象）断言策略输出（allow/deny、violation 消息）；2）准入拦截验证——验证 Gatekeeper 的 Admission Controller 在创建/更新资源时正确拦截违规资源（deny），允许合规资源（allow）；3）测试用例——覆盖合规资源（通过）、违规资源（拒绝）、边界用例（缺失字段、错误类型）；4）验证约束模板（ConstraintTemplate）与约束（Constraint）的绑定生效；5）集成测试——在真实集群用准入 Webhook 验证拦截行为。测试断言：策略规则正确判定、准入拦截正确执行、违规资源被拒绝。

Policy-as-Code 测试包含"规则单测（rego 逻辑）+ 准入拦截（Webhook 行为）"。单测验证规则逻辑，集成测试验证准入拦截真实生效。

• HPA/VPA 弹性伸缩测试
• 副本数随负载伸缩的验证
• 缩容时优雅排空与流量摘除

弹性伸缩测试：1）HPA 扩容——施加负载（压测），验证副本数随 CPU/内存指标上升按比例扩容（HPA 的 min/max 之间）；2）HPA 缩容——降低负载，验证副本数按冷却时间下降（缩容）；3）验证伸缩延迟——扩容及时性（避免流量突增时不及时扩容）、缩容冷却（避免抖动）；4）优雅排空——缩容时验证 Pod 的 PreStop 钩子与优雅终止（terminationGracePeriodSeconds），在途请求被处理完（排空）再终止，避免请求中断；5）流量摘除——缩容时验证 Pod 从 Service 摘除（readiness 探针/结束监听）后再终止，避免流量打到终止中的 Pod。VPA 验证自动调整资源请求（recommendation）。测试断言：扩容/缩容正确、缩容时优雅排空、流量摘除及时。

弹性伸缩测试验证"扩容及时、缩容安全"。缩容时优雅排空（PreStop + 在途请求）与流量摘除（readiness）是防止缩容中断请求的关键。

• LimitRange 与 ResourceQuota 的测试
• 超限行为（拒绝创建、OOM）的验证
• 配额变更的回归

资源配额测试：1）LimitRange——验证命名空间内默认资源请求/限制、最小/最大限制生效（创建超限资源的 Pod 被拒绝）；2）ResourceQuota——验证命名空间内资源总量（CPU/内存/PVC 数量）超限时拒绝创建新的资源；3）超限行为验证——创建超限 Pod 被 kube-apiserver 拒绝（Admission 拒绝，返回错误），内存超限的 Pod 触发 OOM（killed）；4）配额变更回归——修改配额后验证：被拒绝的创建恢复允许、已运行资源不超新配额、降配额时已用资源处理（不删除但禁止新创建）；5）验证"拒绝创建"与"OOM 杀掉"两种超限行为的区分。测试断言：超限创建被拒绝、内存超限 OOM、配额变更后行为正确。

配额测试验证"超限被拒绝创建"与"内存超限 OOM"两种行为。配额变更需回归验证，确保降配额不破坏运行中资源、升配额恢复创建。

• 容器逃逸的测试
• 供应链攻击的测试
• 配置漂移的安全测试

云原生安全测试特殊考量：1）容器逃逸——测试容器能否突破隔离访问宿主机（验证容器以最小权限运行、非 root、只读根文件系统、无特权容器、seccomp/AppArmor 限制），测试容器逃逸漏洞（用镜像扫描 + 权限验证）；2）供应链攻击——测试镜像来源可信（镜像签名验证、SBOM、镜像仓库供应链）、依赖漏洞扫描（Trivy/Clair）、避免使用不可信镜像；3）配置漂移——测试安全配置（RBAC、NetworkPolicy、PodSecurity）是否漂移（被篡改），验证 GitOps 能纠正漂移；4）测试工具——kube-bench（CIS 基准）、kube-hunter、镜像扫描、OPA 策略。测试目标是"验证容器隔离、供应链可信、安全配置不漂移"。

云原生安全测试关注"容器隔离、供应链可信、配置不漂移"。测试容器逃逸防护、供应链漏洞、安全配置漂移，是云原生特有的安全风险。

• IaC 的测试验证方法
• Terraform/CloudFormation 的测试
• 基础设施变更的验证

IaC 测试验证方法：1）静态检查——terraform validate/plan 校验语法与配置正确性；2）单元测试——用工具（terratest、tftest）对 IaC 模块做单元测试，验证资源定义（属性、依赖）；3）集成测试——在真实/测试环境 apply IaC，验证基础设施创建正确（资源、网络、权限）；4）Plan 断言——验证 terraform plan 的变更符合预期（只动预期资源，不误删）；5）drift 检测——验证实际基础设施与 IaC 声明的漂移（terraform plan 显示 drift）；6）破坏性测试——验证销毁/重建基础设施的正确性。测试环境与 IaC 关系：测试环境用 IaC 管理（可重复创建/销毁），IaC 变更需先测试再应用。测试断言：IaC 渲染正确、apply 后资源正确、变更符合预期、无漂移。

IaC 测试覆盖"静态校验、单元测试、集成验证、plan 断言、漂移检测"。测试环境用 IaC 实现可重复基础设施，验证变更安全。

• 多集群的服务发现、流量切换、故障转移测试
• 联邦集群场景的测试设计
• 跨集群一致性验证

多集群测试策略：1）跨集群服务发现——验证服务在跨集群能被发现（DNS/mesh 的服务发现），路由到正确集群的实例；2）流量切换——验证流量能在集群间切换（主集群故障时切换到备集群），切换正确、无中断；3）故障转移——注入集群故障，验证服务自动转移到其他集群（failover），数据一致、可恢复；4）联邦集群（Federation）——验证联邦集群的服务/配置/命名空间同步到多个集群，验证联邦策略（placement、override）生效；5）跨集群一致性——验证跨集群共享数据的同步与一致性（多集群部署、配置、状态）。测试设计：构造多集群拓扑，注入集群级故障，验证跨集群服务发现、流量切换、故障转移与联邦同步。

多集群测试验证"跨集群服务发现、流量切换、故障转移"与联邦同步。用集群级故障注入验证故障转移与跨集群一致性。

• 云原生测试的隔离策略
• 测试成本的控制
• 环境复用与成本平衡

云原生测试隔离：1）环境隔离——测试环境与生产隔离（独立集群/命名空间/账户），测试数据、流量、配置不污染生产；2）资源隔离——测试用命名空间/资源配额限制资源，避免影响其他租户；3）数据隔离——测试数据用独立命名空间/影子，避免污染生产数据。成本控制：1）资源优化——按需创建/销毁测试环境（ephemeral 环境）、缩容闲置资源、用 Spot/低成本实例；2）环境复用——多个测试共享集群（按 namespace 隔离），降低集群成本；3）自动化执行——测试环境生命周期管理（自动创建/销毁），减少闲置；4）按需伸缩——测试环境资源按需伸缩，避免长期占用。隔离与成本平衡：用 namespace 隔离实现多租户复用（省成本）同时保证隔离（安全）。

云原生测试隔离用"命名空间/资源配额"实现多租户隔离，成本用"按需资源、环境复用、生命周期管理"控制。隔离与复用的平衡是核心。

• CRD Schema 校验测试
• 字段约束（必填、类型、枚举、格式）的验证
• 默认值行为验证

CRD Schema 校验测试：1）字段约束——验证 CRD 的 OpenAPI v3 Schema 约束生效：必填字段缺失被拒绝、字段类型错误被拒绝、枚举/pattern/format 违规被拒绝、最小/最大限制违规被拒绝；2）默认值——验证未提供默认值字段时，CRD 按 Schema 的 default 填充默认值；3）校验时机——验证创建/更新 CR 时 kube-apiserver 的 schema 校验拦截违规 CR；4）兼容性——验证 schema 变更（新增字段、字段可选变必填）的兼容性（旧 CR 处理）；5）验证非法 CR 被拒绝（admission 拒绝）、合法 CR 被接受。测试断言：超限/缺失/类型错误的 CR 被拒绝，缺省字段被填默认值，合法 CR 创建成功。

CRD Schema 校验测试验证"字段约束 + 默认值"由 apiserver 强制执行。测试超限被拒、缺省填默认、合法通过，确保 CR Schema 正确。

• K8s API 版本废弃的测试
• CRD 版本转换测试
• 集群升级兼容性验证

升级兼容性测试：1）API 版本废弃——验证应用使用的 K8s API 版本在目标集群仍受支持（kubectl convert、API 检查），检测废弃 API 对应用的影响；2）CRD 版本转换——验证 CRD 多版本（v1alpha1/v1beta1/v1）的转换（conversion webhook）正确，升级后旧版本 CR 能正确转换到新版本、数据不丢失；3）集群升级——验证升级到高版本集群后应用功能正常（API 兼容、CRD 兼容、特性兼容）；4）验证升级前预检（废弃 API 扫描）、升级后回归（功能、CR 状态）。测试断言：升级后应用无 API 不兼容、CRD 版本转换正确、旧数据不丢失、集群升级不影响应用。

升级兼容性测试覆盖"API 废弃、CRD 版本转换、集群升级"。重点验证废弃 API 影响、CRD 转换数据不丢失、升级后应用功能正常。

• CR 对象与 Operator 状态的隔离
• 配置数据的隔离
• 测试数据与生产隔离

云原生测试数据管理：1）CR 对象隔离——测试环境的 CR 对象与生产隔离（独立命名空间/集群），测试创建的 CR 不污染生产；2）Operator 状态隔离——Operator 管理的状态（如调谐状态、缓存、状态字段）随测试环境隔离，测试不干扰生产 Operator；3）配置数据隔离——ConfigMap/Secret 在测试环境独立配置，测试用配置不污染生产；4）数据管理——测试数据用独立命名空间/存储，测试完成后清理；5）多租户隔离——同一集群多测试环境用命名空间隔离 CR 与状态。验证方法：测试环境 CR/状态/配置与生产隔离，测试操作不影响生产对象。测试数据管理要"随环境隔离、可清理、不污染生产"。

云原生测试数据管理核心是"CR、Operator 状态、配置随环境隔离"。用命名空间/集群隔离 + 清理机制，保证测试数据不污染生产。

• 多云/多集群部署差异
• 可移植性测试设计
• 部署差异的系统验证

多集群可移植性测试：1）部署差异——验证应用在多云/多集群（不同云厂商、不同 K8s 版本、不同网络插件、不同存储）能正确部署与运行；2）资源差异——验证依赖的云资源（存储、网络、负载均衡）在目标环境可用（云厂商差异）；3）配置差异——验证配置（镜像、节点、存储类）在不同集群可移植（抽象化差异）；4）系统验证——在多集群/多云环境执行部署、功能、回归、故障测试，验证应用行为一致；5）可移植性标准——验证应用遵循可移植性最佳实践（无供应商锁定、资源抽象、标准 API）。测试方法：在多环境构建部署矩阵，逐一验证部署与运行，发现环境特有差异。可移植性测试目标是"一次构建、多环境一致运行"。

多集群可移植性测试验证"应用在多云/多集群部署一致"。用部署矩阵覆盖环境差异，验证资源/配置可移植、无供应商锁定。

• 测试结果与可观测平台的打通
• 观测闭环的建立
• 测试驱动的观测改进

云原生测试观测闭环：1）测试结果上报——测试执行结果（通过/失败、指标、日志、trace）上报到 Prometheus（指标）/Grafana（可视化）/Loki（日志）/Jaeger（trace）；2）指标打通——测试中注入的故障与指标变化（错误率、延迟）在 Prometheus 可见，结合测试断言验证；3）可视化——在 Grafana 建 Dashboard 展示测试结果、SLO、故障演练的观测数据；4）告警联动——通过 Prometheus 告警规则，将测试异常/SLO 告警接入告警系统；5）反向驱动——可观测平台数据（指标、trace）驱动测试改进（发现薄弱路径补测试）。观测闭环让"测试执行 + 观测数据 + 告警 + 改进"形成闭环，测试结果与运维观测统一。

观测闭环将测试结果接入 Prometheus/Grafana，使测试与生产观测统一。测试数据在可观测平台可见、可告警、可驱动改进。

• 无状态化验证
• 会话、文件、缓存状态外置
• 支撑 Pod 重启与水平扩展

无状态化验证：1）会话外置——验证应用会话存储在外置（Redis/DB）而非本地内存，Pod 重启后会话不丢失；2）文件外置——验证应用写入的文件存储在外置（对象存储/共享卷）而非本地磁盘，Pod 重建后文件保留；3）缓存外置——验证缓存存储在分布式缓存（Redis）而非本地，多副本共享一致；4）Pod 重启验证——删除/重启 Pod，验证应用状态不丢失、功能正常（无状态）；5）水平扩展验证——扩容副本数，验证无状态应用可并行扩展（状态不冲突、会话不失效）；6）验证本地状态——检查应用是否在本地写状态（本地磁盘/内存），发现隐藏状态。测试断言：Pod 重启/扩缩容后，会话、文件、缓存等状态不丢失、功能正常，证明应用无状态化。

无状态化验证核心是"状态外置"。验证会话/文件/缓存外置、Pod 重启不丢状态、水平扩展不冲突，支撑弹性伸缩与重启恢复。