1. 先聊清楚Dashboard和Metrics Server到底各管哪一段很多刚开始接触Kubernetes监控的同学最容易犯的一个认知错误就是把Dashboard当成一个“什么都能看”的监控大屏。装上Dashboard之后发现页面空空如也CPU和内存的曲线永远不显示然后就开始怀疑是不是安装姿势不对。其实Dashboard本身的设计定位是管理界面不是数据采集器。它负责把集群里的工作负载、Pod、Service、存储卷这些资源对象以图形化的方式呈现出来让你不用敲一堆kubectl get命令就能看清楚集群长什么样。但如果你想让Dashboard上的节点卡片和Pod详情页出现CPU、内存的使用曲线和实时数值那必须有另一个组件在背后默默收集这些指标——这就是Metrics Server。两者是配合关系Metrics Server负责“采数”Dashboard负责“展示”。没有Metrics ServerDashboard照样能跑但监控页面就是一片空白没有DashboardMetrics Server照常采集数据你可以用kubectl top node命令看到同样的指标。从我实际接触过的不少项目来看很多团队的Kubernetes集群用的是云厂商托管的版本默认情况下Metrics Server是不预装的。也就是说你装完Dashboard之后大概率会遇到“有界面、没数据”的状态。这其实是整个Kubernetes监控体系搭建里最常见的一个入口坑。Metrics Server解决的是核心指标CPU和内存的采集问题。它通过metrics.k8s.io这个API对外提供数据kubectl top命令和HPA水平自动扩缩容都靠它。Dashboard则是把这份数据消费掉渲染成图表。搞清楚这层关系之后后面的所有操作才有了明确的目的——我们要做的不是“装一个监控工具”而是“打通一条从kubelet到Dashboard的指标链路”。这条链路的具体走向是这样的每个节点上的kubelet组件内置了一个叫cAdvisor的容器指标采集器Metrics Server定时去每个节点的kubelet请求汇总数据然后聚合后暴露成标准的Kubernetes APIDashboard再通过这个API读数据画图。这个链路听起来不复杂但真正动手部署的时候版本匹配、证书认证、网络策略这些细节一个都不能漏。下面我从部署顺序讲起把每一步的关键点和容易踩的坑都摊开说。2. Metrics Server部署版本选择与启动参数里容易被忽略的细节2.1 版本不是越新越好先看Kubernetes集群的版本号部署Metrics Server的第一步不是急着下载YAML文件而是先确认你集群的Kubernetes版本。这点很关键因为Metrics Server的不同版本对Kubernetes的兼容范围有明确限制。你当然可以直接拉最新版本的组件清单来用但新版本可能会依赖较新的API特性在旧集群上会报各种奇怪的错误。稳妥的做法是去GitHub上Metrics Server仓库的release页面对照表格里标注的Kubernetes版本范围来选。一般来说Kubernetes 1.21以上的集群选最新稳定版问题都不大但如果你的集群还停留在1.18左右的版本那最好选对应时间段的Metrics Server版本。我自己曾经在一个模拟项目X的环境里图省事直接用了最新版Metrics Server去对接一个1.20版本的集群结果Metrics Server的Pod起来了但API一直注册不上日志里反复爆出证书相关的问题。后来换了合适的版本问题迎刃而解。2.2 组件清单的获取方式与参数调整部署Metrics Serverkubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml这个命令会创建一个名为metrics-server的Deployment、一个Service、一个ClusterRole以及对应的ClusterRoleBinding。注意默认的components.yaml里有几个参数在多数生产环境下需要调整最典型的就是--kubelet-insecure-tls。这个参数的含义很直接Metrics Server去访问节点上的kubelet时默认会校验TLS证书但很多自建集群里kubelet的证书签发机构并不是集群CA或者证书里的IP SAN不包含节点IP导致校验失败。加了这个参数之后Metrics Server就不再强制校验kubelet的证书了。不过这里我要多提醒一句生产环境不要无脑加这个参数。如果你的集群所有节点证书都是统一由集群CA签发的完全可以通过正确配置证书来避免跳过校验。但如果是测试环境、临时环境或者你的kubelet证书配置比较混乱那这个参数是你排查问题的第一选择。修改方式如下编辑Deployment的启动参数spec: containers: - name: metrics-server args: - --kubelet-insecure-tls - --kubelet-preferred-address-typesInternalIP--kubelet-preferred-address-typesInternalIP参数也很实用。它告诉Metrics Server优先用节点的内网IP去访问kubelet而不是用主机名。有些网络环境下主机名无法解析不加这个参数就会导致Metrics Server连不上kubelet。2.3 部署后的自检正确姿势是先看API再开Dashboard装完之后不要急着装Dashboard先验证Metrics Server是否真正工作。验证方式就两个命令kubectl get apiservices | grep metrics kubectl top node第一条命令检查metrics.k8s.io这个API服务是否注册成功正常状态应该显示True和Available。如果这行是红色的False那说明Metrics Server的Pod虽然跑着但API注册环节出了问题。最常见的元凶就是证书校验失败按上面的--kubelet-insecure-tls参数调整后一般能解决。第二条命令是实际拉一次数据。如果它能把每个节点的CPU和内存数值打印出来那么Metrics Server这块就已经通了。如果数据出不来不要急着往后走先回头看Metrics Server的Pod日志kubectl logs -n kube-system -l k8s-appmetrics-server日志里通常会有很明确的报错比如“unable to fetch node metrics for node xxx”或者“dial tcp ... connect: connection refused”。前者大概率是TLS问题后者往往是kubelet的监听端口或者网络策略的问题。我第一次搭这套环境的时候就是在kubectl top node这里卡了一个多小时。后来发现是云平台的安全组规则没放行10250端口Metrics Server访问kubelet的超时全都折在这里。所以如果你用的是托管集群或者自建的带防火墙环境别忘了检查节点间的10250端口互通情况。3. 安装Dashboard并接入监控数据从零到能看到曲线3.1 两种安装方式我建议你这么选Dashboard的安装方式主要有两种一种是直接用官方推荐的命令安装另一种是用Helm Chart安装。我更倾向于用Helm方式因为后期升级、改参数都方便而且Helm Chart里的默认配置已经比较合理。用Helm安装Dashboardhelm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard \ --namespace kubernetes-dashboard \ --create-namespace \ --set service.typeNodePort \ --set service.nodePort30001这里把Service类型设为NodePort并指定了访问端口30001。生产环境你完全可以用Ingress把Dashboard暴露出来但为了本地测试和演示方便NodePort是最直接的方式。如果你只想在本地电脑上看效果kubectl proxy也能解决问题。3.2 创建访问账号这一步很多人嫌麻烦就糊弄过去了装好Dashboard之后访问地址会要求你登录。Dashboard支持Token和kubeconfig两种登录方式。如果你用的是云厂商托管集群kubeconfig登录其实挺方便的但你得留意kubeconfig里用户的token是否拥有足够的权限。我更推荐用Token方式登录因为Token的权限范围你自己说了算而且在排查问题的时候思路更清晰。创建一个具备管理员权限的ServiceAccount其实并不复杂apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kubernetes-dashboard --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kubernetes-dashboard保存为dashboard-admin.yaml然后执行kubectl apply -f dashboard-admin.yaml kubectl -n kubernetes-dashboard create token admin-user第二条命令会直接输出一串Bearer Token复制到Dashboard的登录页里就能进去了。这里要提醒一句cluster-admin是全集群最高权限日常使用没问题但如果团队里有多个人共用集群建议按照最小权限原则给每个成员单独建账号。我自己就在测试环境里图省事创建了一个永不过期的管理员Token结果某次排查问题时发现其他人也在用这个Token操作集群安全上心里始终不踏实。3.3 登录后的期望效果哪些数据应该出现哪些数据不该出现登录Dashboard之后正常情况下切换左侧菜单到“节点”页面每个节点卡片上应该显示CPU和内存的使用量和百分比进度条。点进某个节点详情能看到近一小时的CPU和内存趋势曲线。Pod列表页面同样有这样的展示。如果你看到的还是“N/A”或者空值那就说明Metrics Server的数据没有正常透传过来。这时候优先检查Dashboard后端的日志——Dashboard本身不会报错因为它在Dashboard处理中已经把这些指标当作可选信息读取失败就静默显示为空。从实际操作经验来看“Dashboard显示N/A”的问题90%以上出在Metrics Server那一侧而不是Dashboard这一侧。所以排查思路不要先动Dashboard先回到kubectl top node确定Metrics Server是否正常再做下一步。3.4 最后再补一个实用技巧如何临时访问Dashboard如果你不想暴露NodePort也不想创建Service只想快速看一眼Dashboard效果kubectl proxy是最省事的方案kubectl proxy然后浏览器打开http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/这种方式适合本地开发生产环境不推荐。因为kubectl proxy是单用户会话多人协作的时候大家共享同一个代理通道权限边界很难控制。4. 从Dashboard的图表反向理解指标链路数据是怎么流转的很多教程会在你看到曲线图之后就结束了。但我觉得如果你只是停留在“能看图”这一步后面遇到指标缺失、数值对不上等问题时又会一脸懵。搞清楚指标链路的流转逻辑排起错来才有方向感。4.1 一次点击背后的完整数据流你在Dashboard页面上点开某个Pod的CPU监控曲线背后大致经历了这样几个环节Dashboard后端向metrics.k8s.io这个API发请求路径大致长这样/apis/metrics.k8s.io/v1beta1/namespaces/namespace/pods/pod-nameAPI Server收到请求后把请求路由给Metrics ServerAPI服务聚合机制。Metrics Server根据Pod所在的节点向该节点的kubelet发起请求拿取Pod对应的容器指标数据。kubelet内置的cAdvisor从容器运行时读取cgroup里的CPU和内存统计数据整理后返回给Metrics Server。Metrics Server汇总后返回JSON数据。Dashboard拿到JSON数据通过前端的图表库渲染成曲线。每一步都可能是故障点。我遇到过一个很典型的案例某次集群中有个节点的时钟偏移严重导致该节点返回的数据时间戳混乱Dashboard上其他节点都正常唯独那个节点的曲线是断断续续的。当时排查了很久才想到去检查节点时间同步后来发现是ntpd服务挂了。Kubernetes集群里节点间时钟必须同步这点在监控场景下尤其重要因为指标数据都是带时间戳的。4.2 Metrics Server的缓存机制为什么你看到的“当前值”会滞后还有一个大家经常疑问的地方Dashboard上显示的CPU和内存“当前值”其实并不是严格意义的实时值。Metrics Server默认是每15秒从kubelet采集一次数据并且会在自己内存里保留一份缓存。所以你在Dashboard上看到的数值最多可能滞后15到30秒。但这个特性不影响日常监控和排障判断。真正需要注意的是Metrics Server的数据只用于实时观测和HPA扩缩容不应该被当作历史数据存储。你关闭Dashboard页面之后再打开看到的是重新从当前时刻开始的曲线中间的历史数据不会保留。如果你想做长期的性能趋势分析、容量规划、历史回溯需要另外部署类似Prometheus 存储的方案。这个区别就像“看仪表盘”和“装行车记录仪”的区别。Metrics Server Dashboard是前者告诉你车现在的速度和发动机转速Prometheus是后者把全程的数据都录下来供你事后复盘。两者可以共存各自承担的角色不同。4.3 为什么某些Pod显示不了指标但节点显示正常还有一种情况在混部场景同一个节点上跑系统组件和业务Pod下很常见节点的整体CPU使用率能显示但某个具体Pod的CPU一直显示N/A。这种问题通常是Pod启动时间太短的瞬时状态或者Metrics Server还没从kubelet拉到这个Pod的数据。你可以等15到30秒再刷新看一次。如果一直报错那就要蹲点看Metrics Server日志确认是否为权限或网络拦截问题。另外有一种情况值得一提static Pod在有些场景下会显示指标但**镜像PodMirror Pod**本身的指标归属在Dashboard上可能对不上号。因为镜像Pod只是在API Server里为了展示而存在的一个映射真正算资源的是节点上跑的那个实际容器。如果遇到这类问题建议直接看节点维度的数据别在一个Pod的显示问题上卡太久。5. 当监控还是“看不到数”时我总结的一套排查顺序这部分是我自己踩过不少坑后总结出来的排查路径逻辑性比较强你可以直接照着这个顺序走能省下大量时间。5.1 指标链路的五级排查法第一级检查API服务状态kubectl get apiservice v1beta1.metrics.k8s.io -o yaml看这个API服务的Conditions重点看Available是否为True。如果为False大概率是Metrics Server的Pod有问题继续往下看。第二级检查Metrics Server的Pod是否健康和日志kubectl get pods -n kube-system -l k8s-appmetrics-server kubectl logs -n kube-system -l k8s-appmetrics-server --tail50Pod处于CrashLoopBackOff状态的话日志里十有八九是证书校验或者启动参数非法的问题。Pod运行正常但日志不断刷报错最常见的是“unable to fetch node metrics”这就要结合节点与集群的连通性来判断。第三级检查kubelet是否正常工作kubectl get --raw /healthz/kubelet | head这个请求直接打向每个节点的kubelet健康检查接口如果返回的不是OK说明kubelet本身可能不健康。更直接的办法是看节点状态kubectl get nodes如果节点已经显示NotReady那Metrics Server采集不到该节点数据再正常不过。第四级验证API Server到kubelet的网络连通性在Metrics Server的Pod里直接发起请求kubectl exec -it -n kube-system metrics-server-xxx -- wget -O- https://节点IP:10250/metrics/resource --no-check-certificate这一步能很明确地区分是网络不通还是证书不匹配。第五级检查集群的聚合层配置Kubernetes API Server启动时需要配置--enable-aggregator-routingtrue某些自建集群可能没有打开这个开关。如果API服务器没有正确配置聚合层Metrics Server的API服务就会注册失败或者超时。这个排查顺序基本可以覆盖90%以上的“Dashboard没有监控数据”的场景。剩下的10%就是各种版本兼容的特殊情况处理起来费时费力但逻辑也是沿着这条链路去核对。5.2 一个容易误导人的现象Pod是Running状态但数据一直不出来我遇到过几次Metrics Server状态正常、API注册也正常、kubectl top node能输出数据但Dashboard上就是刷不出节点曲线的情况。这个现象的核心是Dashboard的权限和网络配置。Dashboard访问Metrics Server的API时如果Dashboard的ServiceAccount没有相应权限API请求会被拒绝。这个点经常被忽略因为你的登录账号是cluster-admin但Dashboard后端服务用的是自己的ServiceAccount。解决办法很直接给Dashboard的ServiceAccount绑定访问监控数据的角色kubectl create clusterrolebinding kubernetes-dashboard-metrics \ --clusterroleview \ --serviceaccountkubernetes-dashboard:kubernetes-dashboard或者干脆用cluster-admin角色绑上去省心但权限过大看你的接受程度。这里要注意命名空间和ServiceAccount名称要以实际情况为准。6. 结合HPA和真实负载测试让监控数据发挥实际价值6.1 用压力测试验证监控链路是否真的通了光看空跑的Pod曲线其实意义不大真正验证监控链路可靠性的方式是把负载打上去看曲线有没有跟着动。用一条简单的压测命令模拟高CPU负载kubectl run cpu-burner --imagebusybox -- /bin/sh -c while true; do :; done这个Pod会空转CPU然后你到Dashboard的节点页面观察对应节点的CPU曲线正常情况下几秒钟内就能看到曲线明显爬升。如果你说到这一步曲线还是平的那数据链路八成还有问题。说句题外话用yes /dev/null跑一个CPU密集的循环也可以达到类似效果但busybox镜像更轻量适合快速测试。6.2 让HPA动起来监控数据不只是“用来看”的Metrics Server采集的指标除了给Dashboard看图还有一个更重要的用途是驱动HPA。你可以给刚才的cpu-burner部署对象配一个HPAkubectl autoscale deployment cpu-burner --cpu-percent50 --min1 --max5这样当负载上升、CPU使用率超过50%阈值时HPA会自动扩容副本数。你可以通过kubectl get hpa -w实时观察HPA的Targets列看currentCPUUtilizationPercentage是不是在向50%靠近以及副本数有没有变化。这套流程走通之后你对Metrics Server价值的理解会从“给Dashboard提供数据”升级为“给集群的自动伸缩能力提供决策依据”。这才是核心指标在Kubernetes里的真正地位。6.3 一个实战细节HPA和Dashboard看到的数据为什么不同步有时候你会发现HPA已经扩容了但Dashboard上的CPU曲线显示好像还没到阈值。这个不一致的原因主要在于计算口径和刷新频率不同。HPA拿到指标后计算的是一段时间内的平均值而Dashboard展示的是某个时间点的瞬时值。再加上网络延迟、数据缓存等因素两者之间有几十秒的偏差是完全正常的。不要在这个细节上过度纠结。7. 生产环境里Metrics Server和Dashboard的定位与局限7.1 什么时候这套组合够用什么时候不够如果团队的业务对资源监控的需求仅限于“看一眼集群是否健康”以及“Pod挂了能及时扩容”那Metrics Server Dashboard这套组合完全够用。它部署简单、维护成本低、没有额外的存储和告警组件的负担。但如果你的需求还包括查看历史趋势、做容量规划、配置复杂告警规则、多集群统一监控那这套组合就会显得力不从心。这时候你应该考虑引入专门的监控体系。Metrics Server的数据是存在内存里的进程一重启历史数据全部清零。它本质上就不是为长期存储设计的。7.2 两套监控共存时的端口和资源注意点当你在集群里同时装了Metrics Server和Prometheus全家桶时要注意两者都在采集节点的核心指标但因为Metrics Server走的是Kubernetes API聚合层而Prometheus抓取的是kubelet的/metrics接口两者互不冲突可以并行工作。唯一需要注意的是节点上kubelet的资源占用会有所上升在节点规格偏小的环境下用free -h多观察一下就好。7.3 Dashboard的权限管控别让“能看到”变成“能改”Dashboard本身是个超管利器但也正因为权限太大它经常成为安全事故的重灾区。建议从两个层面约束一是生产环境不要用NodePort暴露Dashboard尽量走Ingress并配好认证二是Dashboard的ServiceAccount尽量单集群独立别为了省事把所有环境的Dashboard共用一套权限。我见过一些团队把所有环境测试、预发、生产都共用一套Dashboard账号哪怕只是图管理方便也等于把生产集群的安全边界撕开了一个口子。在这个问题上宁可初期麻烦一点也不要把权限敞着用。8. 我踩过几次坑后的经验总结整套部署和排查流程走完我最想分享的经验就这几点。第一先确认Metrics Server通了再动Dashboard。这个顺序一旦反了你会在大屏界面上折腾半天却毫无进展。第二遇到问题先看日志别猜原因。Metrics Server的日志信息其实非常清晰直接指向问题所在。哪怕只是“Unable to connect to x.x.x.x:10250”这样的报错也足以告诉你方向。第三不要试图让这套轻量方案承载超出它能力范围的职责。如果团队已经开始讨论“历史趋势回溯”“异常告警通知”这些话题那就可以认真评估专门监控体系了别在Dashboard上做无谓的期待。第四测试环境建议模拟一次节点故障。主动把某个节点上的kubelet停掉观察Metrics Server的反应和Dashboard的显示这会让你对这套监控体系的实际容错能力有一个直观的判断。我在几次实际部署中还有一个小习惯就是每次部署完成后把kubectl get apiservice和kubectl top node的结果固定保留一份快照。后面如果有人反馈“监控没了”对着快照一对比问题出在新接入的节点还是组件配置也就一目了然了。这套监控方案是整个Kubernetes运维体系里最基础、最轻量的一环值得你花半小时把它彻底搞清楚。