企业官网建设流程全解析

集群跑起来之后，第一件事不是欢天喜地部署业务，而是把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处理。

实际采集过程是这样的：集群里的每个节点都有kubelet，kubelet内置了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是整个资源监控的基座，它一旦缺失，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。你可以直接执行下面的命令看一眼当前系统里已经注册了哪些APIService：

kubectl 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 doesn't 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-types=InternalIP - --metric-resolution=30s

第一个解决证书问题，第二个让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并创建登录Token

Dashboard的部署相对简单，官方仓库提供了完整的YAML清单，直接应用即可：

kubectl apply -f recommended.yaml

部署完成后会新建一个kubernetes-dashboard命名空间，里面有Deployment、Service和几个关联的RBAC资源。检查一下Pod状态：

kubectl get pods -n kubernetes-dashboard

Pod处于Running状态后，Service也会正常创建。默认dashboard Service的类型是ClusterIP，外部还不能直接访问，这一步后面配置。

接下来创建管理员账号。首先创建一个ServiceAccount：

kubectl create serviceaccount admin-user -n kubernetes-dashboard

然后把集群管理员角色绑定给它：

kubectl create clusterrolebinding admin-user-binding --clusterrole=cluster-admin --serviceaccount=kubernetes-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 --verb=get,list,watch --resource=* kubectl create clusterrolebinding view-user-binding --clusterrole=view-user --serviceaccount=kubernetes-dashboard:view-user

不过要注意，view-user这种粗粒度角色虽然能看，但连Secret的明文内容也看不了，一些排障需求可能不够用。更灵活的做法是给不同命名空间创建RoleBinding，只允许查看指定命名空间的资源。权限设计没有标准答案，完全取决于团队规模和协作方式，但有一条原则不会变：默认最小权限，缺了再加。

4. 常见问题与排查实录

4.1 高频错误速查表

以下这些问题是部署和使用过程中出现频率最高的，我把现象、原因和处理办法整理成了表格，方便实际操作时快速对照。

这张表覆盖了我接触过的绝大多数现场问题。最典型的组合拳是：先看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-app=metrics-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的输出要直观得多，也更容易发现异常苗头。如果你刚搭好集群还不知道从哪里开始做监控，不妨就先从这套组合入手，把资源水位看清楚了，后面再决定要不要上更重的监控全家桶。