K8s 平台测试清单：深度分析与实战指南

1. 引言

Kubernetes（K8s）平台作为现代云原生架构的核心底座，其稳定性、安全性与性能直接决定了上层业务系统的可靠性。然而，K8s 平台本身是一个由控制平面、工作节点、网络插件、存储插件、调度器等多个组件构成的复杂分布式系统，任何一个环节的缺陷都可能引发连锁故障。因此，建立一套系统化、可落地的测试清单，是保障 K8s 平台在生产环境稳定运行的关键前提。

本文将从功能、性能、安全、高可用、兼容性、运维可观测性等维度，深度拆解 K8s 平台测试的完整清单，并给出每个测试项的验证方法、通过标准与常见风险点，帮助测试工程师与平台运维团队构建一套可复用的测试体系。

2. 测试范围与分层策略

在制定测试清单之前，首先需要明确 K8s 平台的测试范围。K8s 平台测试通常分为以下四个层次：

基础设施层：操作系统、容器运行时（如 containerd、CRI-O）、网络插件（CNI）、存储插件（CSI）等底层组件。
控制平面层：API Server、etcd、Scheduler、Controller Manager 等核心组件的功能与稳定性。
数据平面层：kubelet、kube-proxy、Pod 生命周期、服务发现与负载均衡等运行时行为。
业务应用层：部署在平台之上的业务工作负载，验证平台对业务的实际支撑能力。

测试策略上，建议采用「分层分级」原则：基础设施层与控制平面层以自动化测试为主，数据平面层结合自动化与手工验证，业务应用层则根据业务重要性进行针对性回归。

3. 功能测试清单

功能测试是验证 K8s 平台是否按预期工作的基础。以下为核心功能测试项：

3.1 集群生命周期管理

集群创建：验证通过 kubeadm、二进制或云厂商托管方式创建集群的成功率与耗时。
节点加入与移除：验证新节点加入后自动注册、资源可调度；节点移除后工作负载自动迁移。
集群升级：验证跨小版本（如 1.28 → 1.29）与跨大版本升级过程中 API 兼容性、etcd 数据完整性。
集群备份与恢复：验证 etcd 快照备份、恢复后集群状态一致性。

3.2 工作负载管理

Pod 生命周期：创建、启动、运行、就绪、终止全流程验证。
Deployment 滚动更新：验证滚动更新策略（maxSurge、maxUnavailable）下的副本数变化与零中断。以下是一个包含滚动更新策略配置的完整 Deployment YAML 示例：

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  # 期望副本数
  replicas: 5
  # 滚动更新策略配置
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # 允许最多额外创建 1 个 Pod（即峰值副本数 = 5 + 1 = 6）
      maxSurge: 1
      # 允许最多 1 个 Pod 不可用（即最少可用副本数 = 5 - 1 = 4）
      maxUnavailable: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25.3
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5

滚动更新与回滚的常用 kubectl 命令及输出注释如下：

bash 复制代码

# 1. 触发滚动更新：更新镜像版本（如 1.25.3 → 1.26.0）
kubectl set image deployment/nginx-deployment nginx=nginx:1.26.0
# 输出示例：deployment.apps/nginx-deployment image updated

# 2. 查看滚动更新状态（观察新旧 Pod 交替过程）
kubectl rollout status deployment/nginx-deployment
# 输出示例：
# Waiting for deployment "nginx-deployment" rollout to finish: 4 out of 5 new replicas have been updated...
# deployment "nginx-deployment" successfully rolled out

# 3. 查看滚动更新历史（含 revision 版本号，用于回滚定位）
kubectl rollout history deployment/nginx-deployment
# 输出示例：
# deployment.apps/nginx-deployment
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         kubectl set image deployment/nginx-deployment nginx=nginx:1.26.0

# 4. 回滚到上一个版本（即 revision 1）
kubectl rollout undo deployment/nginx-deployment
# 输出示例：deployment.apps/nginx-deployment rolled back

# 5. 回滚到指定版本（如 revision 1）
kubectl rollout undo deployment/nginx-deployment --to-revision=1
# 输出示例：deployment.apps/nginx-deployment rolled back

# 6. 暂停 / 恢复滚动更新（用于金丝雀发布或分批验证）
kubectl rollout pause deployment/nginx-deployment
# 输出示例：deployment.apps/nginx-deployment paused
kubectl rollout resume deployment/nginx-deployment
# 输出示例：deployment.apps/nginx-deployment resumed

说明：maxSurge 与 maxUnavailable 可同时配置，也可只配置其一（未配置项默认取 25%）。上述示例中 maxSurge=1、maxUnavailable=1 表示更新过程中最多同时存在 6 个 Pod、最少保持 4 个可用，从而在保证零中断的前提下控制资源峰值。实际测试时建议结合 readinessProbe 验证新 Pod 就绪后再继续滚动，避免流量打到未就绪实例。

