简介面向Kubernetes集群运维与监控工程师这份资源整理了以Prometheus、Grafana、Alertmanager为核心的K8s监控组件镜像清单与离线镜像合集可解决内网或离线环境下镜像拉取困难、监控组件分散部署成本高的问题。包体共124个文件约650.88MB涵盖57个yaml/yml配置、16个gz镜像压缩包、14个txt清单与说明、8个json规则并附有prometheus-webhook-dingtalk、alertmanager、amtool等常用二进制工具及license、service等辅助文件配置与部署所需材料基本齐全。资源中可直接提取grafana.tar.gz、prometheus.tar.gz等镜像包配合yaml声明式配置和告警模板快速拉起监控栈同时适合对照txt说明梳理组件清单、镜像版本与部署顺序。目前已有383人学习下载对于需要离线交付K8s监控方案或希望减少逐一下载镜像、调试告警配置的运维人员能明显提升落地效率。1. K8S集群监控资源镜像清单为什么先清点镜像再动手K8S集群监控资源镜像清单听起来不过是一份记录镜像名和tag的表格但我在某次内部交付中被它狠狠地上了一课Prometheus容器反复起不来查了半天配置没有一处错误最后发现是镜像版本错位——在线环境拉的是新tag离线环境同步的还是旧tag。从那以后凡是涉及监控栈的离线交付我都会先把镜像清单完整清点一遍再把镜像合集同步进内网仓库。这份清单要解决的是部署前“盲拉镜像”的风险把node-exporter、kube-state-metrics、Prometheus、Alertmanager、Grafana这一整套组件的镜像按版本对齐、按仓库固定并能在内网环境中提前验证可拉取。适合做离线交付、私服同步、小团队维护K8S集群的运维人员也适合刚接手监控栈部署、想少踩坑的新手。2. 监控栈镜像从哪来组件全景与版本匹配2.1 监控栈的镜像构成采集器、时序库与可视化组件K8S监控栈不是一个“大而全”的镜像而是多个独立镜像组成的集合。我一般会先把组件拆开再逐个确认镜像来源。最常见的一套组合是node-exporter负责采集宿主机指标kube-state-metrics把K8S对象状态转换成Prometheus指标格式kubelet内嵌的cAdvisor提供容器资源指标Prometheus负责时序存储与查询Alertmanager处理告警路由与通知Grafana做指标可视化。这些镜像的默认来源其实很分散K8S官方组件主要在registry.k8s.iokube-state-metrics在quay.ioGrafana官方chart则把镜像放在Docker Hub。做清单的第一步就是把分散在不同源仓库的镜像统一列出来同时规划内网私服的存放路径。这里有个很容易忽略的点镜像仓库的项目命名空间要按组件划分清楚比如prometheus、kube-state-metrics、grafana各建独立项目而不是把所有镜像丢进同一个目录。否则后续做权限控制、镜像清理时会非常被动。2.2 版本匹配矩阵K8S版本、kube-state-metrics与node-exporter的兼容边界监控栈镜像并不是“最新版就一定好用”。kube-state-metrics对新老K8S版本的兼容性差异很明显旧版本API与新版本K8S对接时指标会出现大量unknown或者干脆连不上API Server。node-exporter则跟节点内核版本、挂载权限绑定老内核环境下部分采集项会为空。Grafana镜像本身兼容性风险小但插件版本与数据源类型不匹配会导致看板渲染失败。我一般不会凭记忆定版本而是打开官方chart的values.yaml直接采用其默认tag并结合官方兼容矩阵核对。版本错位的典型表现可以参考下面这个表这也是我排查时优先对照的症状组件镜像版本取值来源版本错位的典型表现kube-state-metrics官方chart默认tag或官方兼容矩阵kubectl top无数据指标中出现大量unknownnode-exporter官方release推荐tag宿主机指标为空/proc与/sys挂载报权限错误grafana官方chart默认tag数据源插件版本不匹配看板渲染失败2.3 用一条命令抽出集群现状把Deployment里的镜像固化成清单很多人的镜像清单是“从网上抄来的默认列表”但真实集群里跑的镜像往往和chart默认不一样。我习惯的做法是从现有集群中把实际运行的镜像抽出来生成一份基准清单再用这份清单去倒推该补哪些、该替换哪些。下面这个脚本可以快速导出指定命名空间下所有工作负载的镜像列表#!/bin/bash # 从当前集群导出监控组件相关的工作负载镜像清单 NAMESPACESmonitoring kube-system OUT_FILEimage-list.txt : $OUT_FILE for ns in $NAMESPACES; do kubectl -n $ns get deploy,statefulset,daemonset \ -o jsonpath{range .items[*]}{.spec.template.spec.containers[*].image}{\n}{end} $OUT_FILE done sort -u $OUT_FILE -o $OUT_FILE wc -l $OUT_FILE这段脚本的逻辑很直接先通过kubectl的jsonpath遍历Deployment、StatefulSet、DaemonSet三类工作负载从.spec.template.spec.containers[*].image取出所有容器镜像名写入临时文件最后用sort -u去重得到完整清单。wc -l输出的是镜像总数方便后续核对数量是否合理。参数说明NAMESPACES变量需要按实际监控栈所在命名空间调整如果监控栈部署在自建命名空间就改成对应名字。这个脚本只提取了containers没有提取initContainers如果监控栈里存在初始化容器还需要额外处理这个坑会在后面专门展开。生成清单后我建议立刻提交到配置仓库里做版本管理不要只放在本机。3. 镜像合集离线打包与迁移save/load到私服同步3.1 批量拉取与tar打包按命名空间分文件拿到了清单接下来就是把镜像从公网源仓库拉下来、打包、再同步进内网私服。这一步最忌讳的就是“一口气把所有镜像打成一个几十GB的tar包”因为一旦某个镜像层损坏整个包都要重新下载传输。我会按仓库来源拆分打包便于定向重传。#!/bin/bash # 按镜像仓库来源分批拉取并打包离线镜像 MIRROR_PREFIXregistry.example.internal/monitoring TAR_DIR./offline-images mkdir -p $TAR_DIR while read -r image; do # 跳过内网私服已有的镜像避免重复拉取 if [[ $image *example.internal* ]]; then continue fi docker pull $image || echo [ERROR] pull $image pull-errors.log done image-list.txt # 按镜像仓库第一段归类分文件打包 for repo in $(awk -F/ {print $1} image-list.txt | sort -u); do images$(grep ^$repo image-list.txt) docker save $images -o $TAR_DIR/$repo.tar done这段脚本的核心是先逐个docker pull再用awk -F/按镜像名的第一段也就是源仓库域名把镜像分组每组执行一次docker save。这样如果某个源仓库的包推送失败或校验不过只需要重新处理对应的tar包不用整批重来。参数说明MIRROR_PREFIX是内网私服的目标路径用来做本地判定和后续推送pull-errors.log记录拉取失败的镜像这一步很重要不要让任何一条拉取失败悄悄溜过去。另外在打包前要评估磁盘容量tar包的实际占用通常在仓库体积的1.2倍以上而且docker save是单线程写盘建议给临时目录留足余量。3.2 用skopeo把清单镜像同步进内网仓库docker save适合离线环境但如果目标环境有内网镜像仓库我更推荐用skopeo直接完成“源仓库复制到私服”。它不经过本地Docker daemon对自签名证书仓库的支持也更直接。下面是一条典型的复制命令skopeo copy \ --all \ --src-tls-verifyfalse \ --dest-tls-verifyfalse \ docker://quay.io/kube-state-metrics/kube-state-metrics:v2.9.2 \ docker://registry.example.internal/monitoring/kube-state-metrics:v2.9.2命令的逻辑很清楚从quay.io源地址拉取镜像复制到内网私服的目标地址。--all参数会复制镜像的完整多架构manifest列表而不仅仅是当前节点平台对应的单架构镜像这是离线同步多架构集群的关键少了这个参数后面就会遇到平台不匹配的问题。--src-tls-verifyfalse和--dest-tls-verifyfalse分别关闭源端和目标端的TLS证书校验适配内网自签名证书场景。参数说明如果内网私服启用了认证还要追加--dest-creds参数。skopeo的好处是复制过程不落地到本地镜像层因此不会污染本机Docker环境也方便在CI流水线里直接跑。批量同步时我通常把“源地址 目标地址”按空格分隔写成一个镜像映射文件再用循环逐条执行。3.3 打包后的完整性检查镜像复制完不要急着部署。先做完整性检查这一步能提前拦截大批“部署时才发现镜像少层”的翻车现场。我一般检查三个点一是tar包能否正常docker load二是私服仓库里的镜像digest是否与源仓库一致三是多架构manifest是否完整。检查digest最简单的方式是skopeo inspect命令它能直连仓库查看镜像的元信息不占本地磁盘空间。例如skopeo inspect --format {{.Digest}} docker://quay.io/kube-state-metrics/kube-state-metrics:v2.9.2 skopeo inspect --format {{.Digest}} docker://registry.example.internal/monitoring/kube-state-metrics:v2.9.2两条命令分别输出源仓库与私服仓库的digest内容一致说明镜像层完整不一致则说明同步过程中出现了层丢失或覆盖需要重推。这里有个细节多架构镜像如果不加--raw参数默认只看当前平台对应的manifest想要做全量架构校验需要对比--raw输出的内容。4. 离线部署监控栈的常见坑镜像清单总在交付后翻车4.1 tag漂移让“同名tag”内容不一样在某次交付中内网私服里的kube-state-metrics:v2.9.2和公网源的kube-state-metrics:v2.9.2内容不一致部署后指标缺失排查了很久才怀疑到镜像层面。原因是第一次同步时用了浮动tag公网源后来重新推送了同名tag的镜像而内网私服没有跟随更新。浮动tag本身就是“可变指针”同一名字在不同时间点可能指向不同内容。解决这个问题需要在清单和同步脚本里固定digest也就是用“镜像名sha256:xxxx”的方式记录和拉取。这样一来哪怕源端tag发生了漂移我们拉取的仍然是当初验证过的那一份内容。4.2 PullPolicy为Always导致离线环境反复重试节点上明明已经有这个镜像Pod却一直处于ImagePullBackOff状态这是离线环境里最典型的尴尬场面。原因多半是工作负载的imagePullPolicy被设成了Alwayskubelet每次启动容器都尝试连接远端仓库离线网络超时后反复重试。解决方法是把监控栈所有工作负载的imagePullPolicy统一改成IfNotPresent在Helm values里覆盖或者在渲染后的YAML里全局替换。如果改完还是拉取失败再去检查节点上是否真的存在这个镜像、镜像名是否正确而不是盯着Pod日志空转。4.3 镜像地址写死在Chart里切私服要全局替换从公网下载的监控栈chart部署到内网后镜像地址仍然指向registry.k8s.io或quay.ioPod根本拉不到镜像。原因是chart的values里把仓库前缀写死了。我常用的做法是先看chart是否支持global.imageRegistry之类的全局镜像仓库配置支持就直接覆盖不支持就先helm template渲染出YAML再按镜像映射关系逐条替换。注意不能简单粗暴地做全局前缀替换因为同一条命令替换所有仓库前缀可能导致镜像路径变形比如registry.k8s.io/kube-state-metrics/kube-state-metrics变成registry.example.internal/monitoring/kube-state-metrics/kube-state-metrics多了一层路径。正确做法是按“源镜像全名到目标镜像全名”的映射逐一替换。4.4 多架构镜像与节点平台不匹配在x86节点上用docker save导出了镜像推到另一批arm64节点上Pod启动直接报exec format error。原因在于docker save默认只导出当前节点平台对应的单架构镜像没有保留manifest list。用skopeo同步时如果忘了加--all同样会丢失多架构信息。解决方法是导出和同步阶段都保留完整manifest列表并在推送后检查镜像的平台信息。可以用skopeo inspect --raw查看manifest list里是否包含arm64和amd64两个条目确认后再部署。4.5 sidecar与init容器不在清点范围内监控Pod的主容器正常启动但init容器一直卡在Init:CrashLoopBackOff这通常意味着镜像清单漏掉了初始化容器。很多导出脚本只提取了containers没有提取spec.initContainers。Grafana的dashboard sidecar、Prometheus的配置加载器这类辅助镜像非常容易被漏掉。解决方法是把清点命令扩展成同时提取两类容器例如kubectl get pods -A -o jsonpath{range .items[*]}{range .spec.initContainers[*]}{.image}{\n}{end}{end} | sort -u把这条命令的输出并入第2章的清单脚本就能避免“主镜像全齐、辅助镜像缺失”的尴尬。离线环境里这一类坑的排查成本往往比主镜像缺失更高因为它表面看起来是启动失败实际却是镜像缺口。5. 用镜像清单驱动部署Helm统一替换与运行态校验5.1 清单驱动Helm values把镜像改成私服地址镜像清单不只是拿来对照的它可以直接驱动部署。把第2章生成的清单整理成映射关系再写到Helm的values里就能保证部署时使用的镜像和清单完全一致。下面是一个典型的values片段prometheus: image: repository: registry.example.internal/monitoring/prometheus tag: v2.53.0 imagePullPolicy: IfNotPresent kube-state-metrics: image: repository: registry.example.internal/monitoring/kube-state-metrics tag: v2.9.2 imagePullPolicy: IfNotPresent这段配置把Prometheus和kube-state-metrics的镜像地址指向内网私服并固定了tag和拉取策略。repository字段必须是私服完整路径tag要和清单一一对应。这里有一个常见误区只改repository不改tag或者只改tag不调整pullPolicy结果部署时又回到公网源仓库拉取。改完values后先渲染一次YAML确认所有镜像都被替换成了私服地址再去执行安装。5.2 部署后校验实际运行镜像与清单逐项比对部署完成不等于部署成功。我每次都会做一次“运行态镜像与期望清单”的比对确认集群中实际运行的镜像与清单完全一致。下面这个脚本可以从运行中的Pod提取镜像并与期望清单做差异比较#!/bin/bash # 校验实际运行的镜像与期望清单是否一致 EXPECTED./image-list.txt ACTUAL./actual-images.txt kubectl get pods -A -o jsonpath{range .items[*]}{range .status.containerStatuses[*]}{.image}{\n}{end}{end} | sort -u $ACTUAL # 将期望清单中的公网仓库前缀统一替换为私服地址后再比对 sed -E s#^(registry\.k8s\.io|quay\.io|docker\.io)/#registry.example.internal/monitoring/# $EXPECTED | sort -u $EXPECTED.normalized echo 清单中存在但未运行的镜像 comm -23 $EXPECTED.normalized $ACTUAL echo 实际运行但不在清单中的镜像 comm -13 $EXPECTED.normalized $ACTUAL这段脚本先用jsonpath从所有Pod的containerStatuses中提取实际镜像名再用sed把公网源仓库前缀统一替换成私服地址最后用comm对比两组数据。comm -23输出的是“清单里有但没运行”的镜像comm -13输出的是“实际运行但清单里没有”的镜像两份输出都为空说明部署和清单完全一致。提示comm要求输入文件已排序所以脚本里对两个文件都执行了sort -u这一步不能省略。如果对比结果有差异不要急着改配置先看差异落在哪一类。清单里有但没运行的镜像多半是chart里还有未清点的依赖组件实际运行但清单里没有的镜像则可能是某个工作负载被手动改过镜像地址。排查Pod拉取失败时kubectl describe pod里的事件信息比容器日志更关键——ErrImagePull代表镜像不存在或无权限ImagePullBackOff通常与网络或仓库地址相关。6. 用digest锁定镜像一个镜像清单校验的落地技巧部署多套集群后最怕的就是“线上用的是v2.9.2内网清单里也是v2.9.2但内容完全不同”。tag一致但镜像层不同的情况在多个镜像仓库之间同步时很容易发生。我后来给清单里每一行都补上了digest用“镜像名:tagsha256:xxxx”的方式记录核对时以digest为准而不是只看tag。获取digest最直接的方式是skopeo inspectskopeo inspect --format {{.Digest}} docker://registry.example.internal/monitoring/kube-state-metrics:v2.9.2这条命令直连内网私服返回该镜像的digest。我会把源仓库与私服仓库的digest放在一起对比一致才放行。批量校验时可以准备一个镜像映射文件mirror-map.txt每行格式是“源镜像地址 目标镜像地址”然后跑下面的脚本#!/bin/bash # 批量核对源仓库与私服仓库的镜像digest while read -r src dst; do src_digest$(skopeo inspect --format {{.Digest}} docker://$src 2/dev/null) dst_digest$(skopeo inspect --format {{.Digest}} docker://$dst 2/dev/null) if [[ $src_digest ! $dst_digest ]]; then echo [MISMATCH] $src - $dst fi done mirror-map.txt脚本逻辑简单直接逐行读取映射文件分别获取源端和目标端的digest不相等就输出MISMATCH。两个注意点skopeo inspect默认取当前平台对应的manifest digest多架构镜像要完整对比需要另加--all或使用--raw查看完整manifest目标仓库没有该tag时dst_digest变量为空会直接被判定为不匹配。这个脚本也可以放进定时任务定期巡检私服镜像的同步状态发现差异及时告警。我现在每次交付前都会把清单跑一遍这个脚本不再只检查tar包大小和文件数量这已经成了我的固定习惯希望帮到你。本文还有配套的精品资源点击获取