搞Kubernetes运维的朋友应该都有这种经历集群跑起来了Pod也在转但是你想看看每个节点还剩多少内存、某个应用最近半小时CPU是不是飙了却发现无从下手。直接kubectl top node敲下去报错说metrics API不可用因为没有部署采集组件。这时候最经典也最实用的一套组合拳就是Kubernetes监控里最常见的搭配Metrics Server负责采集节点和Pod的CPU、内存数据Dashboard负责把数据变成可视化的界面。今天这篇就把这套监控组合从部署到排查完整走一遍讲清楚每一步的原理、选择和避坑点。这套方案适合谁适合刚把集群跑起来、需要基础资源监控看板的运维和开发也适合准备自己搭一套轻量监控体系、但暂时不想上Prometheus那套重型方案的人。它能解决的核心问题很直接在Dashboard里直接看节点和Pod的历史与实时资源占用曲线执行kubectl top不再报错HPA也能正常拿到指标。1. 基础认知为什么是Metrics Server加Dashboard1.1 先搞清楚Kubernetes监控体系的分层Kubernetes监控不是一个单一的东西而是分了好几层。从下往上大致是物理资源层节点CPU、内存、磁盘、系统组件层kubelet、API Server、调度器自己的状态、应用层容器内的业务指标比如请求量、延迟和事件层Pod调度失败、驱逐等。我们平时聊的先搭个监控看看绝大多数场景指的都是第一层也就是资源指标。这批数据的来源是每台节点上的kubelet它内置了一个叫cAdvisor的组件负责采集容器和节点的CPU、内存、网络、磁盘等原始数据。难点在于kubelet把数据采上来之后是通过一个本地接口暴露的你不可能每次都跑到每台机器上去看。所以需要一个集群层面的组件把这些数据汇总并且按照标准的Kubernetes API方式暴露出来。这就是Metrics Server的核心价值。它把kubelet采集到的数据聚合然后注册成metrics.k8s.io这个API之后你用kubectl top也好Dashboard也好HPA也好都从这个API拿数据。1.2 为什么第一套监控推荐这两个而不是直接上Prometheus很多人会觉得既然要做监控为什么不一步到位直接上Prometheus加Grafana我的看法是分阶段。Prometheus体系功能强大但学习曲线和组件数量都不是零成本的你需要部署Prometheus自身、node-exporter、kube-state-metrics还要学PromQL写查询这对刚接触Kubernetes监控的人来说是个不小的台阶。Metrics Server配合Dashboard这套组合的优势在于轻量、官方维护、零查询语言负担。Metrics Server本身就是Kubernetes官方的插件部署起来就是一组镜像加几个YAML。Dashboard同样是官方项目提供了Web界面点几下就能看到集群资源水位。它不追求深度分析但能把节点是不是快满了哪个Pod在持续占内存这类最要命的问题用曲线直观呈现出来。等这套基础监控跑明白了再上Prometheus做更细粒度的告警和历史数据持久化是更平滑的路径。1.3 这套组合的数据通路到底是怎么走的先说清一条完整的数据链路后面排查问题全靠它。Pod在节点上跑节点上的kubelet通过cAdvisor采集容器CPU和内存的使用数据。Metrics Server通过kubelet的10250端口的只读接口把每个Pod的指标样本抓取下来聚合后缓存在自己的内存里并且通过Kubernetes的聚合API层注册成metrics.k8s.io。Dashboard在展示资源图表时向后端API Server发起查询API Server把请求代理给Metrics ServerMetrics Server返回内存里的缓存数据Dashboard再绘制成曲线图。这条链路里有三个关键点值得圈出来Metrics Server本身不落库数据是内存中的临时快照所以你看不到很久以前的历史数据默认只保留最近几分钟的窗口。metrics.k8s.io这个API是聚合API由APIService对象注册检查这个对象的健康状态是排查kubectl top没数据的第一步。Dashboard查询的是实时指标它本身不直接和kubelet通信所有数据都经过API Server代理所以权限模型走的是RBAC那一套Dashboard需要配置ServiceAccount和对应的ClusterRole。理解这条链路之后你就会发现很多所谓奇怪的问题其实一点都不奇怪只是链路里某个环节没就位。2. 部署前准备版本适配与工具选型2.1 版本适配是第一个隐形坑我见过太多人部署失败第一反应是网络问题或者YAML写错了其实往往是被版本适配坑的。Metrics Server和Kubernetes主版本之间是有对应关系的不匹配的时候会出现证书校验失败、API无法注册这类莫名其妙的问题。以当前主流版本为例Kubernetes 1.19到1.25对应Metrics Server v0.6.x镜像是registry.k8s.io/metrics-server/metrics-server:v0.6.4。Kubernetes 1.26及以上推荐Metrics Server v0.7.x或者更新的v1.x版本因为kubelet的TLS证书行为有变化旧版本会握手失败。还需要留意容器运行时。如果节点用的containerd而不用DockerMetrics Server本身没影响但Dashboard的镜像拉取策略和网络设置有时会有小坑这个后面会单独说。判断版本匹配的一个笨但有效的办法去Metrics Server官方GitHub的README里找到Compatibility表格对着看。不要凭感觉选最新版本最新版本不一定兼容你的集群。2.2 我用的环境与工具清单我这次演示的标准环境是某公司内部测试集群用kubeadm方式安装的Kubernetes v1.28版节点上容器运行时为containerd网络插件用的是Calico。这样的环境应该能覆盖大部分生产或测试场景的共性。需要用到的工具有kubectl本地操作集群的客户端版本最好和集群小版本差异不超过一个版本。helm虽然这篇主要以纯YAML部署为主但我会提到用helm做Dashboard部署的替代方式官方chart维护起来会方便一些。浏览器加一个SSH端口转发工具因为Dashboard大多数时候不会暴露成LoadBalancer服务而是通过kubectl port-forward访问。强调一下虽然我用的是RHEL类的Linux发行版做跳板机但kubectl port-forward的用法在所有平台上都一样。2.3 为什么建议用官方YAML而不是自己写Metrics Server和Dashboard官方都提供了标准的部署YAML分别是components.yaml和recommended.yaml。直接用的理由有三个第一这两份文件里的镜像地址、权限绑定、启动参数都是经过大量生产环境验证的自己拍脑袋写的配置很容易漏掉必需的参数比如--kubelet-preferred-address-typesInternalIP这类细节。第二官方文件里有配套的RBAC对象ServiceAccount、ClusterRole、ClusterRoleBinding都是齐的少一个Dashboard就登录不进去。第三升级的时候直接替换文件就能平滑跟进不用手工比对差异。当然直接用不意味着闭眼用。内网环境拉不了外部镜像的情况很常见你需要提前把镜像docker pull或者ctr pull下来打上tag推到自己的私有仓库然后修改YAML里的image字段。这是标准的离线部署操作后面排查章节会再提到和镜像拉取相关的坑。2.4 端口和网络层面的预期Metrics Server跑起来后默认监听443端口它需要访问每个节点的kubelet 10250端口。这一步在使用网络安全策略NetworkPolicy的集群里尤其要留意如果那个命名空间默认禁止进站流量Metrics Server到节点的抓取会失败表现就是Pod起来了但所有指标都拉不到甚至API注册不成功。Dashboard主容器默认监听8443端口通过kubectl port-forward直接转发到本地的某个端口访问。如果集群里的Ingress已经配置好也可以选择用Ingress暴露但需要额外处理TLS证书和Dashboard自身的认证方式我建议你在第一次部署时就用端口转发简单直接。3. Metrics Server部署与深度解析3.1 部署Metrics Server的标准步骤部署的第一步是拉取官方清单文件。wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml然后直接应用kubectl apply -f components.yaml等一两分钟检查Pod状态kubectl get pods -n kube-system -l app.kubernetes.io/namemetrics-server正常情况下应该看到类似这样的输出NAME READY STATUS RESTARTS AGE metrics-server-7d5b6d9c9b-x4k2m 1/1 Running 0 96s接着验证API是否注册成功kubectl get apiservice v1beta1.metrics.k8s.io输出中的AVAILABLE列应该是True。这一步是我在所有集群上的必查项因为Pod处于Running状态并不能说明API一定可用。再验证数据采集是否正常kubectl top node kubectl top pod -A如果你看到类似error: metrics not available yet的提示先别慌多数情况下只是因为Metrics Server才启动第一轮采集还没完成。等一分钟再敲一次。如果反复都是这个错误就需要按第五章的排查思路去查了。3.2 核心原理聚合API与参数选择Metrics Server能让你用kubectl top这种原生命令查指标是因为Kubernetes提供了一套聚合API机制。简单说你可以自己写一个后端服务提供一组特定格式的API然后通过创建APIService对象告诉API Server这个路径的请求代理给那个服务处理。Metrics Server正是这么做的它把自己注册成了metrics.k8s.io这个API组。在components.yaml里你可能会注意到Metrics Server Deployment里有一堆启动参数这些参数是部署后能不能成功采数据的关键。拿最常见的几个来说--kubelet-preferred-address-typesInternalIP告诉Metrics Server优先使用节点的内网IP去访问kubelet而不是主机名。如果你的集群DNS解析有问题不加这个参数会解析到错误地址导致抓取失败。--cert-dir/tmpMetrics Server自己也需要TLS证书默认会挂载一个临时目录存放自签证书。如果你看到日志里报找不到证书多半是CERT_DIR没有指向Deployment里指定的volume路径。--kubelet-use-node-status-port新版本默认行为是使用节点状态里上报的端口适用面更广。另一个需要理解的点是cAdvisor数据源。Metrics Server本身不采集数据它是向每个节点上的kubelet发请求kubelet再从cAdvisor拿数据返回。所以如果你单独启用了某种运行时隔离策略或者kubelet配置了自定义的cgroup驱动Metrics Server得到的数值可能会和你在宿主机上用free看到的有偏差这在容器化资源统计里是正常的不用纠结。3.3 镜像拉取问题的常见解法国内网络环境拉registry.k8s.io的镜像经常失败这是部署Metrics Server时最普遍的障碍。解决方案很直接用镜像代理或者先拉到本地再推私有仓库。以containerd运行时为例可以这样操作ctr -n k8s.io images pull registry.k8s.io/metrics-server/metrics-server:v0.6.4如果这个地址也超时可以用一些公共镜像仓库的代理地址先拉取然后重新打tagctr -n k8s.io images pull docker.io/mirrorgooglecontainers/metrics-server:v0.6.4 ctr -n k8s.io images tag docker.io/mirrorgooglecontainers/metrics-server:v0.6.4 registry.k8s.io/metrics-server/metrics-server:v0.6.4然后修改components.yaml里的image字段指向你自己的私有仓库地址再apply即可。需要注意改镜像地址的同时imagePullPolicy最好设置成IfNotPresent避免节点在镜像已经存在的情况下还要去远程仓库校验。3.4 高可用与多副本部署生产环境如果只有单副本Metrics Server一旦Pod被重新调度监控会短暂中断。用Deployment默认的replicas: 1在测试环境没问题但如果有条件建议调整为两个副本spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1配两个副本之后还需要在spec.template.spec里加上调度分散的配置比如podAntiAffinity让两个Pod尽量不落在同一节点上。另外多副本模式有个细节Metrics Server的启动参数里不要加--metric-resolution这种会导致数据不一致的参数保持默认即可因为每个副本都是独立从kubelet抓取数据是同一份快照副本之间不需要同步。3.5 安全加固限制Metrics Server的访问范围Metrics Server作为集群内的一个高权限组件它默认可以获取所有命名空间的资源指标。如果集群安全要求严可以通过RBAC对它做约束。components.yaml里有个ClusterRole叫system:metrics-server它的规则列表指定了可以读取nodes/metrics、pods等资源。尽量不要去扩大它的权限范围如果业务上有隔离需求可以考虑用--metric-resolution和--kubelet-only组合限制它只从kubelet拿数据不让它直接访问Pod的Exec接口之类的。另外Metrics Server的ServiceAccount在kube-system命名空间平时很少被单独审计建议在部署后第一时间给这个ServiceAccount打上标签方便后续结合策略引擎做异常检测。4. Dashboard部署与登录配置4.1 部署Dashboard主体Metrics Server是数据采集层Dashboard是展示层两者配合起来才能看到曲线。Dashboard官方提供的部署文件叫recommended.yaml里面包含了所有必要资源对象。kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml这个清单会创建kubernetes-dashboard命名空间部署Deployment、Service、ServiceAccount还有一系列RBAC规则。默认情况下Dashboard的Service类型是ClusterIP端口443这意味着只有集群内部可以访问。这也是我们接下来需要用端口转发访问的原因。查看Dashboard Pod状态kubectl get pods -n kubernetes-dashboard因为Dashboard镜像比较大加上有时候解析慢Pod在ContainerCreating阶段多停一会儿是正常的。遇到ImagePullBackOff就按镜像拉取问题处理思路和前面Metrics Server一样。4.2 Dashboard的认证方式Token登录Dashboard默认不支持账号密码登录可以用两种方式认证一种是Kubeconfig一种是Token。实际运维里Token方式最常用因为它只依赖Kubernetes自身的ServiceAccount机制不需要额外配置。创建一个专门给Dashboard用的管理员ServiceAccountapiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kubernetes-dashboard再创建一个ClusterRoleBinding把它绑到集群管理员角色上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然后取得这个ServiceAccount的Token。新版本Kubernetes里ServiceAccount会自动创建对应的Secret名称一般是admin-user-token-xxxxx。获取令牌的命令是kubectl -n kubernetes-dashboard create token admin-user这条命令会生成一个有时效的Token默认有效期为1小时适合临时登录。如果你希望Token长期有效传统做法是直接读取Secret里的token字段kubectl get secret -n kubernetes-dashboard $(kubectl get secret -n kubernetes-dashboard -lapp.kubernetes.io/componentkubernetes-dashboard -o jsonpath{.items[0].metadata.name}) -o jsonpath{.data.token} | base64 -d不过提醒一句长期Token增加了泄露风险。如果是临时演示或排查用create token就好如果需要长期用建议通过外部密钥管理系统来签发和轮换而不是把Token硬编码到脚本里。4.3 访问Dashboard端口转发与Ingress选型登录和访问是很多人第一次卡住的地方。端口转发的方式很简单在一台能连通Kubernetes API Server的机器上执行kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard 8080:443然后本地浏览器访问https://localhost:8080浏览器会提示证书不受信任这是正常的因为Dashboard用的是自签证书选择继续访问即可。需要注意端口转发只适合临时使用或者你本机直连的情况。如果集群有多个节点其他同事也要访问Dashboard每次都让人家自己转发就很麻烦。这时候可以配置Ingress。Dashboard的Service是HTTPS的所以Ingress需要配置TLS后端协议也要设为HTTPS。具体的注解取决于你用的Ingress Controller以常见的Nginx Ingress为例apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: dashboard namespace: kubernetes-dashboard annotations: nginx.ingress.kubernetes.io/backend-protocol: HTTPS nginx.ingress.kubernetes.io/ssl-passthrough: true spec: ingressClassName: nginx tls: - hosts: - dashboard.example.com secretName: kubernetes-dashboard-tls rules: - host: dashboard.example.com http: paths: - path: / pathType: Prefix backend: service: name: kubernetes-dashboard port: number: 443这里用了ssl-passthrough因为Dashboard是自签HTTPS证书如果Ingress再终止TLS会多一层证书问题。生产环境建议把Dashboard置于内部域名下不要暴露到公网毕竟Dashboard有集群管理权限暴露公网等于把钥匙挂在门上。4.4 登录后的界面布局与核心功能用Token登录后你会进入Dashboard主界面。左侧导航有几个核心区域先说最常用的。集群概览顶部直接展示节点数、命名空间数、内存请求总量等摘要数字下方是按节点排列的资源使用量条形图。节点列表点开某个节点可以看到该节点上所有Pod的列表以及每个Pod的实时CPU、内存占用还有节点的压力状态。工作负载按Deployment、StatefulSet、DaemonSet等分类查看点进去能看到每个工作负载的Pod列表、重启次数、调度事件以及日志入口。服务和Ingress查看服务暴露方式调试端口映射很方便。垂直Pod自动扩缩容和水平Pod自动扩缩容如果你配置了HPADashboard里可以直接看到当前目标指标和实际指标值。Dashboard里最让我受用的一个功能是查看某个Pod的日志不再需要kubectl logs -f一条条敲。有一个点必须提醒Dashboard默认显示的CPU指标是Core数量内存是字节数如果你在图表里看到数值变化规律诡异先确认单位再下结论。4.5 自定义Dashboard资源配额与隔离如果团队里有多个人共同使用Dashboard通常不希望所有人都拿到cluster-admin权限。更合理的做法是按角色拆分查看类权限绑定到view这个ClusterRole需要重启Pod的再给一个包含delete权限的自定义Role。Dashboard自带的RBAC模型和Kubernetes原生的RBAC是一致的所以控制好ServiceAccount的权限就控制了Dashboard的权限。如果你在Dashboard里创建了自定义资源比如某个命名空间下的DeploymentDashboard会直接用你的ServiceAccount身份去调用API Server权限校验是实时的。这个设计既方便又危险有时候你在Dashboard里删东西删不掉是因为当前Token对应的角色没有对应命名空间的删除权限这恰恰说明权限隔离生效了是好事。5. 实操过程从零到有一次完整走通5.1 完整命令时间线为了让你对这个过程有整体把握我把从零部署到成功看到Pod曲线的完整命令时间线放在这里。这部分每一行我都实际跑过你可以照抄。第一段部署Metrics Serverkubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml等Pod起来之后验证kubectl get pods -n kube-system -l app.kubernetes.io/namemetrics-server kubectl get apiservice v1beta1.metrics.k8s.io kubectl top node第二段部署Dashboardkubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml kubectl get pods -n kubernetes-dashboard -w第三段创建登录账号和获取Tokenkubectl create -f dashboard-adminuser.yaml kubectl -n kubernetes-dashboard create token admin-user第四段访问Dashboardkubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard 8080:443浏览器打开https://localhost:8080粘贴Token登录。进到界面以后点节点列表找到某个节点点击进去在Dashboards那个区域就能看到CPU和内存的曲线图。5.2 理解你看到的指标CPU与内存曲线怎么读登录Dashboard之后很多人第一反应是这曲线怎么看着不对。这里把读图的逻辑讲清楚。Dashboard里节点的CPU使用率是Metrics Server返回的实时样本它代表的是节点上所有容器进程CPU使用量的总和除以节点可分配的CPU核数。注意它不包含系统进程和内核本身的开销所以你会看到节点CPU使用率即使业务很忙也很难冲到100%因为有一部分CPU被kubelet、系统守护进程等占用但Metrics Server没有统计进去。内存同理节点内存使用率是Pod实际占用的量不包含Page Cache因此和free命令看到的used差别很大是正常的。某个Pod的CPU曲线出现尖峰不代表就是应用故障有可能是初始化容器在跑数据迁移或者Java应用的JIT编译瞬间占满核。要结合重启次数和调度事件一起判断才不容易误判故障。我自己踩过这样的坑一个Pod因为OOMKilled反复重启但CPU曲线看起来一点都不忙后来发现是内存配额设置得太低OOM发生在内存维度跟CPU没关系。5.3 让Dashboard显示HPA目标指标Dashboard支持查看HPA状态前提是你的集群里已经安装了Metrics Server。在Dashboard左侧导航找Horizontal Pod Autoscalers打开某个HPA的详情页能看到目标指标比如CPU利用率的当前值和目标值。如果当前值一直显示unknown基本可以断定Metrics Server没有就绪回到第3章去查。这里有一个配置细节值得单独说HPA如果想按Pod的平均CPU利用率扩缩容需要在Deployment上设置正确的resources.requests.cpu因为HPA的利用率是当前使用量除以请求量没有requestsHPA就没有计算基础Dashboard上也没法显示百分比。很多人部署了HPA但一直不生效问题往往出在资源请求没有设置。5.4 实操中我建议你补充的三个小工具Metrics Server和Dashboard不是万能的它们在历史趋势、告警方面很弱所以我在实践里会给这套组合补充三个轻量工具kube-state-metrics它把集群里各种对象的状态变成Prometheus格式的指标比如Deployment的期望副本数和实际副本数。Metrics Server只关心运行中的Pod资源使用而kube-state-metrics能反映配置层面的漂移。node-problem-detector检测节点层面的异常比如内核死锁、容器运行时无响应。这个东西是DaemonSet部署成本很低但能补齐Dashboard看不到的底层故障。sloop开源的小工具可以按时间线展示Pod的调度历史和状态变化对排查某个Pod为什么被驱逐特别有用。这些工具不是必选项但加上了之后你会发现这套监控从能看变成了能查。5.5 从演示走向生产参数调整与资源配额演示环境里使用默认参数没问题但生产环境有几个硬性要求建议提前调好。Metrics Server的Deployment需要显式声明资源requestsresources: requests: memory: 100Mi cpu: 100m不建议把requests设得太低否则在内存紧张的节点上Metrics Server可能被判定为不可调度而监控组件恰恰是最不该缺失的。Dashboard的Deployment默认资源请求比较保守在大量并发访问时会OOM。我在并发量高的环境会把它调到memory: 512Mi同时加上limits防止它把节点内存吃满。Dashboard的容器主要是渲染和代理API内存是主要瓶颈。另外Dashboard的Service默认是ClusterIP如果你需要跨集群访问而又不想开Ingress可以临时改Service类型为NodePort但访问时一定记得加TLS。端口转发适合排障NodePort适合短期的跨网络测试长期使用我更倾向于Ingress加内部DNS。6. 常见问题与排查技巧实录6.1 Metrics Server一直不Ready这是部署Metrics Server遇到最多的状况。Pod状态ContainerCreating一直不动一般就是镜像拉不下来按照镜像代理的方式处理。如果Pod显示CrashLoopBackOff先看日志kubectl logs -n kube-system -l app.kubernetes.io/namemetrics-server日志里常见的错误是unable to fully discover metrics: unable to fetch metrics from node。这种多半是kubelet的证书问题。Kubernetes 1.26以上的集群里kubelet会生成一个由集群根CA签名的服务证书但如果你没有把根CA配置到kubelet的--tls-cert-file参数里Metrics Server和kubelet之间会TLS握手失败。解决办法是给Metrics Server加上启动参数--kubelet-insecure-tls但这只是临时绕过证书验证。正规做法是把集群CA加入Metrics Server的信任列表也就是修改Deployment的volume和volumeMount把宿主机的/etc/kubernetes/pki/ca.crt挂载进去。生产环境我建议用正规做法--kubelet-insecure-tls能用但本质上是关闭了TLS验证审计时不好看。6.2 metrics.k8s.io的ABAC问题还有一个很不起眼但是坑过人的点如果集群开启了ABAC模式Metrics Server的注册可能不会生效。虽然现在几乎都是RBAC但老集群偶尔还会遇到。验证方法是在Master节点上查API Server的启动参数看有没有--authorization-modeABAC。如果确实开了需要把Metrics Server的ServiceAccount加入ABAC策略文件否则kubectl top会一直报metrics.k8s.io is forbidden。不过这种场景现在比较少见遇到的话基本上是历史原因短平快的处理方案是建议集群迁移时切到RBAC模式。6.3 Dashboard登录后白屏或空白我遇到过Dashboard能访问但登录后页面空白的情况。排查步骤按照这个顺序来浏览器F12看控制台有没有报错。常见的报错是failed to fetch metrics这种就回去查Metrics Server跟Dashboard本身没有关系。确认Token是真正的服务账号Token。新版Kubernetes里如果你用kubectl get secret admin-user-token-xxx -o jsonpath{.data.token}取出来的Token有些场景因为--legacy-service-account-token-clean-up的启动参数会被标记为无效Dashboard登录会直接失败。确认浏览器没有拦截跨域请求。Dashboard自身的API请求是从页面发到集群API Server如果中间有代理做了拦截就会出现白屏。白屏问题九成以上都是Token或者Metrics API不通Dashboard本身极少挂。6.4 数值显示NaN或者负数有段时间我配置了Metrics Server的自定义参数Dashboard里显示CPU利用率为NaN排查下来发现是抓取间隔调得太短Metrics Server在API Server做聚合时累计的计算窗口产生了边界问题CPU平均值算出来是空的。后来我把配置恢复默认数值就正常了。内存使用量为负数的情况多半发生在你给Pod设置的limits.memory小于实际节点上的Page Cache统计口径时虽然少见但遇上不要紧张怀疑统计口径差异而不是组件故障。6.5 端口转发可以访问但Ingress访问不通这个区别很典型。端口转发是直接走API Server代理如果转发通了说明Dashboard后端本身没问题。Ingress不通问题大多在Ingress Controller的HTTPS后端配置。你可以先关掉Ingress里的ssl-passthrough改用nginx.ingress.kubernetes.io/backend-protocol: HTTPS并确保证书Secret里的私钥和证书是配套的。还有一种情况是Ingress Controller自己没有监听443端口检查Controller的Service里是否暴露了443把它映射到宿主机端口即可。这类网络问题有个万能的排查起点在集群内curl一下Dashboard Service地址确认后端可达再从Ingress Controller所在节点curl Service地址逐段缩小范围问题很快就定位了。我实际用了这一套组合很久最大的感触是它帮我挡掉了大量半夜接到告警但不知道集群怎么了的焦虑。Metrics Server加Dashboard的监控能力虽然不算深但覆盖面刚刚好尤其是对中小规模集群从节点CPU到Pod内存再到HPA目标用一对组合就能讲清楚集群的大部分故事。踩过几次坑之后我现在的习惯是每次部署完都顺手把kubectl top node跑一遍把输出存下来当作集群初始状态的基线。如果以后要继续往深走可以在同一套链路里再引入Prometheus做长期存储和告警但第一步先让Dashboard上的曲线亮起来这比什么都有说服力。