★ FEATURED ARTICLE 集群跑起来之后第一件事不是欢天喜地部署业务而是把Kubernetes监控补齐。在我这几年实操过的环境里最顺手、最省心的一套基础监控组合就是Metrics Server搭配Dashboard一个负责把节点和Pod的CPU、内存数据及时采上来一个负责把数据画成你看得懂的图和表。这套组合专治集群黑盒的焦虑适合刚搭好集群的运维、想查看资源水位的研发以及还没上Prometheus的中小规模集群作初期可视化。很多人一提到K8s监控就想着上全家桶其实不用。对于大多数日常需求你要的只是三样节点有没有被打爆、Pod还够不够内存、应用对应的副本资源是否正常。Metrics Server加Dashboard恰好覆盖了这些而且部署成本低遇到问题也容易定位。这篇文章我会把核心原理、完整部署步骤、以及我在实际环境里踩过的坑全部理清楚照着做就能搭出一套可用的基础监控入口。1. 项目背景为什么我把这套组合当作集群监控的底线1.1 监控这件事先别急着上全家桶每个K8s集群在初始化之后免不了要经历一段眼前一黑的阶段。你没有可视化入口排障只能靠kubectl get pods加kubectl logs集群节点状态全凭命令行返回的一串英文效率低心里更没底。监控体系通常可以分为几层可用性监控、资源用量监控、性能指标监控、日志与链路追踪。对于绝大多数刚起步的团队最紧急、最高频的是资源用量这一层——节点CPU有没有跑满、内存是不是快炸了、某个工作负载有没有在偷偷膨胀。这些数据其实K8s自身就能采集只是默认没有对外提供易用的展示界面也没有现成的聚合API把数据组织好。这里就必须分清两类工具。第一类是以Prometheus为核心的完整监控系统能拉取大量指标、保留历史数据、做告警规则能力很全面但部署成本也高组件多、存储要规划、告警规则要写。第二类是今天的主角Metrics Server它不做告警、不存历史、指标种类也很有限但它轻、准、原生专门提供节点和Pod的实时资源数据。排障的时候看一眼Metrics Server给出来的数据基本能判断出资源层有没有问题。我的实际建议是先上Metrics Server加Dashboard让虚拟机层面的资源水位透明化等业务稳定了再补Prometheus做历史趋势和告警。这个顺序能让你在最短时间内获得可视化能力不会因为一开始就折腾整套监控而失去耐心。1.2 Metrics Server与Dashboard的分工这套组合里两个角色的边界非常清晰。Metrics Server本质上是K8s的一个聚合API服务。它运行在集群内部定期从每个节点的kubelet那里获取资源摘要然后通过metrics.k8s.io/v1beta1这个API提供给上层使用。你可能觉得它只是个小工具但系统里不少地方都依赖它比如kubectl top node、kubectl top pods以及HPA自动扩缩容时作决策依据都是走Metrics Server这条链路。没有它你连看看现在哪个Pod最吃内存这种基本操作都做不了。Dashboard则是K8s官方推出的Web界面解决的是怎么看的问题。它把集群里的节点、工作负载、服务、配置等资源全部可视化在界面上点一点就能看资源清单、日志、事件。Dashboard本身只是一个控制台它本身并不采集数据而是通过访问Kubernetes API来获取信息其中就包括通过Metrics Server提供的指标接口。所以一个负责采集和提供数据一个负责展示和交互两者拼在一起才是完整闭环。如果只装Dashboard不装Metrics Server你会发现节点列表能看但资源图表全空如果只装Metrics Server不装Dashboard数据是有了但只能通过命令行看不够直观。打个比方Metrics Server是体温计Dashboard是仪表盘。体温计负责把温度量出来仪表盘负责把温度指针画到表盘上。没有体温计仪表盘上的指针永远指向零没有仪表盘你手里只有一根温度计读数也要凑近看。2. 核心原理数据从哪里来又怎么走到浏览器2.1 Metrics Server的工作机制很多人在部署Metrics Server之后会遇到各种莫名其妙的异常想排查但不知道从哪下手原因就是没吃透它的数据链路。Metrics Server以Deployment形式运行在kube-system命名空间下通常只有一个副本Pod会包含几个容器。它启动时会向Kubernetes API Server注册一个APIService路径是metrics.k8s.io/v1beta1这样API Server就能把对/apis/metrics.k8s.io的请求转发给Metrics Server处理。实际采集过程是这样的集群里的每个节点都有kubeletkubelet内置了cAdvisor组件负责采集节点和容器的CPU、内存、网络、磁盘等基础指标并且在每个节点的10250端口上暴露一个Summary API返回聚合后的资源摘要。Metrics Server做的就是定期轮询每个节点的这个接口把数据汇总之后以列表或单个对象的形式暴露出去。这里有个很容易被忽略的点Metrics Server默认每60秒抓取一次数据也就是说kubectl top看到的数值不是实时的会有最多一分钟的延迟。对于急促排障来说这个延迟可以接受但对于需要秒级响应的场景就不够了这也是它和Prometheus之间的核心差异之一。另外需要注意Metrics Server的设计原则是轻量它不存储历史数据只保留最近一次抓取的结果。你重启Metrics Server之后Dashboard里的历史曲线依然会从0开始画这是因为数据源只有当前值没有历史序列。明白了这一点就不会在遇到重启后曲线消失时以为出了故障。2.2 Dashboard如何消费指标Dashboard后端是以Deployment形式运行在kubernetes-dashboard命名空间里的前端是浏览器加载的单页应用后端则是真正与Kubernetes API交互的代理服务。当你在页面上打开某个节点或某个Pod详情时后端会向API Server发起相应请求其中资源用量部分的请求会被转发到Metrics Server。这个架构决定了两个常见现象。第一Dashboard的功能依赖API Server的资源接口如果RBAC权限不足页面上很多按钮会直接返回Forbidden而不是显示为空。第二Dashboard的指标图表依赖metrics.k8s.io这个API如果Metrics Server没装好API请求会报错图表区域要么空白要么显示No data。在登录方式上Dashboard支持Token登录。Token本质上是某个ServiceAccount的凭据Kubernetes通过RBAC机制决定这个凭据能看什么、能改什么。默认部署时的kubernetes-dashboard这个ServiceAccount只有基础权限能看的东西很有限所以实际使用中通常需要自己创建一个管理员ServiceAccount绑定cluster-admin角色再用这个账号的Token登录。这里多说一句生产环境里绑定cluster-admin确实是权限过大的操作但如果只是测试环境或者小型内部集群这是最省事的做法。我在多个环境里都是先用管理员身份把所有功能验一遍确认各环节没问题后再去细化权限。2.3 为什么这两个组件缺一个都不行很多新手第一次装Dashboard发现页面打不开或者打开了没有数据第一反应是Dashboard部署出问题了折腾半天才意识到Metrics Server还没装。为了彻底避免这种无效排查建议一开始就按采集端→展示端的顺序部署并且每一步都做验证。检查项没有Metrics Server没有Dashboardkubectl top node报错无法获取指标正常但看不懂Dashboard节点图表报错或No data无法访问HPA自动扩缩容无法工作不受影响资源排查体验命令行硬啃界面空荡荡部署成本一个Deployment一个Deployment加RBAC从表里能看出Metrics Server是整个资源监控的基座它一旦缺失HPA都会受影响而Dashboard只是展示层缺了不影响系统运行但会严重影响排障体验。我在实际中见过一种情况某部署人员已经提前装了Metrics Server但是APIService状态显示不可用kubectl top完全跑不动。这种情况下人会觉得是命令有问题其实根本不是是聚合层没有把请求正确转发到Metrics Server后端最常见的元凶是TLS证书校验失败或Pod没起来。遇到这种问题别急着重装先去查APIService状态和Pod日志。3. 完整实操从部署到第一张资源曲线3.1 部署前置检查安装之前先确认集群版本。Metrics Server对Kubernetes版本是有要求的太老的版本接口不兼容建议至少使用v1.19以上的集群如果是v1.21以后就非常稳妥。接着确认聚合层是否正常。所有需要扩展API的组件包括Metrics Server和以后可能用的自定义资源都要依赖API Server的aggregation layer。你可以直接执行下面的命令看一眼当前系统里已经注册了哪些APIServicekubectl get apiservice正常情况下会看到很多v1.开头的APIService如果列表里没有metrics.k8s.io相关条目先别急着执行安装命令因为安装完成后聚合层还要一段时间才能完成注册。顺便确认一下集群里有没有已经存在的同名组件避免重复部署导致端口冲突kubectl get pods -n kube-system | grep metrics如果之前装过旧版Metrics Server最好先清理干净再装新的不然后面排障会分不清到底是配置问题还是版本冲突。这一步花不了两分钟却能避免后续所有问题都变成薛定谔的故障。3.2 安装Metrics Server并验证Metrics Server官方提供了现成的部署清单常用的做法是直接从官方仓库拉取components.yaml。如果你所在环境的镜像拉取有困难需要自行修改镜像地址这个后面说。kubectl apply -f components.yaml部署完成后先看Pod状态kubectl get pods -n kube-system | grep metrics-server正常情况下应该是Running状态如果CrashLoopBackOff或者ImagePullBackOff基本就是镜像没拉下来或者启动参数出错。这里分享一个我反复踩过的坑默认components.yaml在大多数自建集群上会运行失败典型的报错是x509: cannot validate certificate for x.x.x.x because it doesnt contain any IP SANs原因是kubelet默认使用自签证书Metrics Server在通过HTTPS访问kubelet时无法校验证书。解决办法是调整Metrics Server的启动参数最直接的是加--kubelet-insecure-tls跳过证书校验。在components.yaml里找到Deployment的containers.args位置加上这一行- --kubelet-insecure-tls还有几个参数我建议一次配齐避免后续反复修改- --kubelet-insecure-tls - --kubelet-preferred-address-typesInternalIP - --metric-resolution30s第一个解决证书问题第二个让Metrics Server优先使用节点内网IP去访问kubelet第三个把采集周期从默认60秒缩短到30秒让Dashboard上的曲线更平滑一些。改完配置重新apply一次观察Pod起来后再验证APIService状态kubectl get apiservice v1beta1.metrics.k8s.io看到AVAILABLE列为True才说明聚合链路正常。接下来就是最有成就感的时刻执行kubectl top node kubectl top pods -A如果能看到节点CPU和内存的数值说明采集链路已经全部打通。新集群刚部署完可能会提示metrics not available yet这不是故障只是首轮数据还没采集完成等一两分钟再执行就好。3.3 安装Dashboard并创建登录TokenDashboard的部署相对简单官方仓库提供了完整的YAML清单直接应用即可kubectl apply -f recommended.yaml部署完成后会新建一个kubernetes-dashboard命名空间里面有Deployment、Service和几个关联的RBAC资源。检查一下Pod状态kubectl get pods -n kubernetes-dashboardPod处于Running状态后Service也会正常创建。默认dashboard Service的类型是ClusterIP外部还不能直接访问这一步后面配置。接下来创建管理员账号。首先创建一个ServiceAccountkubectl create serviceaccount admin-user -n kubernetes-dashboard然后把集群管理员角色绑定给它kubectl create clusterrolebinding admin-user-binding --clusterrolecluster-admin --serviceaccountkubernetes-dashboard:admin-user为什么要额外创建这个账号而不是直接用默认的kubernetes-dashboard因为默认账号权限很低很多页面点进去会报Forbidden排查起来很浪费时间。这个管理员账号绑定的是集群最高权限配合一次性Token登录适合测试和初期管理。新版Kubernetes获取Token的命令很简洁kubectl -n kubernetes-dashboard create token admin-user执行后会直接打印一长串Token复制保存好。如果你的集群版本比较老可能需要用secret方式来获取kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa admin-user -o jsonpath{.secrets[0].name}) -o jsonpath{.data.token} | base64 -d两种方式拿到的是同一个Token用起来没有区别。需要提醒的是create token生成的Token有过期时间适用于临时登录要想长期稳定保存一套Token用secret方式获取更合适那个不会自动过期。3.4 配置访问方式并登录Dashboard默认是HTTPS服务端口443。访问方式有多种日常测试最推荐用kubectl的端口转发不需要改Service类型也不会暴露到公网kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard 18443:443执行后保持终端不关闭浏览器访问https://localhost:18443浏览器大概率会提示证书不受信任这个正常Dashboard用的是自签证书点击继续访问就行。如果是国内某浏览器自动拦截不让你点过去换用常规的现代浏览器大多没问题。如果你希望其他机器也能访问可以把Service改成NodePort类型kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard将type: ClusterIP改为type: NodePort保存后查看对外分配的端口kubectl get svc -n kubernetes-dashboard然后在浏览器里访问https://节点IP:NodePort。注意这里的节点IP是集群里任意一个节点的地址不一定是控制平面节点。为了安全生产环境不建议直接把Dashboard暴露到外网后续我会单独说这个问题。登录页面选择Token方式粘贴前面保存的Token点击登录就能进去了。进入后默认是集群概览页可以看节点数量、资源使用概览。点击左侧节点菜单进入节点列表再点进任一节点就能看到CPU和内存的实时曲线这部分数据正是来自Metrics Server。再点开工作负载里的Pod能看到每个容器的实时资源占用还可以直接查看日志、进入容器执行shell。到这里整套Kubernetes监控的基础可视化就具备了。3.5 权限配置的一些建议上面给admin-user绑定的是cluster-admin这是为了演示方便。如果这套环境要给多个开发同学共用建议收敛权限至少不要每个人都拿管理员Token。一个常见的做法是创建一个只读角色绑定给普通用户账号kubectl create clusterrole view-user --verbget,list,watch --resource* kubectl create clusterrolebinding view-user-binding --clusterroleview-user --serviceaccountkubernetes-dashboard:view-user不过要注意view-user这种粗粒度角色虽然能看但连Secret的明文内容也看不了一些排障需求可能不够用。更灵活的做法是给不同命名空间创建RoleBinding只允许查看指定命名空间的资源。权限设计没有标准答案完全取决于团队规模和协作方式但有一条原则不会变默认最小权限缺了再加。4. 常见问题与排查实录4.1 高频错误速查表以下这些问题是部署和使用过程中出现频率最高的我把现象、原因和处理办法整理成了表格方便实际操作时快速对照。现象根本原因处理方式kubectl top报错no metrics knownMetrics Server没装好或首轮采集未完成等1-2分钟检查Pod状态和日志Pod一直CrashLoopBackOff启动参数冲突或改动出错clear 掉旧版本重新apply新配置x509证书校验失败kubelet自签证书无法校验加--kubelet-insecure-tls参数Dashboard打不开链接超时Service类型或网络策略问题检查Service类型、NodePort、网络策略登录后很多资源点不开权限不足创建并绑定cluster-admin或更细分角色Token报错无效Token生成方式不对或已过期重新生成Token确认粘贴完整无换行图表区域一直No dataMetrics Server异常或APIService未Ready检查kubectl get apiservice状态这张表覆盖了我接触过的绝大多数现场问题。最典型的组合拳是先看Metrics Server Pod有没有起来再看APIService是否Report最后再看Dashboard后端日志基本能定位90%的问题。4.2 图表一直显示0或没有数据的排查Dashboard上节点信息正常、列表能出来但进入详情页以后图表区域全是零或者提示没有数据这种情况通常不是Dashboard的问题而是Metrics Server的数据没有被正确消费。第一步确认Metrics API本身是通的kubectl get --raw /apis/metrics.k8s.io/v1beta1 | head如果返回的是错误信息说明Metrics Server链路上有问题如果正常返回JSON数据说明指标接口没问题问题可能出在Dashboard后端的连接或浏览器缓存。第二步查看Metrics Server日志kubectl logs -n kube-system -l k8s-appmetrics-server日志里如果大量出现dial tcp ... context deadline exceeded说明Metrics Server访问kubelet超时常见原因是节点防火墙加固后放行了6443端口却忘了10250端口。Kubelet的10250端口需要放开给Metrics Server访问尤其要注意很多安全基线脚本会主动收紧这个端口。第三步检查Dashboard的日志。Dashboard后端Pod如果持续出现404或403说明它请求Metrics API时没有正常拿到数据。这种时候重启一下Dashboard的Deployment通常有帮助因为它会重新建立与API Server的连接kubectl -n kubernetes-dashboard rollout restart deployment kubernetes-dashboard还有一个很隐蔽的问题Dashboard页面打开后长时间不刷新Metrics Server重启过页面上显示的曲线可能就断了。关闭页面重新打开即可不用过度分析。4.3 多环境监控的实践建议如果这套组合用得顺手你可能也会像我一样在多个集群里重复部署。几个经验值得记一下。镜像地址的坑。不同网络环境下默认的镜像地址可能拉不下来。遇到ImagePullBackOff时把镜像地址换成能访问的仓库即可版本号建议锁定不要用latest。我习惯在部署文档里记录当前部署的版本号这样克隆新环境时能保证组件版本完全一致排查跨集群问题时也少一个变数。跨集群部署时把components.yaml和recommended.yaml保存到自己的Git仓库里并在YAML里把自定义参数写明。特别是--kubelet-insecure-tls这种带安全隐患的配置必须在注释里写清楚为什么加、什么时候可以去掉。不然半年后回头看根本想不起来这些参数是干嘛的。还有一点关于资源限制。Metrics Server和Dashboard本身资源占用很小但建议不要直接部署在抢占式节点上。有一次我的Metrics Server所在节点被回收整个集群的kubectl top直接不可用HPA也停了排查了半小时才发现是节点没了。如果有条件给这两个Deployment加上priorityClassName让它们在节点抖动时优先保留。最后聊聊这套组合的边界。Metrics Server不存历史数据Dashboard也没有告警能力所以它承担的是当前状态查看不是历史回溯和主动发现问题。当集群规模大了、业务多了还是要引入Prometheus生态来做长期存储和告警。但在这之前一个轻量、不喧宾夺主的Dashboard监控方案已经能帮你在绝大多数时刻快速看清集群水位。我个人在实际操作中的体会是这套组合最大的价值不在于功能多强而在于它让你愿意随时打开浏览器看一眼集群状态。一天里打开几次Dashboard比自己写一堆脚本定时去抓kubectl top的输出要直观得多也更容易发现异常苗头。如果你刚搭好集群还不知道从哪里开始做监控不妨就先从这套组合入手把资源水位看清楚了后面再决定要不要上更重的监控全家桶。
阅读完成 · 觉得有帮助？
