容器与 Kubernetes 测试

• envtest 的单元/集成测试方法
• kuttl 的声明式场景测试
• Operator 测试的覆盖范围

Operator 测试分层进行：其一，envtest——用 kube-apiserver 和 etcd 的本地二进制（无需完整集群）启动真实 API server，配合 controller-runtime 的 Reconciler 测试，验证 CR 创建后控制器正确调谐，断言最终状态、子资源与事件；其二，kuttl——声明式端到端测试，用 YAML 定义"应用 CR → 等待 → 断言资源状态"的步骤，结合 assertions 验证期望状态，适合验证 CRD 与 webhook 的完整行为；其三，webhook 测试——验证准入控制（创建/更新/删除）的校验逻辑，拒绝非法对象；其四，故障与幂等——验证被调谐对象重复调谐不产生副作用，控制器崩溃重启后能恢复。最佳实践：用 envtest 做快速单元/integration 测试，用 kuttl 做真实集群的端到端测试，合理划分测试环境，避免测试污染生产。

Operator 是"控制循环"程序，测试核心是验证"声明状态 → 实际状态"的调谐闭环。envtest 提供轻量真实 API server 便于快速迭代，kuttl 提供表达能力强的声明式场景测试，两者结合覆盖从单元到端到端的层次。幂等与故障恢复是 Operator 的关键可靠性。

• 基础镜像与依赖漏洞扫描
• 运行时权限最小化（非 root、seccomp、capabilities）
• 镜像扫描与 CI 集成

容器镜像安全测试方法包括：其一，漏洞扫描——用 Trivy、Clair、Grype 等工具扫描镜像中的基础镜像与依赖（OS 包、语言依赖）CVE 漏洞，按严重级别（Critical/High）判定是否阻断发布；其二，基础镜像策略——选择更新更频繁的官方精简镜像（如 distroless、Alpine），减少攻击面；其三，运行时权限最小化——验证镜像以非 root 用户运行、不暴露多余 capabilities（用 cap_drop 裁剪）、配置 seccomp/AppArmor 限制系统调用；其四，只读文件系统——验证除必要卷外文件系统只读；其五，敏感信息——扫描镜像是否包含密钥/令牌/硬编码凭据；其六，把扫描接入 CI，在镜像构建后自动扫描，高危漏洞阻断发布并生成报告。建议设置"SCAN_FAIL_ON_SEVERITY"类策略。

镜像安全是"供应链安全"的核心，漏洞扫描在构建期拦截已知 CVE，运行时最小化在部署期降低未知漏洞可利用性。两者结合：扫描解决"已知漏洞"，权限最小化解决"未知漏洞的爆炸半径"。测试要验证安全配置真正生效（非 root 真能拒绝写、cap 被裁剪）。

• Chart 模板渲染与 values 组合
• 部署正确性与资源校验
• 回滚能力验证

Helm Chart 测试方法包括：其一，模板渲染——用 helm template 渲染渲染不同 values 组合，校验生成的 manifest 与资源内容（label、image、replicas）正确，用 schema/lint 校验 values 合法性；其二，values 组合矩阵——对关键参数（副本数、镜像 tag、环境、ingress 开关、资源限制）构造组合，验证渲染结果符合预期；其三，部署正确性——用 helm install 在测试集群部署，验证资源能正常创建、Pod 就绪、服务可达；其四，Chart 的测试钩子（helm test）——定义 test pod 验证应用功能；其五，回滚能力——helm upgrade 后故意引入错误，验证 helm rollback 能恢复到上一版本且资源状态正确；其六，升级兼容——验证 chart 从旧版本升级到新版本不破坏现有资源。建议用 helm lint 与 chart-testing 工具在 CI 中自动校验。

Chart 本质是"模板 + 配置"，主要风险是"不同 values 组合渲染出错误资源"和"升级/回滚破坏现有状态"。测试要在渲染层校验组合正确性，在部署层验证真实可用性，在回滚层验证可恢复能力。模板渲染是低成本高覆盖的手段。

• NetworkPolicy 的入站/出站规则
• 策略生效与默认拒绝
• 端到端连通性验证

NetworkPolicy 测试方法包括：其一，连通性矩阵——用测试工具（如 netshoot、kube-network-policies）在 Pod 间发起连接，验证"允许的"连通、"禁止的"被阻断，构造一个（源、目标、端口）矩阵进行断言；其二，入站/出站规则——分别验证 ingress 与 egress 规则，包括默认拒绝（未匹配策略则拒绝）与显式允许（matchLabels、namespaceSelector、IPBlock）；其三，命名空间隔离——验证不同 namespace 间的策略是否生效；其四，DNS 与端口——验证允许的 DNS 解析、特定端口访问受限；其五，策略变更——验证新增/修改策略后隔离行为即时更新。前提是集群 CNI 支持 NetworkPolicy（如 Calico、Cilium），测试需在真实网络环境执行。

