# 测试工程师学 K8s：一份"最小必要知识"清单，附学习路线

宋均浩
0 阅读5分钟

招聘 JD 上"精通 K8s"越来越常见，测试群里每隔几天就有人问"测试要不要学 K8s"。本文从测试工程师的实际工作场景出发，分析哪些 K8s 知识是刚需、哪些可以跳过，给出一份两个月可完成的精简学习路线。

适用人群： 有基础 Linux/Docker 使用经验，需要在 K8s 环境中部署测试服务、排查问题的测试/测开工程师。

结论先行

测试工程师不需要"精通 K8s"，但需要"能在 K8s 上独立工作"。

具体来说，三件事必须会：

  1. 部署测试服务 —— 写 Deployment YAML，把自己的自动化服务跑在 K8s 上
  2. 排查问题 —— 看 Pod 状态、查日志、进容器 debug
  3. 管理配置 —— 用 ConfigMap/Secret 管理环境差异，告别硬编码

三件事不需要会：搭集群、配 RBAC、写 Operator。下面展开说。

学了 vs 用了：半年学习复盘

知识点耗时测试工作中使用频率建议
Pod / Deployment / Service2 周每天✅ 必学
kubectl 常用命令1 周每天✅ 必学
ConfigMap / Secret3 天高频✅ 必学
日志查看 / 容器调试1 周每次故障✅ 必学
Ingress / Service 网络1 周偶尔⚠️ 了解即可
Helm2 周按团队而定⚠️ 会用就行
PV / PVC 存储1 周几乎不用❌ 可以跳过
RBAC 权限控制1 周几乎不用❌ 可以跳过
集群搭建（kubeadm）2 周搭完再没碰过❌ 可以跳过
Operator / CRD3 周从未用过❌ 可以跳过

一半学习时间属于无效投入。 如果现在重新规划，砍掉下四项，把时间集中在前四项上，两个月足够从零到能干活。

1. 部署：把测试服务跑在 K8s 上

测试团队维护一个 API 自动化测试服务，需要让它以 Deployment 方式运行在测试集群中。你需要自己写部署文件——因为只有你知道自己的服务需要什么环境变量、资源配额、健康检查端点。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-test-runner
  namespace: test-env
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api-test-runner
  template:
    metadata:
      labels:
        app: api-test-runner
    spec:
      containers:
        - name: runner
          image: registry.xxx.com/api-test-runner:v2.1.0
          env:
            - name: BASE_URL
              valueFrom:
                configMapKeyRef:
                  name: test-config
                  key: base_url
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: test-secrets
                  key: db_password
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 30

几个测试场景下需要注意的点：

配置说明
resources.requests/limits必填。不设的话 Pod 可能被 OOMKilled，测试跑到一半容器消失
livenessProbe你的测试服务需要有 /health 端点，否则 K8s 不知道它是否存活
namespace测试环境独立命名空间，避免误操作影响其他环境
image tag建议用版本号而非 latest，保证可复现

2. 排查：出问题时手里有工具

生产环境报 bug，后端说"是环境问题不是代码问题"。你需要自己验证。

测试工程师必会的四个 kubectl 命令

# 1. 查看 Pod 状态 — 是不是挂了
kubectl get pods -n test-env -l app=user-service

# 输出解读：
# NAME                            READY   STATUS             RESTARTS
# user-service-7d8f-4xk2m         1/1     Running            0        ← 正常
# user-service-7d8f-9b3yq         0/1     CrashLoopBackOff   12       ← 挂了

# 2. 查看 Pod 事件 — 为什么挂了
kubectl describe pod user-service-7d8f-9b3yq -n test-env

# 关注 Events 段：OOMKilled / ImagePullBackOff / Liveness probe failed

# 3. 查看日志 — 错误在哪个环节
kubectl logs -n test-env user-service-7d8f-4xk2m --tail=200 -f
# -f 持续跟踪（类似 tail -f），排查实时请求时非常有用

# 4. 进容器直接验证 — 终极手段
kubectl exec -it -n test-env user-service-7d8f-4xk2m -- sh

# 进去后可以 curl、cat 配置文件、检查环境变量
curl http://localhost:8080/api/user/123
env | grep DB_

典型排查链路

用户报 bug → 你查日志 kubectl logs → 
发现是 DB 连接超时 → 进容器 curl DB 端口不通 → 
describe pod 发现 Endpoints 为空 → 
定位：Service selector 写错了

这个链路不需要运维介入，测试自己就能走完。排查自主权是学 K8s 最大的 ROI。

3. 配置管理：告别硬编码

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
  namespace: test-env
data:
  base_url: "https://api.dev.xxx.com"
  log_level: "DEBUG"
  mock_payment: "true"
  timeout_seconds: "30"

环境切换流程：

# 切到 staging 环境
kubectl edit configmap test-config -n test-env
# 改 base_url: "https://api.staging.xxx.com"

# 重启 Pod 让新配置生效
kubectl rollout restart deployment api-test-runner -n test-env

配合 ConfigMap 的批量管理：

# 从文件创建/更新 ConfigMap
kubectl create configmap test-config \
  --from-file=configs/dev.yaml \
  -n test-env \
  --dry-run=client -o yaml | kubectl apply -f -
配置类型存储位置示例
非敏感配置ConfigMapbase_url, log_level, feature_flags
敏感信息SecretDB 密码, API Key, Token
代码级配置pytest conftestfixture scope, marker 注册

精简学习路线（8 周）

第 1 周：核心概念（纯理论）

理解 4 个核心对象的层级关系：

Pod ← Deployment ← Service ← Ingress
  • Pod：最小调度单元，一个或多个容器
  • Deployment：管理 Pod 的副本数、滚动更新
  • Service：给 Pod 提供稳定的访问地址（Pod IP 会变）
  • Ingress：从集群外部访问 Service

不需要动手，画张图搞清楚"谁管谁"就行。

第 2-3 周：kubectl 命令

只练这四个：get、describe、logs、exec。80% 的日常操作不超出这个范围。

kubectl get pods,svc,deploy -n <namespace>   # 一览
kubectl describe pod <name> -n <ns>           # 详情
kubectl logs <pod> -n <ns> --tail=100         # 日志
kubectl exec -it <pod> -n <ns> -- sh          # 进入

第 4 周：第一个 Deployment

用 minikube 或 Docker Desktop 自带的 K8s，把你的测试服务部署上去。

第 5-6 周：ConfigMap + Secret

把硬编码的配置迁移到 ConfigMap。这一步是测试环境管理水平的质变。

第 7-8 周：Helm（按需）

如果团队已经在用 Helm，学会 helm install、看懂 values.yaml、会改参数。不需要从零写 Chart。

总结

维度需要不需要
核心对象Pod, Deployment, Service, ConfigMap, SecretPV/PVC, RBAC, ServiceAccount, NetworkPolicy
操作get, describe, logs, exec, apply, edit搭集群, 配 CNI, 管 etcd
部署写 Deployment YAML, 设资源配额, 配健康检查写 Operator, CRD, 自定义 Controller
工具kubectl, Helm（会用）kubeadm, kustomize（可后续补）
认证无CKA/CKAD（除非想转运维）

2026 年 7 月 | 约 2400 字 | 预计阅读 7 分钟

avatar
文章
阅读
粉丝