共计 2988 个字符，预计需要花费 8 分钟才能阅读完成。
KubeSphere v3.1.0 通过集成 KubeEdge，将节点和资源的治理延长到了边缘，也是 KubeSphere 正式反对边缘计算的第一个版本。
笔者也第一工夫搭建和试用了边缘节点相干的性能，然而在边缘节点纳管之后遇到了一些监控的小问题，在排查过程中也顺带理解了一下 KubeSphere 对于边缘节点的监控原理，收回来和大家分享，不便其余的开发者可能更快的排查问题或进行二次开发。
环境版本和形成
通过 KubeKey 装置，参数如下，其余组件版本默认未改变。
Kubernetes : v1.19.8
KubeSphere : v3.1.0
| 主机名称 | 角色 |
|---|---|
| k8s-worker-03 | worker |
| k8s-worker-02 | master |
| k8s-worker-01 | master,etcd |
问题景象
通过生成的 keadm 命令即将边缘节点退出集群，并在边缘节点上部署 POD，该 POD 的监控信息不能显示。
监控原理
定位和解决问题之前，必定是要先搞懂工作原理。
1. KubeEdge
KubeEdge 的 Edgecore 组件对 Kubelet 进行了轻量化革新，Edgecore 和 Cloudcore(云端)也不在同一个 Cluster 网络中，通过 k8s 默认的形式进行 metrics 获取必定是行不通的(logs 和 exec 原理雷同)。
以后 KubeEdge 的实现办法是 kube-apiserver 上的 iptables 转发给云端的 Cloudcore，Cloudcore 通过和 Edgecore 之间的 WebSocket 通道向边缘端进行音讯和数据传递。
KubeEdge 官网的使用手册和文档：https://kubeedge.io/en/docs/a…
为了便于大家了解，作者画了一张图，整体的流程请参考如下：
2. Metrics-server
原生的 K8S 中就是通过 Metrics-server 这个官网组件进行节点和 POD 的 CPU/Memory 等数据的监控。
简而言之，Metrics-server 通过 Pull 的形式去每个节点上拉取监控数据，放在本身的内存中，提供 K8S 的 API 供 kubectl top 这样的 client 来查问。
Metrics-server 的具体设计，能够参考 github 的官网阐明：https://github.com/kubernetes…
Metrcis-server 的启动参数中，有一个参数要特地阐明一下：”_kubelet-use-node-status-port_”。
在 KubeEdge 的官网文档中，也提到了启动 Metrics-server 时要指定该参数，至于起因文档中并未提及，这里简略阐明一下。这个参数的意思是：“调用 kubelet 服务时，用该 Node 上报的 port，而不是默认的 port”。咱们晓得 kubelet 的 metrcis 接口默认是监听在 10250 端口的，而 KubeEdge 的 edgecore 将 metrics 接口默认监听在 10350 端口，如果不加这个参数，metrice-server 就会通过相似 ”_edgenodeIP:10250/stat/summary_” 这样的申请去获取监控数据，后果必定获取失败的。
咱们通过 KubeSphere 环境的 yaml 文件，也能清晰地看到这一点配置：
3. KubeSphere
下面讲到了，Metrics-server 曾经从 KubeEdge 那里获取到了边缘节点的监控数据，那么 KubeSphere 只有从 Metrics-server 提供的 K8S API 中即可获取到边缘节点的实时监控数据用来在前端进行展现。
略微翻了一下 KubeSphere 的代码，和咱们的料想是统一的，KubeSphere 通过 metrics-server 拿到了以后版本展现的监控数据。
4. EdgeWatcher
从上述第 1 点 KubeEdge 的工作原理来看，是须要在 kube-apiserver 所在的节点上进行 iptables 转发规定设置的(将所有 10350 的申请都转发给 Cloudcore 的 10003 端口进行解决)。
那么每一个边缘节点退出集群的时候不可能由运维人员手动进行 iptables 的规定设置，所以 KubeSphere 就自研了 EdgeWatcher 这样一个组件。这个组件的目标应该是有以下几点：
- 提供 kubeedge group API(增加边缘节点时前端调用该 group API)
- 边缘节点退出集群时，设置 IPtables 规定(logs exec metrics 都须要)
- 验证边缘节点指定的 IP 是否可用，IP 须要全局惟一
EdgeWatcher 暂未开源，作者从社区转载了上面这张 EdgeWatcher 的工作原理图，供大家参考：
对于边缘节点 IP 须要全局惟一的问题，作者还是有很多想说的，后续有工夫再开一篇，和大家一起探讨。
5. 总体概览
其实通过对上述监控组件的理解，咱们也根本能勾画出 KubeSphere v3.1 在基于 KubeEdge 的边缘集成中，所作的致力和工作。上面是作者简略画的一张整体组件架构的图，供大家参考：
问题定位
既然原理都搞清楚了，上面就简略说一下定位的过程和思路。
1. Metrics-server
首先咱们判断 metrics-server 有没有失常提供服务，能不能获取到边缘数据。
从上面的命令后果能够看出，边缘节点 (k8s-agent) 的监控数据和非边缘节点的 POD 的监控数据都是没有问题的。
只有边缘节点上的 POD 的监控数据获取不到。
2. KubeEdge
再来看 KubeEdge 提供的 10350 端口的 metrics 服务，有没有问题。
咱们能够看到，KubeEdge 的 edgecore 提供的 10350 端口的服务也是没有问题的，能够从中获取到边缘节点和边缘 POD(nginx-xxx)的监控数据。
3. 总结
从下面的剖析能够得出以下论断：
- Metrcis-server 没问题
- KubeEdge 的 edgecore 在边缘节点的服务没问题
- cloudcore 和 edgecore 之间的通路没有问题(通过查看 edgecore 的日志，能够看到 stat/summary 的调用，然而 POD 的监控数据调用则没有)
最初再去确认其余能够获取边缘 POD 节点的信息，发现只有 docker 版本的差异，出问题的是 v18.09.1，而失常的节点版本如下：
至此，根本能判定是 docker 版本过低造成的，至于是哪个接口和 metrics-server 不能兼容，就不花太多工夫去考察剖析，有教训的开发者能够留言共享一下。
论断
基于这个问题，咱们对 Docker 版本进行了测试，最终确认在 Kubesphere v3.1、metrics-server 版本(v0.4.2)、KubeEdge v1.6.1 的场景下，Docker 版本要大于等于 v19.3.0 能力反对边缘 POD 的监控。KubeEdge 官网最新版本 v1.7.1 曾经公布，从 v1.6.2 的 Changelog 来看，该问题曾经被修复了。造成该 pod metrics 失落的起因，应该是 edgecore 应用的 K8s 版本过低导致的。详情可参考官网 KubeEdge v1.6.2 的 Changelog。
后记
尽管问题不是很大，然而通过这个小问题能把边缘监控的脉络搞清楚，是比问题自身更有意义的。
通过这样的剖析和总结，问题定位和二次开发的效率才会更高，心愿咱们社区的开发者一起把 KubeSphere 做得更好更欠缺。
本文由博客一文多发平台 OpenWrite 公布！