NetworkPolicy 是"默认拒绝"的网络安全模型，测试价值在于验证"隔离是否真的生效"——错误的策略会被注入导致该通的不通或该断的没断。连通性矩阵方法能系统化验证 (源,目标,端口) 组合，端到端网络测试才能发现配置错误。

• requests 与 limits 的调度与限制语义
• OOMKill 与内存超限
• CPU 节流（throttling）

资源限制测试方法包括：其一，内存超限——给容器设置内存 limits，注入内存压力（如 stress 工具持续分配内存），验证容器被 OOMKill（RestartPolicy 下重启）或报错，Observed 内存不超限，且不受影响的其他 Pod 正常；其二，CPU 节流——设置 CPU limits，跑高 CPU 负载，观察容器 CPU 使用被限制在 limits 值（配额，不 OOM 但被节流），验证 CPU throttling 发生且不影响调度；其三，requests 与 limits 关系——requests 用于调度（保证保障），limits 用于限制，验证 requests < limits 时调度与运行差异；其四，QoS 级别——验证 Guaranteed/Burstable/BestEffort 三类 Pod 在资源压力下的表现差异；其五，调度验证——验证 requests 过大导致无法调度（Pending）。建议用 HPA 与监控指标（如 container_memory_working_set_bytes、cpu_usage）量化断言。

requests/limits 决定调度的保障与运行的硬限制，测试要验证"超限的后果"符合预期：内存超限 OOMKill、CPU 超限被节流。这两者行为不同（OOM 是终止，节流是降速），是测试重点。同时验证 requests 影响调度是否合理。

• 流量管理（路由、权重、镜像）
• 熔断（负载均衡池、连接池）
• mTLS 双向认证

Service Mesh 测试方法包括：其一，流量管理——验证 VirtualService 的权重路由（如 90%/10% 灰度）、基于 header 的路由、故障注入（delay/abort）是否符合预期；其二，熔断——通过 DestinationRule 的 connectionPool/trafficPolicy 配置熔断，注入高负载或故障，验证超出阈值时请求被拒绝（503）而非拖垮下游，统计熔断打开/闭合状态；其三，mTLS——验证启用 PeerAuthentication 后服务间双向 TLS 生效，明文请求被拒绝，证书轮换正常；其四，重试与超时——验证 mesh 层的重试与超时策略；其五，可观测性——验证 mesh 产生正确的 telemetry（trace、指标、日志）。建议用真实服务网格配合 fault injection 与负载测试验证。

Service Mesh 把流量控制、安全、可观测下沉到基础设施层，测试要验证这些"数据面行为"是否按配置生效。熔断/故障注入是核心韧性测试，mTLS 是安全核心，都需在真实 mesh 环境（而非 mock）验证。权重与路由策略直接决定灰度正确性。

• 镜像内容与启动命令（ENTRYPOINT/CMD）验证
• 健康检查与存活/就绪探针
• 资源限制与安全扫描

容器镜像测试方法包括：其一，镜像内容——用 docker inspect/镜像平台工具验证镜像文件系统内容、层、元数据（标签、暴露端口、环境变量）符合预期；其二，启动命令——验证 ENTRYPOINT/CMD 能正确启动进程，容器启动后进程存活且端口监听正常；其三，健康检查——验证镜像内置 HEALTHCHECK 与线上定义的 liveness/readiness 探针能正确反映应用状态，异常时探针失败；其四，资源限制——验证镜像运行时按 requests/limits 消耗资源，不越界；其五，安全扫描——用 Trivy/Clair 扫描漏洞与敏感信息，禁止高危镜像上线；其六，运行冒烟——启动容器后访问健康端点，验证最小功能可用。建议把镜像测试纳入 CI（构建后扫描 + 冒烟），保证镜像"可构建、可运行、可扫描通过"。

镜像测试是"产物的正确性验证"，覆盖内容、启动、健康、资源、安全五个维度。镜像不可变，构建期验证能提前拦截问题，比运行时才发现更高效。安全扫描与健康检查是上线门槛，应作为 CI 强制门禁。

• Pod 生命周期状态迁移
• liveness/readiness 探针行为
• 配置挂载与滚动更新/回滚