StatefulSet 有序部署：验证 Pod 序号、稳定网络标识（Headless Service）与持久化存储绑定。
DaemonSet 节点覆盖：验证新节点加入后 DaemonSet Pod 自动调度到所有匹配节点。
Job / CronJob：验证一次性任务与定时任务的执行、重试与并发策略。### 3.3 服务发现与网络
Service 类型：ClusterIP、NodePort、LoadBalancer、ExternalName 四类 Service 的连通性验证。
DNS 解析：验证集群内 Pod 通过 Service 名称、Namespace 限定名称解析的正确性。
Ingress 路由：验证基于域名、路径的流量转发，以及 TLS 证书配置。
NetworkPolicy：验证默认拒绝、白名单、跨 Namespace 访问控制策略是否生效。

3.4 存储与持久化

PV / PVC 动态供给：验证 StorageClass 动态创建 PV、PVC 绑定与释放。
持久化数据读写：验证 Pod 重启后数据持久性，以及多 Pod 共享读写（ReadWriteMany）场景。
存储扩容与快照：验证 PVC 在线扩容、CSI 快照创建与恢复。

4. 性能测试清单

性能测试旨在评估 K8s 平台在规模化场景下的承载能力与资源效率。

4.1 控制平面性能

API Server 吞吐：通过压测工具（如 kube-burner、vegeta）模拟大量 Pod/Service 创建请求，观察 API Server 的 QPS、延迟与错误率。
etcd 性能：验证 etcd 在大量 watch、读写请求下的延迟与磁盘 IO 表现，重点关注 defragmentation 后的性能恢复。
调度性能：验证大规模 Pod 批量创建时的调度吞吐（Pods/sec）与调度延迟。

4.2 数据平面性能

Pod 启动延迟：从创建到 Ready 的端到端延迟，重点关注镜像拉取、容器运行时启动、就绪探针等待时间。
网络性能：验证 Pod 间通信的带宽、延迟与 PPS（每秒包数），对比不同 CNI 插件（Calico、Cilium、Flannel）的差异。下表为三种主流 CNI 插件在典型测试环境下的示例数据，实际结果会因节点规格、内核版本、网络拓扑与压测工具（iperf3、netperf）的不同而有所差异，建议在自身环境中建立基线后再做横向对比。

CNI 插件	带宽（Gbps）	延迟（μs）	PPS（百万包/秒）
Calico（eBPF 模式）	8.5	45	1.2
Cilium（eBPF 模式）	9.2	38	1.6
Flannel（VXLAN 模式）	6.8	62	0.8

说明：以上数据为示例值，仅用于展示三种插件在带宽、延迟与 PPS 上的相对差异。Cilium 与 Calico 的 eBPF 数据面在吞吐与包处理能力上通常优于 Flannel 的 VXLAN 封装方案，但 Flannel 胜在部署简单、资源占用低；实际选型需结合 NetworkPolicy 支持度、可观测性与运维成本综合评估。

存储性能：验证不同 StorageClass 下块存储与文件存储的 IOPS、吞吐量与延迟。### 4.3 规模化压测
节点规模：验证集群在 500、1000、5000 节点规模下的控制平面稳定性。
Pod 密度：验证单节点承载 100、200、500 Pod 时的资源消耗与调度表现。
长稳测试：持续运行 7×24 小时，观察内存泄漏、goroutine 泄漏、日志增长等长期稳定性问题。

5. 安全测试清单

安全测试是 K8s 平台测试中不可忽视的一环，重点覆盖权限、隔离、供应链与运行时安全。

5.1 认证与授权

RBAC 权限验证：验证不同 Role / ClusterRole 下的用户与 ServiceAccount 的实际权限边界。
ServiceAccount 令牌：验证自动挂载的令牌是否遵循最小权限原则，是否启用了 TokenRequest API。
准入控制：验证 PodSecurity Admission、ValidatingAdmissionWebhook、MutatingAdmissionWebhook 的生效情况。

5.2 容器与运行时安全

镜像安全扫描：验证镜像仓库中的镜像是否存在高危漏洞（CVE）。
特权容器限制：验证是否禁止了 privileged 容器、hostPID、hostNetwork 等高危配置。
只读根文件系统：验证只读根文件系统与 drop capabilities 配置是否生效。
Seccomp / AppArmor：验证容器运行时是否应用了安全配置文件。

5.3 网络安全

NetworkPolicy 隔离：验证默认拒绝所有流量、仅允许白名单流量的策略是否真正生效。
加密通信：验证 etcd 与 API Server 之间、Pod 之间的 TLS 加密是否启用。
敏感信息保护：验证 Secret 是否加密存储（Encryption at Rest），以及是否通过环境变量或文件方式安全注入。

5.4 供应链安全

镜像签名验证：验证是否启用了镜像签名（cosign）与策略校验。
准入镜像白名单：验证是否限制了可部署镜像的来源仓库与 tag 规则。

6. 高可用与故障演练测试

