[CI/CD] 排障实录：内网环境下 Jenkins + ArgoCD 流水线搭建

说明：本文基于个人学习测试环境编写，部分配置（如镜像仓库使用 HTTP、NodePort 暴露服务等）仅为简化演示，仅供参考，生产环境请遵循安全规范。1. 基本信息任务类型：部署 / 故障排查涉及系统/服务：K3s 集群（v1.33.4+k3s1，1 Master + 2 Worker）Jenkins（Helm 部署于jenkins命名空间，版本 2.541.3-jdk21）ArgoCD（v3.3.3，部署于argocd命名空间）私有 Docker Registry（registry:2，NodePort 31830，HTTP 协议）Gitee（代码托管，simple-webapp-source与k8s-manifests两仓库）FRP（内网穿透，用于 Gitee Webhook 触发内网 Jenkins）Trivy（漏洞扫描器，版本 0.59.1）containerd（K3s 内置运行时）最终状态：部分成功。流水线核心阶段（代码拉取、镜像构建、推送、配置仓库更新）已验证可行；安全扫描阶段因 Trivy 漏洞数据库推送中而待最终验证；ArgoCD 同步状态已就绪但尚未进行端到端部署测试。2. 问题描述 / 部署目标2.1 目标构建一套基于 GitOps 的 CI/CD 流水线，用于示例应用simple-webapp（Go 后端 + 静态前端）的自动构建与部署。完整流程如下：开发者推送代码到 Gitee 源码仓库simple-webapp-source。Gitee Webhook 通过 FRP 内网穿透触发 Jenkins Pipeline。Jenkins 动态创建 Kubernetes Pod（含 Docker-in-Docker 容器），在 Pod 内执行：拉取源码构建后端与前端 Docker 镜像推送镜像到集群内私有 Registry（registry.registry.svc.cluster.local:5000）克隆配置仓库k8s-manifests，更新其中的镜像标签推送配置仓库变更ArgoCD 监测到配置仓库变更后，自动将最新版本部署到 K3s 集群的simple-webapp命名空间。2.2 初始问题现象用户已完成基础组件部署（ArgoCD、Registry、Jenkins），但在首次触发 Jenkins 构建时，Agent Pod 始终处于ImagePullBackOff或ErrImagePull状态，报错http: server gave HTTP response to HTTPS client或no such host。手动测试发现 Jenkins 主 Pod 可解析 Registry 内部域名，但动态 Agent Pod 无法解析。即使手动推送镜像至私有仓库，Pod 拉取仍失败，且后续构建阶段因缺少 Docker 命令、外网不通等连环失败。3. 系统/网络架构图内网 192.168.34.0/24公网K3s Master DebianVM203Webhook POST内网穿透转发到创建 Agent Pod拉取基础镜像/推送产物更新配置仓库每3分钟拉取配置同步部署Gitee 代码仓库/simple-webapp-source/k8s-manifestsFRP Server公网 IPJenkins Podjenkins/jenkinsNodePort 30080ArgoCD Serverargocd/argocd-serverRegistry Podregistry/registryClusterIP 10.43.138.13:5000NodePort 31830CoreDNS10.43.0.10FRP ClientWorker 192.168.34.201Worker 192.168.34.202K3s-API