K8s 场景测试方法包括：其一，Pod 生命周期——验证 Pod 从 Pending→Running→Ready/Succeeded/Failed 的状态迁移，以及删除、驱逐时的行为；其二，探针——验证 liveness 探针失败时容器被重启、readiness 探针失败时流量被摘除（Pod 不进入 Ready），并验证探针的 initialDelay、period、failureThreshold 配置；其三，配置挂载——验证 ConfigMap/Secret 挂载到容器后内容正确、更新后如何生效（是否热更新或需重启）；其四，滚动更新——验证 Deployment 更新时滚动策略（maxSurge/maxUnavailable）生效，新 Pod 就绪后旧 Pod 才被终止，期间服务不中断；其五，回滚——验证 update 失败（如镜像错误、探针失败）时 rollout 能回滚到上一版本，或手动 kubectl rollout undo。建议用 kubectl 断言语义与监控指标验证。

这些是 K8s 的核心运行场景，测试要验证"声明式状态与控制器行为"的一致性。探针与滚动更新直接决定可用性，配置挂载决定配置正确性，回滚决定故障恢复能力。测试应端到端验证真实行为而非只看配置。

• SIGTERM 信号处理与优雅退出
• terminationGracePeriod 与 preStop 钩子
• readiness 探针与滚动更新的配合

保证滚动更新不丢在途请求需要"摘流量 + 优雅退出"配合。方法包括：其一，摘流量——Deployment 滚动更新时，先从 Service Endpoints 摘除旧 Pod：通过 readiness 探针失败或 preStop 钩子 sleep 让 LB 停止转发新请求，再处理存量；其二，preStop 钩子——在 preStop 中 sleep（如 5-10s）等待负载均衡器把已连接请求完成，再终止容器；其三，SIGTERM 处理——应用应捕获 SIGTERM，停止接收新请求，完成在途请求后退出，而非立即退出；其四，terminationGracePeriod——配置足够长的优雅退出窗口，超时后被 SIGKILL 强杀；其五，验证测试——用持续压测的请求流，在滚动更新过程中断言请求成功率不下降、无 502/连接中断，验证"优雅"生效。建议用端到端压测 + 滚动更新并发验证。

滚动更新丢请求的根因是"Pod 被终止时仍有在途连接"。优雅终止的完整链路是"摘流量（readiness/endpoints）→ preStop 等待 → SIGTERM→应用完成在途请求 → 超时 SIGKILL"。测试要验证这条链路的每环，特别是压测中可以量化"更新期间丢了多少请求"。

• StatefulSet 的启动/删除顺序（ordinal）
• PVC 数据持久化
• 故障重建与数据恢复

有状态应用测试方法包括：其一，有序性验证——StatefulSet 按 ordinal（0,1,2...）顺序启动、逆序删除，验证 Pod 启动/删除顺序符合预期，且 service 与 hostname 稳定；其二，PVC 持久化——验证数据写入 PVC 后，Pod 删除或重建，数据仍保留（PVC 与 Pod 生命周期解耦）；其三，重建恢复——验证某 Pod 被删除/故障后重建，重新挂载原 PVC，数据不丢失，应用状态恢复；其四，伸缩——验证扩容时按序新增 new Pod、缩容时按序删除且数据保留；其五，故障转移——验证主从（如数据库）故障转移时数据一致性。建议用真实有状态应用（如数据库、Kafka）做端到端验证，并检查 PVC 绑定与存储类。

StatefulSet 面向有状态应用，其核心语义是"稳定网络标识 + 稳定存储 + 有序部署"。测试要验证这些语义在"删除、重建、伸缩、故障"场景下不破坏数据。PVC 持久化与重建恢复是数据安全的关键，必须用真实存储验证。

• 混沌工程（Chaos Engineering）的注入手段
• Pod 驱逐、节点故障、网络分区的自愈
• 稳态假设与恢复验证

混沌测试方法包括：其一，注入手段——用 ChaosMesh、Litmus、kube-monkey 等注入 Pod 删除、节点故障、网络丢包/延迟/分区、磁盘故障等故障；其二，Pod 驱逐——驱逐 Pod 后验证 Deployment 按 ReplicaSet 自动重建，服务可用性恢复；其三，节点故障——模拟节点 NotReady/宕机，验证 Pod 被调度到其他节点，控制面健康；其四，网络分区——注入网络隔离，验证应用重试、熔断、故障转移后恢复；其五，稳态假设——混沌测试前定义"系统正常指标"（如 API 成功率、p99 延迟），注入故障后验证系统能回到稳态或按预期降级。建议用"游戏日"（Game Day）演练，从小范围故障逐步扩大，并观察指标恢复。