高可用测试的核心是验证平台在组件故障时能否自动恢复，且业务不中断或仅短暂中断。

6.1 控制平面高可用

API Server 故障：杀掉一个 API Server 实例，验证客户端连接自动切换到其他实例。
etcd 故障：杀掉一个 etcd 节点，验证集群仍可正常读写；杀掉多数节点，验证只读模式与恢复流程。
Leader 选举：验证 Controller Manager 与 Scheduler 的 Leader 选举切换时间与行为。

6.2 数据平面故障

节点宕机：强制关闭一个工作节点，验证 Pod 在容忍时间（如 5 分钟）后自动迁移到其他节点。
kubelet 故障：杀掉 kubelet 进程，验证节点状态变为 NotReady，以及恢复后的 Pod 重建。
网络分区：模拟节点间网络隔离，验证 CNI 的健康检查与流量恢复。

6.3 混沌工程演练

故障注入：使用 Chaos Mesh 或 Litmus 注入 Pod 崩溃、网络延迟、磁盘 IO 故障，观察平台自愈能力。
恢复时间目标（RTO）：记录从故障发生到业务完全恢复的时间，验证是否符合 SLO。

7. 兼容性测试清单

K8s 平台需要与上下游多种组件协同工作，兼容性测试确保平台在异构环境中的可用性。

7.1 容器运行时兼容性

验证 containerd、CRI-O、Docker（通过 cri-dockerd）等不同运行时下的 Pod 创建、日志、exec 行为一致性。

7.2 CNI 插件兼容性

验证 Calico、Cilium、Flannel、Weave 等 CNI 插件下的网络连通性、NetworkPolicy 支持度与性能差异。

7.3 CSI 存储插件兼容性

验证不同云厂商（AWS EBS、GCE PD、Azure Disk）与开源存储（Ceph RBD、NFS）的 CSI 驱动挂载、扩容、快照能力。

7.4 上游 API 兼容性

验证 K8s API 的弃用（deprecated）接口在升级后是否仍可用，以及客户端库（client-go、kubectl）版本兼容性。

7.5 多架构支持

验证平台在 amd64、arm64 等不同 CPU 架构下的镜像拉取、调度与运行能力。

8. 运维可观测性测试

可观测性测试验证平台是否具备完善的监控、日志与告警能力，支撑日常运维与故障排查。

8.1 监控指标

验证 kube-state-metrics、node-exporter、cAdvisor 等指标采集是否完整，Prometheus 抓取是否正常。
验证核心指标（CPU、内存、网络、磁盘、API Server 延迟）的准确性与粒度。

8.2 日志采集

验证容器标准输出日志、文件日志通过 Fluentd / Loki / ELK 等管道采集的完整性与时效性。
验证日志的标签（Namespace、Pod、Container）是否正确注入，便于检索。

8.3 告警规则

验证关键告警规则（节点 NotReady、Pod 重启、API Server 高延迟、etcd 空间不足）是否触发及时、通知渠道是否可达。
验证告警的抑制与静默规则是否合理，避免告警风暴。

8.4 审计日志

验证 API Server 审计日志是否记录了关键操作（创建、删除、权限变更），且日志可检索、可归档。

9. 测试执行策略与工具链

9.1 测试分层执行

冒烟测试：每次集群部署或升级后，快速执行核心功能用例（如 Pod 创建、Service 连通、DNS 解析），确保基础可用。
回归测试：在版本迭代或配置变更后，执行完整功能与安全用例集。
性能与长稳测试：在预发环境或独立测试集群中执行，避免影响生产。

9.2 推荐工具链

功能测试：kubectl、Kubernetes e2e-test、Sonobuoy。
性能测试：kube-burner、vegeta、iperf3、fio。
安全测试：kube-bench、kube-hunter、trivy、falco。
混沌测试：Chaos Mesh、Litmus。
可观测性：Prometheus、Grafana、Loki、Jaeger。

9.3 测试报告与闭环

每次测试后输出结构化报告，包含用例执行结果、失败原因、风险等级与修复建议。
建立缺陷跟踪闭环，确保高危问题在发布前修复并复测通过。

10. 总结与最佳实践

K8s 平台测试清单的构建不是一次性的工作，而是一个持续演进的过程。以下为几条最佳实践建议：

以业务场景驱动测试设计：优先覆盖对业务影响最大的核心链路，而非追求用例数量。
自动化优先，手工兜底：将高频、可重复的用例自动化，保留少量需要人工判断的复杂场景。
建立基线数据：通过性能与长稳测试沉淀基线数据，用于后续版本对比与容量规划。
持续集成到 CI/CD：将冒烟与回归测试接入流水线，在每次变更后自动触发。
重视故障演练：定期进行混沌演练，验证平台的真实自愈能力，而非仅依赖理论设计。

最后，测试清单的价值在于「可执行、可度量、可闭环」。建议团队根据自身平台规模与业务特点，裁剪并落地本文清单，形成一套属于自己的 K8s 平台质量保障体系。