“原生Kubernetes容器云平台基本测试使用”这件事我最近刚完整走了一遍。所谓原生就是集群里的 kube-apiserver、kube-controller-manager、etcd、kubelet 全部采用社区原版组件没有套发行版外壳也不依赖云厂商托管。好处是行为最贴近官方定义踩坑之后能直接对应到社区 issue坏处是控制面、网络、存储、监控全部自己负责。这篇文章把所有验证过的项目、实际敲过的命令、以及中途遇到的故障完整记录下来无论你是刚用 kubeadm 把集群搭起来的新手还是维护自建平台的老手这份清单都能帮你确认平台到底能不能交付使用。1. 测试前准备确认集群状态与设计测试思路1.1 原生集群和托管服务差在哪很多人问我为什么不直接用云上的托管容器服务非要自己搭原生 Kubernetes 平台再跑测试。最核心的差异在于“责任边界”托管服务把控制面、etcd、证书轮换、节点伸缩都包了你只需要关心工作负载而原生集群里etcd 备份、控制面高可用、CNI 网络性能、存储插件兼容性甚至节点和 apiserver 的时钟同步偏差每一样都要自己兜底。这直接决定了测试的方式。托管服务的“基本测试”通常是跑一遍业务冒烟看 Pod 能不能跑起来、服务能不能通原生平台的基本测试得额外验证控制面自愈能力、调度器行为、网络插件策略、存储生命周期这些底层能力。用一个形象的比喻托管服务像是租精装修公寓你只需要检查水电原生集群像是毛坯房自己装修得连墙里的管线一并验收。所以我在设计测试计划时目标不是“压测性能”而是建立一条明确的功能基线平台具备最基本的可用性、隔离性、自愈性和可观测性。如果这条基线都过不了谈性能优化和生产上架都是空谈。1.2 环境清单与验收标准动手测试之前先把集群当前状态摸清楚。我的环境是三节点集群一个控制面节点加两个工作节点操作系统都是主流 Linux 发行版容器运行时使用 containerd网络插件用的是常见的开源 CNICalico 或 Flannel 按部署方式选其一存储方面预先装好了一个本地动态供给的 StorageClass比如 local-path 这类方案。这个配置是自建原生集群最常见的形态测试结论有普适性。检查项命令预期结果节点状态kubectl get nodes -o wide全部 ReadyKUBELET 版本一致控制面组件kubectl get componentstatusetcd、scheduler、controller-manager 全部 Healthy核心插件kubectl get pods -n kube-systemCoreDNS、metrics-server、CNI 全部 Running集群版本kubectl versionserver/client 版本差异不超过一个小版本这里重点是确认 CoreDNS 和 metrics-server 是否就绪因为后面的 DNS 解析和 HPA 自动扩缩容测试都依赖这两个组件。当时我碰到一个问题节点显示 Ready但 CoreDNS 一直 CrashLoopBackOff排查后发现是节点 iptables 规则兼容性问题。这意味着表面健康的集群内部可能埋着雷提前做基础检查能省掉后面大量的无效测试时间。1.3 测试用例的设计原则基本测试不等于随便玩玩。我的设计原则有三个第一覆盖分布式系统的核心操作链路而不是只测单点功能。比如部署一个应用要顺带验证标签选择器是否生效、网络是否跨节点互通更新一个应用要验证滚动策略和可用性保持。第二所有测试都要有明确的“预期结果”。比如 Pod 调度到哪个节点、Service 的 ClusterIP 是否稳定、PVC 释放后数据是否还在这些指标都要先写下来测完逐项对照避免“看起来没报错就算通过”。第三测试环境要与生产隔离。我在集群中单独创建了dev、prod两个命名空间分别做粗粒度功能验证和精细化策略验证所有测试资源集中放在test命名空间中测完统一清理不影响已有业务。依据这套原则我把测试拆成工作面、可靠性、租户隔离、可观测性、故障排查五个方向正好对应下面的章节。2. 核心功能验证工作负载部署与访问链路2.1 命名空间隔离与资源配额实测命名空间是最基础的隔离维度。我在集群里先创建了一个测试命名空间kubectl create namespace dev然后施加资源配额避免某个测试应用把集群资源吃光影响同集群里的其他业务。apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota namespace: dev spec: hard: requests.cpu: 2 requests.memory: 4Gi limits.cpu: 4 limits.memory: 8Gi pods: 10 persistentvolumeclaims: 2应用后执行kubectl get resourcequota dev-quota -n dev能看到配额已经生效。配额数字不是拍脑袋定的按集群总规格3 节点 × 4 核 8G 12 核 24G计算给 dev 环境分配约 1/3 的总额度既满足测试需求又给其余命名空间留足了空间。接着做个负向验证尝试创建一个超过内存限制的 Pod。命令是kubectl apply -n dev -f - EOF apiVersion: v1 kind: Pod metadata: name: over-limit-pod spec: containers: - name: app image: registry.example.com/busybox:latest command: [sh, -c, sleep 3600] resources: requests: memory: 6Gi EOF提交后立刻被 API Server 拒绝提示exceeded quota。这说明配额限制真正被强制执行而不是仅仅停留在声明层面。这轮验证的价值在于平台作为“容器云”提供给多个团队使用时必须保证单个租户的资源申请边界可以被有效管控。2.2 多副本部署与调度结果检查配额没问题接着部署一个有状态的工作负载验证 Deployment 控制器的调度能力。kubectl create deployment web-demo --imageregistry.example.com/web-demo:v1 --replicas3 -n dev kubectl get pods -n dev -o wide看到三个 Pod 分别分布在两个工作节点上说明调度器正常工作。这一步看似普通但原生平台最容易在调度环节暴露出两个问题一是节点标签或污点配置错误导致 Pod 全部挤到同一个节点二是节点资源分配超卖出现调度成功但容器无法启动的情况。为了验证调度稳定性我还做了一个小实验随机挑一个节点执行kubectl cordon node把节点置为不可调度再扩容到 5 个副本。观察新 Pod 是否全部落在其余节点上确认调度器尊重节点状态约束。之后用kubectl uncordon node恢复。这个验证能有效证明平台在工作节点故障时具备基础的调度规避能力。2.3 Service与Ingress暴露访问全验证集群内部调度稳定接下来验证应用对外暴露的能力。服务暴露链路需要逐层打通Pod 的 IP 只存在于集群内ClusterIP 提供虚拟访问入口NodePort 把流量引到宿主机端口Ingress 负责接入集群外 HTTP/HTTPS 流量。先创建一个 ClusterIP 类型的 Servicekubectl expose deployment web-demo --port80 --target-port8080 --typeClusterIP -n dev kubectl get svc -n dev进入集群内任意 Podkubectl exec -it 任意pod -n dev -- curl http://web-demo.dev.svc.cluster.local能返回页面说明集群内 DNS 解析正确CoreDNS 工作正常Service 的 Endpoint 已正确绑定到三个背后的 Pod IP。再验证 NodePortkubectl edit svc web-demo -n dev # 修改 type: NodePort观察分配的 nodePort 端口例如 31234 curl http://任意节点IP:31234这里有个值得注意的细节NodePort 是“所有节点都监听同一个端口”也就是说即使某个 Pod 没有调度到当前节点请求到该节点也能被转发到后端 Pod。验证通过之后还要测试从外部访问集群内网需要额外配置 Ingress 规则。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-demo-ingress namespace: dev spec: ingressClassName: nginx rules: - host: demo.example.local http: paths: - path: / pathType: Prefix backend: service: name: web-demo port: number: 80应用之后在测试机 hosts 文件里加上demo.example.local指向 Ingress Controller 所在节点浏览器访问就能看到应用页面。链路全部打通平台的核心网络功能基本可以确认。2.4 配置与密钥注入的两种方式容器应用离不开配置管理。原生 Kubernetes 平台提供 ConfigMap 和 Secret 两类对象接入方式主要有环境变量和文件挂载两种。我在测试中两种方式都做了验证。数据准备kubectl create cm app-config -n dev \ --from-literalAPP_ENVproduction \ --from-literalLOG_LEVELinfo kubectl create secret generic db-secret -n dev \ --from-literalDB_PASSWORDPssw0rd环境变量方式在 Deployment 里用envFrom引入 ConfigMap 和 Secret容器启动后env命令能看到对应变量。文件挂载方式把 ConfigMap 挂载到容器内的/etc/configSecret 挂载到/etc/secret进入容器确认文件内容和解码后的值。这里重点验证一个容易踩坑的点环境变量注入的配置修改 ConfigMap 后需要滚动重启 Pod 才能生效文件挂载方式则默认由 kubelet 周期性同步通常几十秒内新内容就会覆盖到挂载点某些场景下甚至不需要重启。我实际测下来确实如此这对于后续做配置热更新方案选型很有参考价值。还需要注意Secret 只是做了 Base64 编码不是真正加密。在原生平台上如果不额外做静态加密或集成外部密钥系统Secret 的价值主要体现在避免明文出现在配置文件和镜像环境变量里。测试报告里必须写明这个安全边界避免团队成员误以为 Secret 是安全的加密存储方案。3. 可靠性专项滚动更新、弹性伸缩与故障自愈3.1 滚动更新与回滚全流程工作负载部署有更新需求时Deployment 默认走 RollingUpdate 策略。这个策略的精髓在于“先增后删”保证更新过程中服务不中断。我模拟一次版本升级kubectl set image deployment/web-demo web-demoregistry.example.com/web-demo:v2 -n dev kubectl rollout status deployment/web-demo -n devrollout status输出滚动更新过程可以看到旧副本逐个缩减、新副本逐个扩容。滚动更新的关键参数是maxSurge和maxUnavailable默认值都是 25%含义是更新过程中最多允许多出 25% 的新副本同时最多允许 25% 的旧副本不可用。对于生产环境来说这两个参数需要根据服务承载能力明确调整比如当只有 3 个副本时25% 近似于 1 个副本滚动过程最小可用副本数为 2如果业务要求至少保持 3 个副本在线就得把maxUnavailable设为 0。更新完成后查看版本历史kubectl rollout history deployment/web-demo -n dev如果新版本出现严重问题需要快速恢复执行kubectl rollout undo deployment/web-demo -n dev回滚会自动复用上一次的 ReplicaSetPod 重新拉取旧镜像并调度整个过程同样走滚动策略不需要人工介入。实测中我还验证了“回滚到指定版本”的用法比如kubectl rollout undo deployment/web-demo --to-revision1。这轮测试下来我对原生 Deployment 控制器的可靠性印象还是很深的整个过程没有出现过流量中断。3.2 HPA弹性伸缩触发与回收弹性伸缩是容器云平台的核心卖点之一原生 Kubernetes 用 HPAHorizontalPodAutoscaler实现。前提是集群里已经部署好 metrics-serverHPA 通过 metrics API 读取 Pod 的 CPU/内存指标再计算期望副本数。我先给web-demo创建 HPA 规则kubectl autoscale deployment web-demo --cpu-percent60 --min1 --max5 -n dev kubectl get hpa -n dev这里解释一下参数选择--cpu-percent60是当前较为稳妥的阈值设置太低会导致副本频繁扩缩设置太高则可能在流量高峰时来不及扩容。--min1, --max5则限定了副本数浮动区间避免极端场景下无限扩容消耗集群资源。为了触发扩容动作我跑了一个模拟压力客户端kubectl run -i --tty load-generator --imageregistry.example.com/busybox --restartNever -n dev -- sh -c while true; do wget -q -O- http://web-demo.dev.svc.cluster.local; done观察 HPA 状态kubectl get hpa -n dev kubectl describe hpa web-demo -n dev大约 1 到 2 分钟内HPA 检测到当前 CPU 超过阈值把副本数从 1 逐步提升到 4 或 5。这里说“逐步”是因为 HPA 默认有冷却时间窗口防止副本数抖动。压力停止后指标下降到阈值以下再等几分钟副本数回落到 1。这个过程中我注意到 metrics-server 默认的采集周期是 15 秒HPA 控制器默认同步周期是 15 秒加上冷却时间整个伸缩响应周期大约在 60 到 120 秒。所以在真实生产里如果业务对弹性有更严苛的需求需要评估调整这些默认参数而不是期望压测瞬间就能看到扩容。3.3 PVC持久化存储验证很多有状态应用数据库、消息队列、文件服务依赖持久化存储PVC 是整个存储抽象的核心验证项。我事先安装的是本地路径动态供给 StorageClass名字是local-path它会自动为 PVC 创建宿主机目录并绑定 PV。定义一个 PVC 并让 Pod 挂载apiVersion: v1 kind: PersistentVolumeClaim metadata: name:>volumes: - name: data persistentVolumeClaim: claimName:>kubectl exec -it pod -n dev -- sh -c echo persistent data /data/marker.txt cat /data/marker.txt接着删除 Podkubectl delete pod pod -n dev再重新创建同一份 Deployment使用同一个 PVC进入新容器读取/data/marker.txt文件内容还在说明存储的生命周期与 Pod 分离数据持久性验证通过。值得注意的是ReadWriteOnce意味着存储卷同一时间只能被一个节点挂载如果两个副本的 Pod 被调度到不同节点第二个 Pod 启动时会卡在 ContainerCreating。这时候调度器会把 PVC 看作一个约束条件尽量将 Pod 调度到绑定 PV 的节点。本地存储类在跨节点调度时存在天然局限如果业务需要多副本共享存储原生集群里更合适的方案是 NFS、CephFS 这类支持ReadWriteMany的存储后端。3.4 节点故障与Pod重调度实测自愈能力是平台级测试的重头戏。我模拟了两种典型故障场景场景一单节点 kubelet 异常。登录某个工作节点执行sudo systemctl stop kubelet随后在控制面节点观察状态变化kubectl get nodes kubectl get pods -n dev -o wide节点状态大约在 40 秒到 1 分钟内变为NotReady。Pod 并不会立刻迁移这符合预期控制面需要先通过心跳超时确认节点失联然后由 NodeLifecycleController 触发 Pod 驱逐默认的 Pod 驱逐宽限期约 5 分钟。等驱逐发生后原本运行在该节点的 Pod 会变成Terminating状态然后调度器在其他可用节点上重新创建新 Pod。这里有一个关键点Pod 被驱逐不是“实时热迁移”而是“优雅终止后重新创建”。也就是说应用必须设计为无状态或支持故障恢复否则节点故障必然带来短暂的服务中断。场景二控制面组件异常。我执行了sudo systemctl restart kubelet以及模拟控制面节点重启确认集群在控制面恢复后能正常对外提供服务etcd 数据没有丢失Deployment 状态能自动对齐。通过这两组模拟测试平台的自愈能力基本确认。4. 多租户与网络策略权限隔离验证4.1 RBAC最小权限模型实战原生 Kubernetes 平台面向多个团队时必须验证 RBAC 权限模型是否真正生效。测试目标创建一个只能查看 Pod 的只读用户确保它不能修改或删除任何资源。kubectl create namespace dev kubectl create serviceaccount readonly-user -n dev kubectl create role pod-reader -n dev --verbget,list,watch --resourcepods kubectl create rolebinding readonly-binding -n dev --rolepod-reader --serviceaccountdev:readonly-user获取该 ServiceAccount 的 Tokenkubectl create token readonly-user -n dev携带 Token 执行操作kubectl get pods -n dev --tokenTOKEN # 执行成功 kubectl delete pod web-demo-xxx -n dev --tokenTOKEN # 返回 Forbidden只读用户被拒绝执行删除操作RBAC 生效。这里需要重点解释 Role 与 ClusterRole 的区别Role 只作用于某个命名空间ClusterRole 作用于整个集群或跨命名空间资源如节点、存储类。实际建设中管理员分权的最佳实践是“按团队拆命名空间 按职责拆 ClusterRole”避免给普通用户分配过大的集群权限。测试发现ServiceAccount 默认没有绑定任何权限默认 Token 也无法访问集群任意资源。平台默认的最小权限约束在这一步体现得非常好——它保证了即使某个 Pod 被攻破攻击者也只能利用该 Pod 的 ServiceAccount 权限而不能直接控制集群。4.2 NetworkPolicy默认拒绝与放行网络策略用于控制 Pod 之间、Pod 与外部服务之间的流量。它依赖 CNI 插件支持Flannel 默认不支持Calico/Cilium 支持所以这一步实际验证的是“CNI 网络策略能力的执行链路”。我创建两个测试 Pod分别打上标签appdb和appweb默认情况下它们可以互相访问。然后应用一个拒绝所有入站流量的 NetworkPolicyapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: dev spec: podSelector: {} policyTypes: - Ingress应用后从webPod 的容器里curl dbPod 的 IP直接超时。这说明数据面网络策略已经生效。再创建一个放行策略仅允许携带appweb标签的 Pod 访问appdbapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-web-to-db namespace: dev spec: podSelector: matchLabels: app: db ingress: - from: - podSelector: matchLabels: app: web应用后复查webPod 又能访问dbPod而其他标签的 Pod 依旧不可访问。网络策略的实际意义在于集群内部默认的“全互通”模式并不适合多租户环境。合理使用 NetworkPolicy 才能做到微服务之间的最小网络暴露面。这轮测试也验证了原生 CNI 在策略执行上的完整性数据平面确实按照控制面的规则在做过滤而不是只在文档层面支持。5. 可观测性验证监控与日志链路5.1 指标采集与HPA依赖验证平台基本使用必须包含可观测性验证。我首先确认 metrics-server 的指标链路是否正常kubectl top nodes kubectl top pods -n dev如果这两条命令能返回 CPU 和内存使用量说明 metrics API 和 kubelet 的指标采集链路是健康的。这里有个逻辑闭环值得强调前面 HPA 测试能成功触发扩缩容本质上依赖于 metrics-server 提供资源指标所以这轮验证会自然回归一遍 HPA 行为。生产级观察还需要部署指标聚合方案。我临时在kube-system中部署了一套常用的开源监控栈由服务发现组件抓取各个 exporter 的指标 时序数据库保存时间序列数据 可视化面板展示图表三个部分组成。部署完成后在控制面板里能看到节点 CPU 使用率、内存使用率、Pod 重启次数等基础指标确认从指标生成、抓取采集到持久化存储、前端展示的完整链路没有断点。对原生平台来说监控是“保底工程”不是“锦上添花”。没有指标数据HPA 无法扩容故障定位缺少数据支撑容量规划更无从谈起。这轮测试至少需要确认指标采集不缺失、指标查询接口可达、核心组件能暴露指标数据。5.2 容器日志收集验证日志收集分两个层级单个 Pod 的日志查看和集群级别的日志聚合。单个 Pod 日志验证比较简单kubectl logs deployment/web-demo -n dev --tail50 kubectl logs -l appweb-demo -n dev --since10m--since10m可以避免大量日志刷屏。这里要特别提醒一个常见误区kubectl logs只能看到容器的标准输出和标准错误如果应用把日志写入文件而不是 stdoutkubectl logs什么都看不到。容器应用的最佳实践是统一采集 stdout 日志这也是原生平台的默认假设。集群级别的日志聚合需要引入日志收集器。常见方案有两种在节点上以 DaemonSet 方式部署日志采集代理把宿主机容器日志目录下的文件转发到集中式日志服务或者为每个容器挂载 Sidecar 日志容器转发文件日志到日志服务。考虑到很多团队还没有部署集中式日志系统我在测试时采用一种轻量验证方式确认日志采集组件能识别容器日志目录/var/lib/docker/containers或 containerd 对应的日志目录在控制台能查询到关键业务日志的关键字并且日志有时间戳和 Pod 元数据标注。6. 测试中的典型故障与排查方法实录6.1 Pod一直Pending怎么定位这是最高频的问题。Pod 长时间处于Pending核心原因几乎都集中在调度环节。我遇到过三类情况一是节点资源不足比如 CPU 或内存的 requests 超过节点可分配量二是 PVC 无法绑定StorageClass 未安装或卷容量超限三是节点亲和性/污点限制Pod 能落下的节点全部被NoSchedule或NoExecute污点排除。排查顺序非常关键。先看事件kubectl describe pod pod-name -n devEvents 里如果出现0/3 nodes are available: insufficient cpu说明资源不足如果出现waiting for pod to be scheduled且PersistentVolumeClaim为绑定中则优先处理存储问题如果看到node(s) had taint则要检查节点污点配置。这套定位方法看起来简单实际效率很高大多数 Pending 的根因 80% 都能在 describe 输出里找到。6.2 镜像拉取失败的常见根因镜像拉取失败的典型错误是ErrImagePull或ImagePullBackOff。原生集群中最常见的根因有三类私有镜像仓库证书未配置需要在/etc/containerd/config.toml中配置[plugins.io.containerd.grpc.v1.cri.registry.mirrors]和auth信息imagePullPolicy设为Always但环境离线无法访问公网镜像源镜像 tag 写错或者镜像不存在。排查时可以执行kubectl get events -n dev --sort-by.lastTimestamp直接看 Kubelet 上报的具体拉取错误。如果是证书类问题通常关键字x509: certificate signed by unknown authority如果是网络不可达通常是net/http: TLS handshake timeout。定位到原因后配置镜像仓库并重启 containerd 即可恢复。6.3 Service不通与DNS解析异常Service 不通通常伴随核心链路故障。我的排查顺序是从内到外、从 DNS 到网络。先在集群内启动一个测试 Pod执行nslookup web-demo.dev.svc.cluster.local如果 nslookup 返回server cant find基本可以定位是 CoreDNS 问题检查 CoreDNS Pod 是否 Running、名称是否在 kube-system 下、上游 DNS 是否可达如果 DNS 能解析出 ClusterIP但访问仍然不通则检查 Service 的 Endpoint 是否正常kubectl get endpoints web-demo -n dev如果 Endpoint 为空说明 Service 的 Label Selector 和 Pod 的标签不匹配这是最容易被忽略的配置错误。如果 Endpoint 存在但 curl 超时下一步检查 kube-proxy 是否正常、节点 iptables 规则是否被外部清理或冲突。实测中发现某些 CNI 插件升级后会把节点上已有的自定义 iptables 规则清空从而影响 NodePort 转发这种问题需要结合系统网络规则和 CNI 日志联合排查。6.4 节点NotReady排查顺序节点进入NotReady时我的操作顺序是先查看节点状态里的 condition Message再检查 Kubelet 服务状态然后查看节点日志最后检查 CNI 和磁盘。kubectl describe node node-name | grep -A 5 Conditions systemctl status kubelet journalctl -u kubelet -n 100常见根因包括kubelet 证书过期、磁盘压力DiskPressure、内存压力MemoryPressure、CNI 插件挂载目录异常、节点与 apiserver 网络不通。证书过期在一年以上的集群里很常见需要提前检查证书轮换机制磁盘压力则通常可以通过清理镜像和日志缓解。节点 NotReady 并不是瞬间发生的它经历过从Ready到NotReady的状态翻转过程条件信息里一般会写明最后一次成功心跳的时间对照这个时间点和节点事件可以快速收敛排查范围。提示节点 NotReady 后叠加默认的 Pod 驱逐时间约 5 分钟策略会开始在新节点重建 Pod。如果在生产环境遇到节点短暂抖动导致大面积 Pod 重建先别急着重启节点很多人忽略了这个时间窗口的价值——等待几秒可能就自动恢复了。7. 写在最后我在这轮测试里学到的东西这轮原生 Kubernetes 容器云平台基本测试做完最大的感受是功能验证不难难的是理解每个验证项背后的机制关系。HPA 依赖 metrics-serverPVC 绑定依赖 StorageClassService 转发依赖 kube-proxy 和 CNI 协同Ingress 依赖 Controller 的部署方式。这些依赖不亲自测一遍光看文档是体会不到的。还有一个特别想分享的经验测试过程中不要只盯着“通过”的用例把每一个看似偶然的报错都认真看完。这次测试里最值钱的发现正是来自一个“莫名其妙”的 CoreDNS CrashLoopBackOff 问题它暴露出集群底层网络兼容性隐患这比十个通过用例更有价值。原生平台的运维思路就是这样所有能力都是构建在层层组件之上基础不牢上层再漂亮的 Pod 调度也没有意义。