测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载导读本文以 origin 仓库中的官方排障文档docs/debugging-openshift.md为骨架系统梳理 OpenShift v3 部署过程中最常见的故障类型与对应的排查步骤从主机环境准备root 权限、firewalld、DNS、iptables、构建Build失败定位、集成容器镜像仓库registry与不安全仓库insecure registry配置到容器探测、容器内 DNS 冲突、Vagrant 共享目录问题以及最终向社区求助前必须采集的 Must Gather 诊断数据。读完本文你将掌握一套从看日志 → 定位根因 → 修复配置 → 重新提交的完整排障闭环并能理解当前 openshift-tests 一致性测试套件为何将oc adm must-gather与构建失败场景纳入正式回归检查。说明该文档面向 OpenShift v3origin时代的部署排障场景文中命令基于oc/oc adm客户端与 Docker 守护进程。当前仓库延续了这一运维体系将 must-gather 与构建失败等排障要点固化为自动化测试详见后文仓库中的呼应证据一节。一、系统环境部署前必须满足的四个前提OpenShift v3 在主机层面有若干硬性依赖排障的第一步往往是回溯环境是否满足这些前提。文档明确指出以下四点1. 以 root 身份启动 OpenShiftOpenShift v3 服务端必须以 root 身份启动因为它需要直接操作宿主机的 iptables 配置为 Pod 网络打通流量路径。注意区分openshift start等服务端进程需要 rootoc create等客户端命令不需要root普通用户即可执行。排障启发若出现网络隔离、Pod 间无法互通等异常先确认服务端是否以 root 运行、iptables 是否被其他进程改动过。2. 正确配置或禁用 firewalld在 Fedora 及其他使用 firewalld 的发行版上需要把docker0网桥加入trusted受信任区域否则 Docker 与 OpenShift 的网络规则可能被防火墙拦截$ firewall-cmd --zonetrusted --change-interfacedocker0 $ systemctl restart firewalld如果不打算使用 firewalld也可以直接停用$ systemctl stop firewalld排障启发容器无法访问外部网络、镜像拉取超时等看似网络故障的问题很多时候是 firewalld 默认区域没有放行docker0导致的。3. 主机 DNS 必须能被容器访问容器需要解析主机名因此如果宿主机上运行了本地 DNS 服务如dnsmasq、named必须更新/etc/resolv.conf改用容器网络可达的 DNS 服务器。文档推荐 Google 的8.8.8.8。排障启发构建日志中出现Could not resolve host见下文构建失败一节时优先检查宿主机/etc/resolv.conf中填写的 DNS 是否位于容器可路由的网段内。4. 重启 iptables 前先保存并恢复规则Docker 会在 iptables 中插入自己的 NAT/过滤规则。如果必须重启 iptables这些规则会丢失导致容器网络异常。正确的操作顺序是先保存、后重启、再恢复$ iptables-save /path/to/iptables.bkp $ systemctl restart iptables $ iptables-restore /path/to/iptables.bkp排障启发如果在重启 iptables 后出现 Pod 无法通信、Service 无法访问多半是 Docker 规则丢失重新执行iptables-restore即可或者重启 Docker 让其重新注入规则。二、构建Build失败排查从 Build 日志到 Docker 日志构建失败是 OpenShift 日常运维中出现频率最高的故障之一。文档给出了从易到难的三级排查路径。第 1 步查看 Build 日志$ oc get builds # 第一列即为 build id $ oc logs build/[build_id]oc get builds会列出当前项目中的所有构建及状态build id 位于第一列oc logs build/[build_id]输出该构建的完整日志通常能直接看到失败原因。可能的失败类型文档列举无法找到源码仓库source repository实际构建过程出错编译、依赖等将构建产物镜像推送到容器镜像仓库失败。第 2 步绕过 OpenShift直接从 Docker 取日志如果通过oc logs无法取回日志说明 Pod/容器可能已处于异常状态可以绕过 Master 直接查询 Docker$ docker ps -a | grep builder列表中最新的容器即为运行本次构建的容器container id 在第一列然后$ docker logs [container id]第 3 步识别典型 DNS 失败并重启 Docker 重试文档给出一个典型故障容器内无法解析任何主机名例如 github.com构建日志表现为E0708 17:28:07.845231 1 git.go:102] fatal: unable to access https://github.com/gabemontero/cakephp-ex.git/: Could not resolve host: github.com; Unknown error处理办法重启 Docker 守护进程然后基于失败的构建重新发起一次构建$ sudo systemctl restart docker $ oc start-build --from-buildyour build identifieroc start-build --from-build会复用原构建的配置源码、上下文目录、策略等重新执行是修复环境后快速重试的标准操作。仓库中的呼应证据构建失败场景正是当前 openshift-tests 一致性测试套件重点覆盖的对象。在 test/extended/builds/build_pruning.go 中e2e 测试通过创建failed-build-config.yaml、执行oc create -f、随后断言构建失败br.AssertFailure()验证failedBuildsHistoryLimit等配置对失败构建清理策略的控制见该文件 L102-L111、L192-L200 等。这说明构建失败不仅是排障手册关注的对象也已被固化为可自动回归的验收项。三、集成镜像仓库Docker Registry检查与启动OpenShift v3 的多数工作流构建推送镜像、Deployment 拉取镜像都假设集群内运行着一个集成容器镜像仓库 Pod。排障的第一步是确认它是否在运行。用oc adm registry --dry-run检查$ oc adm registry --dry-run正常运行时会输出container image registry docker-registry service exists未运行时输出error: docker-registry docker-registry does not exist (no service).未运行时的启动命令$ oc adm registry该命令会按集群默认配置创建docker-registry服务与对应的 Deployment/Pod。排障启发构建成功后镜像推不上去、部署时镜像拉不下来第一排查项就是集成 registry 是否存活--dry-run可以无副作用地先做探测。四、Insecure Docker Registry推送失败的根治配置如果向集成 registry 推送镜像失败构建日志中会出现类似下面的报错E1124 14:51:23.828346 1 dockerutil.go:74] push for image 172.30.216.184:5000/test/image:latest failed, will retry in 5s seconds ... ... F1124 14:51:28.828654 1 builder.go:60] Build error: Failed to push image. Response from registry is: unable to ping registry endpoint https://172.30.216.184:5000/v0/ v2 ping attempt failed with error: Get https://172.30.216.184:5000/v2/: tls: oversized record received with length 20527 v1 ping attempt failed with error: Get https://172.30.216.184:5000/v1/_ping: tls: oversized record received with length 20527tls: oversized record received是明文 HTTP 流量被当作 TLS 解析的典型特征——即 Docker 客户端在向一个非 HTTPS的 registry 强制走 TLS。集成 registry 默认以 HTTP 形式暴露因此必须把其所在网段配置为 Docker 的insecure registry。配置方法场景 ADocker 由 systemd 管理Fedora/CentOS/RHEL 常见编辑/etc/sysconfig/docker在options中追加参数--insecure-registry 172.30.0.0/16然后重启 Docker 守护进程。场景 B直接启动 Docker daemon$ docker daemon --insecure-registry 172.30.0.0/16网段取值依据172.30.0.0/16是 OpenShift 默认的 Service 网段CIDR但你的集群取值可能不同。文档明确要求查阅 OpenShift master 配置文件master-config.yaml中networkConfig.serviceNetworkCIDR字段的实际值将--insecure-registry设置为该值或包含该网段的更大范围。提示serviceNetworkCIDR决定 Service 与集成 registry 的虚拟 IP 归属网段因此 insecure registry 网段必须与其对齐这是按集群实际配置排障而非照抄默认值的关键点。五、探测容器日志、进入命名空间与脱离 Master 的调试当某个容器行为异常时文档推荐三种逐级深入的探测手段。1. 看日志$ docker logs [container id]2. 进入容器命名空间$ docker exec -it [container id] /bin/sh可以进入容器内部查看进程、网络与文件系统状态。3. 脱离 Master 独立调试容器文档特别指出两个常见困境开发 S2I builder 或 Docker 构建时镜像启动即失败liveness probe存活探针误判失败容器在排查前就被杀掉重启。针对容器被 Master 管理、还没来得及看就被销毁的情况可以把 OpenShift 已创建的容器提交为独立镜像脱离 Master 的知识范围进行调试$ docker commit CONTAINER ID some new name $ docker run -it name from previous step /bin/bash这样即可获得一个活的、不被探针和 Pod 生命周期干扰的调试环境。前提是镜像中装有 bash如果没有可以在调试用的镜像里打包进去。另外如果 Pod 已被销毁且依赖的 volume 已被清理docker start CONTAINER ID将无法重启该容器这也是需要走docker commit路线的原因。六、容器内 DNS 冲突dnsmasq 的排查与规避运行在宿主机上的 DNS 相关服务如dnsmasq可能干扰 OpenShift 启动的容器内的域名解析甚至抢占 OpenShift 将要使用的 53 端口。以 Fedora 上的dnsmasq为例文档要求在启动 OpenShift 之前依次执行以下三条命令确保其既不运行、也不会在后续自动启动$ sudo systemctl stop dnsmasq $ sudo systemctl disable dnsmasq $ sudo killall dnsmasqstop立即停止当前进程disable取消开机自启防止后续干扰killall dnsmasq兜底清理可能残留的进程实例。排障启发容器内间歇性 DNS 解析失败端口 53 被占用等问题应优先检查宿主机是否残留 dnsmasq 等本地 DNS 服务。七、良性错误与消息日志中可安全忽略的三类输出OpenShift 日志中会出现一些看起来很吓人但通常无碍的消息。文档明确列出三类可作为日常巡检时的白名单1. Failed to find an IP for podE1125 14:51:49.665095 04523 endpoints_controller.go:74] Failed to find an IP for pod: {{ } {7e5769d2-74dc-11e4-bc62-3c970e3bf0b7 default ...}}判断标准只要不是持续不断重复出现即可视为良性——通常是 Pod 尚未完成网络初始化时 endpoints 控制器的一次性抱怨。2. Proxy connection resetE1125 14:52:36.605423 04523 proxier.go:131] I/O error: read tcp 10.192.208.170:57472: connection reset by peer代理proxier侧连接被对端重置属于网络波动下的常规日志一般无需处理。3. No network settingsW1125 14:53:10.035539 04523 rest.go:231] No network settings: api.ContainerStatus{State:api.ContainerState{Waiting:(*api.ContainerStateWaiting)(0xc208b29b40), ...}}容器尚未获得 Pod IPPodIP:时REST 层常见的警告属正常过渡状态。排障启发将这些消息加入已知良性清单可以显著降低误判率避免把精力浪费在无意义的告警上真正的异常信号是同一错误高频重复出现。八、Vagrant 共享目录卷权限异常的根源与解法如果使用仓库提供的 Vagrantfile 开发 OpenShift默认情况下 origin 目录会通过 vagrant synced folder 挂载到/data/src/github.com/openshift/origin。此时 OpenShift 日志中可能出现如下错误E0706 11:29:43.421460 3664 empty_dir.go:322] Expected directory /data/src/github.com/openshift/origin/openshift.local.volumes/pods/4c390e43-23d2-11e5-b42d-080027c5bfa9/volumes/kubernetes.io~secret/deployer-token-f9mi7 permissions to be: -rwxrwxrwx; got: -rwxrwxr-x E0706 11:29:43.421741 3664 kubelet.go:1114] Unable to mount volumes for pod docker-registry-1-deploy_default: operation not supported; skipping pod E0706 11:29:43.438449 3664 pod_workers.go:108] Error syncing pod 4c390e43-23d2-11e5-b42d-080027c5bfa9, skipping: operation not supported根因共享目录synced folder不支持 ACL访问控制列表而 OpenShift 的 kubelet 依赖 ACL 设置卷权限导致挂载失败并跳过 Pod。解法将卷存储目录移到共享目录之外。通过给openshift start传入--volume-dir指定绝对路径$ openshift start --volume-dir/absolute/path把openshift.local.volumes的落盘位置迁移到非共享目录即可绕开 ACL 限制。九、Must Gather向社区求助前必须采集的诊断数据如果上述手段都无法定位问题在前往社区如 #openshift 频道求助前文档要求先复现问题并开启 verbose 日志然后采集以下三类数据1. OpenShift 日志level 4 详细级别以--loglevel4或等价方式重启/复现采集 verbose 级别的完整日志包含更细粒度的内部事件与调用栈。2. 容器日志全量脚本下面的脚本会拉取宿主机上所有运行过的容器的日志。如果不想保留大量历史可以手动只抓取相关容器for container in $(docker ps -aq); do docker logs $container $LOG_DIR/container-$container.log donedocker ps -aq列出全部容器 id含已退出docker logs导出每个容器的标准输出/错误输出统一落入$LOG_DIR便于打包上传。3. 授权规则Authorization rules如果收到预期之外的forbidden报错或 403 状态码需要采集目标命名空间的 policy bindings、roles 与 rules。将project-namespace替换为实际访问的命名空间依次执行$ oc describe policy default --namespacemaster $ oc describe policybindings master --namespacemaster $ oc describe policy default --namespaceproject-namespace $ oc describe policybindings master --namespaceproject-namespace $ oc describe policybindings project-namespace --namespaceproject-namespace前三类数据齐备后再向社区求助能大幅降低来回沟通成本。仓库中的呼应证据must-gather 已从人工排障步骤升级为一致性测试套件中的正式回归项。在 pkg/test/ginkgo/cmd_runsuite.go 中测试调度器会将名称含[sig-cli] oc adm must-gather的用例从常规 OpenShift 测试中单独拆分出来splitTests单独统计Found %d must-gather tests并在并行测试结束后单独运行这些用例以减少资源争用该文件 L724 附近的注释明确写道 run the must-gather tests after parallel tests to reduce resource contention。这说明oc adm must-gather在现代 OpenShift 中已成为验证集群可诊断性的标准手段也是本仓库openshift-tests即 OpenShift 一致性测试套件持续保障的能力之一。十、排障方法论总结将文档中的经验抽象为可复用的排查顺序环境先行root 权限、firewalld、容器可达的 DNS、iptables 规则持久化——四要素缺一不可日志分层oc logs build/[build_id]→docker logs→docker exec从平台层逐级下沉到容器层配置对齐insecure registry 网段必须与master-config.yaml的networkConfig.serviceNetworkCIDR一致卷目录必须避开不支持 ACL 的共享文件系统白名单过滤先排除文档列出的三类良性错误再聚焦真正重复异常的信号证据收集求助前完成 level 4 日志、容器日志全量与授权规则采集三件套即 Must Gather。这套方法既适用于 v3 时代的自建集群排障也与当前 openshift-tests 仓库的回归验证逻辑一致——构建失败、must-gather 等核心场景均已被固化为自动化测试可在 test/extended/builds/build_pruning.go 与 pkg/test/ginkgo/cmd_runsuite.go 中继续深入研读对应实现。赞分享测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载相关推荐gh_mirrors/do/dockerfiles镜像仓库事件日志审计与故障排查gh_mirrors/do/dockerfiles镜像仓库事件日志审计与故障排查 项目概述 gh_mirrors/do/dockerfiles https:/云原生DevOpsCordis插件组实战用Group组织和管理你的插件王国Cordis插件组实战用Group组织和管理你的插件王国 Cordis 是一款主打「时空可组合性」的元框架Meta Framework of Spatiot后端依赖注入插件系统Falco实战生产环境部署与故障排查Falco实战生产环境部署与故障排查 本文详细介绍了Falco在生产环境中的完整部署方案和故障排查实践。首先通过Docker Compose提供快速部署方案云原生运行时防护IDS应用安全上一篇Pushup部署完全指南Docker、Nix与传统服务器配置下一篇你的微信聊天记录真的安全吗用WeChatMsg实现数据自主的终极方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考