混沌测试的价值在于"主动发现分布式系统的脆弱性"，而非等故障自然发生。核心是"稳态假设 + 故障注入 + 恢复验证"：先定义正常指标，注入故障，观察系统是否自愈并恢复稳态。这能真实检验控制器的自愈能力。

• GitOps 的声明式状态与漂移
• 漂移检测与自动同步
• 配置一致性验证

GitOps 漂移检测测试方法包括：其一，一致性验证——部署后验证集群应用状态与 Git 仓库中的 manifest 一致（ArgoCD 的 Sync Health 状态为 Synced/Healthy）；其二，漂移注入——手动修改集群中的资源（如改 Deployment 副本数、改 ConfigMap），验证 GitOps 工具检测到"OutOfSync"漂移并（若开启 auto-sync）自动回滚到 Git 声明状态；其三，自动同步——验证开启自动同步后，漂移被纠正，手动修改被还原；其四，回滚——验证 Revert 到 Git 历史版本后集群状态随之更新；其五，权限与多集群——验证 GitOps 对多集群的一致管理。建议用 ArgoCD CLI/API 断言 Application 状态，把"同步状态"作为 CI 门禁。

GitOps 的核心承诺是"Git 是唯一事实来源"，漂移检测是确保"集群状态 = Git 状态"的机制。测试要验证"手动改会造成漂移、GitOps 能检测并纠正"，从而保证所有变更都经 Git 可审计、可回滚。这是 GitOps 可信赖性的根基。

• 集群内运行测试的方式（TestPod、Job、并行）
• 测试命名空间隔离
• 资源配额与生命周期管理

K8s 测试基建方法包括：其一，运行方式——测试可作为 Job、TestPod 或 sidecar 在集群内运行，用 Testkube 等工具编排测试，也可以把测试容器作为 Deployment 在集群内执行；其二，命名空间隔离——每个测试套件/PR 使用独立命名空间，避免测试间相互污染，命名空间内用 label 隔离资源；其三，资源配额——用 ResourceQuota 与 LimitRange 限制测试命名空间的 CPU/内存/对象数量，防止测试失控占用集群资源；其四，生命周期——测试结束后清理命名空间与资源（namespace delete），避免残留；其五，权限——测试用最小权限 ServiceAccount，避免越权；其六，并行与调度——测试并行时用不同命名空间/亲和性避免资源争抢。建议用 GitOps/CI 自动创建销毁测试命名空间。

集群内测试基建的关键是"隔离"—命名空间隔离业务、配额隔离资源、账号隔离权限。测试在集群内运行能验证真实网络与 API 行为，但必须可控、可清理、不污染生产。资源配额防止测试资源泄漏。

• 镜像不可变性与可重复性
• 分层缓存与依赖一致性
• 缓存命中对测试结果的影响

镜像不可变性与分层缓存对测试的影响方法包括：其一，不可变性——相同 tag 的镜像应内容一致，可复现测试结果；但若用可变 tag（如 latest）或构建不确定，会导致测试结果漂移，应使用不可变 tag（含 commit/构建号）；其二，分层缓存——Docker 分层缓存命中意味着依赖层不重建，能加速构建，但若依赖解析（如包管理器无锁文件）不确定，缓存命中掩蔽了新依赖，测试可能没覆盖真实依赖；其三，可重复性——用 lock 文件固定依赖版本，保证镜像重建时依赖一致，测试结果可复现；其四，缓存失效——验证依赖变更时缓存正确失效、重建后镜像包含新依赖。建议用固定 tag + 依赖锁文件 + 构建指纹保证可重复性。

镜像不可变性是"同一镜像=同一代码+依赖"的保证，直接影响测试可重复性。分层缓存加速构建但可能造成"缓存命中导致依赖未更新"的假象。测试要保证确定性：固定 tag、锁定依赖、验证缓存失效，才能让测试结果可信。

• RBAC 的 Role/ClusterRole 与 RoleBinding/ClusterRoleBinding
• ServiceAccount 的授权边界
• 越权与最小权限验证

RBAC 权限测试方法包括：其一，授权边界验证——用 kubectl auth can-i 或官方 API 验证某 ServiceAccount 对资源（get/list/create/delete）的权限，断言"允许的操作能用、拒绝的操作被拒"；其二，Role 与 ClusterRole 差异——验证 Role 只作用于指定命名空间、ClusterRole 作用于全集群，RoleBinding 与 ClusterRoleBinding 的绑定范围正确；其三，最小权限——验证 ServiceAccount 只拥有完成任务所需的最小权限，无多余通配符权限；其四，越权测试——用低权限 ServiceAccount 尝试访问受保护资源，验证被 RBAC 拒绝；其五，令牌与身份——验证 Pod 使用正确的 ServiceAccount，令牌不过度暴露。建议用 can-i 断言 + 真实越权尝试双管齐下。

RBAC 是 Kubernetes 的安全边界核心，测试要验证"授权模型是否真的限制住了"。kubectl auth can-i 能快速验证权限，但真实越权尝试更可靠（能发现策略解析与实现差异）。最小权限验证防止权限过度放大。

• Kind、K3s、minikube 的差异
• 能力、速度、CI 适配的权衡
• 场景化选型

三者取舍如下：其一，Kind——用 Docker 运行单 node 集群，轻量、启动快、与 CI 集成好（GitHub Actions 常用），支持多节点与 HA；缺点是对新特性支持依赖 Docker 内核、功能较基础；其二，K3s——单二进制、资源占用低、启动快，适合边缘/资源受限环境，但为精简可能裁剪部分功能、与生产 K8s 有差异；其三，minikube——功能最全、驱动多样（含真实 VM），支持多 worker、addons、与真实集群接近，但启动较重、资源占用大、CI 中较慢。选型建议：CI 快速回归用 Kind（轻量、易并行）；本地开发与测试常用 minikube（功能全、贴近生产）；资源受限/边缘测试用 K3s。注意测试环境与生产版本差异带来的兼容性风险。

本地 K8s 环境选型是"能力、速度、成本"的权衡。Kind 胜在轻量与 CI 适配，minikube 胜在功能完整贴近生产，K3s 胜在资源占用低。没有绝对最优，需按场景（CI 快速、本地开发、边缘测试）选择，并注意与生产 K8s 版本差异。

• 环境变量与 ConfigMap 配置注入
• Secret 安全注入
• 配置变更与热更新

配置注入测试要点包括：其一，环境变量——验证容器内环境变量被正确注入，应用能读取到正确配置（地址、端口、开关）；其二，ConfigMap——验证 ConfigMap 挂载为文件后内容正确、路径正确，应用能读取；其三，Secret——验证 Secret 通过 volume 或环境变量注入，内容不泄露到日志/环境变量；其四，配置变更——验证 ConfigMap 更新后挂载文件是否热更新（propagated）、应用是否感知（需重启或重新加载）；其五，依赖注入——验证通过注入 mock 外部服务（如测试数据库、测试 HTTP 服务）替代真实依赖，测试环境隔离；其六，缺失与非法配置——验证配置缺失时应用报错或降级符合预期。建议用 ConfigMap/Secret 作为配置来源，避免硬编码。

容器配置注入测试要验证"配置正确到达应用"且"配置安全"。ConfigMap/Secret 是配置与敏感信息的标准注入方式，测试要覆盖内容正确性、热更新行为、Secret 不泄露。依赖注入则让测试能用 mock 替代真实外部依赖，实现隔离。

• securityContext 的只读根文件系统、runAsNonRoot、capabilities
• 配置生效的验证方法
• 误配置风险

安全上下文验证方法包括：其一，只读根文件系统——设置 readOnlyRootFilesystem: true，验证容器无法写根目录（写临时目录需挂载 emptyDir），误写会报错；其二，非 root——设置 runAsNonRoot/runAsUser 非 0，验证容器以非 root 运行（/proc 中 uid 非 0），且镜像内无 root 入口；其三，capabilities 裁剪——用 drop 移除危险 capability（如 NET_ADMIN、SYS_ADMIN），验证相关操作被拒绝；其四，seccomp 限制——验证系统调用被限制。误配置风险：只读根文件系统但应用需写临时文件会导致运行失败；未设 runAsNonRoot 时特权容器可能以 root 运行；capabilities 裁剪过度会让依赖特定权限的应用无法工作；而根本不配置安全上下文则暴露过大攻击面。测试既要验证限制生效，也要验证应用在限制下仍能正常运行。

安全上下文是"纵深防御"的容器硬约束，测试要验证"限制真的生效"（非 root 真非 root、只读真只读、cap 真裁剪），同时验证"限制不破坏应用"（应用能在受限下运行）。误配置风险是测试最该发现的：要么限制太松失效，要么限制太紧导致应用故障。