1.本技术涉及数据处理技术，尤其涉及一种kubernetes边缘集群的数据监测方法和装置。
背景技术：
：：2.在典型的边缘计算场景中，往往需要监测边缘节点及边缘节点上容器的资源开销，如cpu、内存、磁盘、网络等的指标数据；还需要监测容器运行状态，如容器的cpu、内存、磁盘、网络等的指标数据。这样才能全面掌控边缘计算集群的运行状态。在应用于边缘计算场景时，kubernetes集群也称为kubernetes边缘集群，集群中的边缘节点往往处于封闭的局域网内，从中心节点无法直接访问到边缘节点，也即形成单向连通的网络环境。受限于单向连通的网络环境，传统的监测服务(如prometheus)主动拉取(pull)的方式获取指标数据的监测方案将无法正常工作。3.为了解决这一问题，业界(例如openyurt、superedge等)普遍采用了通过tunnel隧道的方式，打通中心节点和边缘节点的连接通路，使得部署于中心节点的监测服务能够借助tunnel隧道与边缘节点连通，实现完成数据采集。4.但是，这种方式存在如下技术问题：一是指标数据的采集流量与控制面流量共享一个tunnel隧道，会给tunnel组件带来极大的压力，影响系统稳定性，严重时将导致控制指令(比如kubectllogs/exec等)无法正确执行；二是tunnel隧道的路由解析实例(tunnelserver)需要和监测服务(如prometheus实例的apiserver)强绑定到同一节点，监测服务的横向扩展和tunnel隧道路由解析实例的横向扩展强耦合，无法实现弹性扩缩容。技术实现要素：5.本技术提供一种kubernetes边缘集群的数据监测方法和装置。6.一方面，本技术提供一种kubernetes边缘集群的数据监测方法，应用于kubernetes边缘集群中的边缘节点，所述边缘节点上运行有采集代理，包括：7.通过所述采集代理执行如下数据采集处理：8.挂载采集配置信息，所述采集配置信息包括监测数据的数据格式、访问监测数据提供服务所需的访问配置信息、推送指标数据的目标地址信息；9.根据所述监测数据的数据格式和所述访问配置信息，在本地主机网络内访问监测数据提供服务，从所述监测数据提供服务获取所述边缘节点的监测数据；10.根据所述目标地址信息，向中心节点推送所述边缘节点的监测数据。11.另一方面，本技术提供一种kubernetes边缘集群的数据监测方法，应用于kubernetes边缘集群中的中心节点，所述中心节点上运行有负载均衡服务，包括：12.通过所述负载均衡服务接收边缘节点推送的所述边缘节点的监测数据；13.存储所述边缘节点的监测数据。14.另一方面，本技术提供一种kubernetes边缘集群的数据监测，应用于kubernetes边缘集群，所述kubernetes边缘集群包括边缘节点和中心节点，所述边缘节点上运行有采集代理，所述中心节点上运行有负载均衡服务，所述方法包括：15.所述边缘节点通过所述采集代理，挂载采集配置信息，所述采集配置信息包括监测数据的数据格式、访问监测数据提供服务所需的访问配置信息、推送指标数据的目标地址信息；根据所述监测数据的数据格式和所述访问配置信息，在本地主机网络内访问监测数据提供服务，从所述监测数据提供服务获取所述边缘节点的监测数据；根据所述目标地址信息，向中心节点推送所述边缘节点的监测数据；16.所述中心节点通过所述负载均衡服务接收边缘节点推送的所述边缘节点的监测数据，存储所述边缘节点的监测数据。17.另一方面，本技术提供一种kubernetes边缘集群的数据监测装置，应用于kubernetes边缘集群中的边缘节点，所述边缘节点上运行有采集代理，包括：18.数据采集模块，用于通过所述采集代理执行如下数据采集处理：19.挂载采集配置信息，所述采集配置信息包括监测数据的数据格式、访问监测数据提供服务所需的访问配置信息、推送指标数据的目标地址信息；20.根据所述监测数据的数据格式和所述访问配置信息，在本地主机网络内访问所述监测数据提供服务，从所述监测数据提供服务获取所述边缘节点的监测数据；21.根据所述目标地址信息，向中心节点推送所述边缘节点的监测数据。22.另一方面，本技术提供一种kubernetes边缘集群的数据监测装置，应用于kubernetes边缘集群中的中心节点，所述中心节点上运行有负载均衡服务，包括：23.数据接收模块，用于通过所述负载均衡服务接收边缘节点推送的所述边缘节点的监测数据；24.数据存储模块，用于存储所述边缘节点的监测数据。25.另一方面，本技术提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；所述存储器存储计算机执行指令；所述处理器执行所述存储器存储的计算机执行指令，以实现上述任一方面所述的方法。26.另一方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现上述任一方面所述的方法。27.本技术提供的kubernetes边缘集群的数据监测方法和装置，通过将采集agent部署到每个边缘节点上，采集agent与node-exporter服务、kubelet服务和cadvisor服务等监测数据提供服务都运行在边缘节点上，采集agent与node-exporter服务都以hostnetwork的方式启动pod，通过宿主机网络，每个边缘节点上的采集agent只需要和本机的监测数据提供服务交互即可采集到监测数据，并采用数据push方式，通过采集agent向中心节点上的监测服务(包含负载均衡服务)推送监测数据，分离了监测数据采集流量和控制面流量，并且控制面流量用下行带宽，监测数据采集流量用上行带宽，使用不同的tcp连接，彻底地将监测数据采集流量从下行通道中剥离出来，保证控制命令通道不会被影响。进一步地，监测服务端提供一个用于接收监测数据的负载均衡服务，所有边缘节点的采集agent只需连接该负载均衡服务即可实现监测数据推送，监测数据采用push的方式走上行通道，由于在边缘方案中只有下行的流量才需要tunnelserver做路由边缘节点的路由，这样监测服务不再要求部署在tunnelserver所在节点，无需将监测服务与tunnelserver强绑定到同一节点，解耦监测服务的横向扩展和tunnel隧道路由解析实例的横向扩展，能够实现弹性扩缩容，提高监测服务的灵活性。附图说明28.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。29.图1为本技术提供的传统监测方案的架构示例图；30.图2为本技术提供的kubernetes边缘集群的数据监测方法使用的部署架构示意图；31.图3为本技术一实施例提供的kubernetes边缘集群的数据监测方法流程图；32.图4为本技术另一实施例提供的kubernetes边缘集群的数据监测方法流程图；33.图5为本技术一实施例提供的采集代理通过宿主机网络采集监测数据的架构示意图；34.图6为本技术一实施例提供的kubernetes边缘集群的数据监测方法的总体架构示意图；35.图7为本技术一实施例提供的一种示例架构与数据链路的示意图；36.图8为本技术一实施例提供的kubernetes边缘集群的数据监测装置的结构示意图；37.图9为本技术另一实施例提供的kubernetes边缘集群的数据监测装置的结构示意图。38.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。具体实施方式39.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。40.首先对本技术所涉及的名词进行解释：41.容器：一种基于进程的隔离运行技术。42.kubernetes：缩写为k8s，容器编排系统，负责管理自动化部署、伸缩、管理容器。43.kubelet：kubernetes中在每个节点上都会运行的程序组件，负责pod对应的容器的创建、启停等任务。同时与kubernetes集群密切协作，实现集群管理的基本功能。44.cadvisor：kubelet中包含的一个服务，它会收集容器相关信息。45.node：kubernetes集群中被管理的独立主机称为node，也叫节点，可以是物理机或虚拟机。46.node资源：node提供的计算资源，包括且不限于cpu、内存、gpu等。47.pod：是kubernetes中创建和管理的最小可部署计算单元，由一个或多个容器组成。48.daemonset：是kubernetes中的一种应用部署资源的方式，某一功能模块以daemonset方式部署时，它会在每个node上最多部署一个该功能模块的pod，起到节点级别应用部署的作用。49.confimap：kubernetes中的一种资源，可以用来存储基于字符串的数据。50.边缘计算：一种云计算技术，采用数据消费、加工贴近本地数据的方式来解决数据传输导致的计算延迟问题。51.中心节点：也即云端节点，边缘计算集群中用于部署管控组件的节点。52.边缘节点：边缘计算集群中用于业务数据处理的节点，可以在无网络场景下运行。53.tunnel隧道：kubernetes边缘集群中连接中心节点和边缘节点的网络通道，用于传输kubernetesapi调用的数据包。54.prometheus(普罗米修斯)：一种监测控制数据的整体解决方案，包括数据采集、数据存储、数据查询接口等功能。55.metrics：业务、系统组件暴露的监测指标项(监测数据)，供采集系统收集。一般以http/https接口方式暴露。56.prometheuspull：prometheus方案中的metrics采集方式，即prometheus的采集应用调metrics提供者的http/https接口来获取监测指标项。57.采集代理：也即采集agent，部署在边缘节点上的metrics采集程序。具备metrics收集、缓存、传输功能。58.采集配置：用于声明metrics服务的提供方访问的协议、ip地址、端口，采集数据格式，数据传输目标地址等采集相关的信息。59.node-exporter：一种收集节点cpu、内存、磁盘、网络metrics的程序，用于节点监测。60.lb(loadbalance)：负载均衡服务，用于将工作负载分布到多个服务器来提高服务的性能和可靠性。61.另外，术语“第一”、“第二”、“第三”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。62.在典型的边缘计算场景中，往往需要监测边缘节点的资源开销，如cpu、内存、磁盘、网络等的指标数据；还需要监测容器运行状态，如容器的cpu、内存、磁盘、网络等的指标数据。这样才能全面掌控边缘计算集群的运行状态。在应用于边缘计算场景时，kubernetes集群也称为kubernetes边缘集群，集群中的边缘节点往往处于封闭的局域网内，从中心节点无法直接访问到边缘节点，也即形成单向连通的网络环境。受限于单向连通的网络环境，传统的监测服务(如prometheus)主动拉取(pull)的方式获取指标数据的监测服务器将无法正常工作。63.为了解决这一问题，业界(例如openyurt、superedge等)普遍采用了通过tunnel隧道的方式，打通中心节点和边缘节点的连接通路，使得部署于中心节点的监测服务能够借助tunnel隧道与边缘节点连通，实现完成数据采集。64.示例性地，以监测服务为prometheus为例，对openyurt、superedge等传统的监测方案的系统架构进行示例性地说明，在openyurt、superedge等传统的监测方案中，采用如图1所示的系统架构，图1中监测采集应用是指prometheus，apiserver为prometheus的接口服务也即prometheus实例。edgeagent是部署在边缘节点上的边缘代理。采用原生prometheus的方式收集边缘节点上的监测数据(metrics)。65.传统的监测方案存在如下技术问题：66.一是，指标数据的采集流量与控制面流量共享一个tunnel隧道，会给tunnel组件带来极大的压力，影响系统稳定性，严重时将导致控制指令(比如kubectllogs/exec等)无法正确执行。67.二是，基于iptables(数据包的转发路由规则)方案的tunnelserver对组件的部署形态存在约束，要求tunnel隧道的路由解析实例(tunnelserver)必须和prometheus实例部署在相同的节点上才能工作，当prometheus实例中发生pod漂移(如当一台机器上的pod出现故障时，kubernetes会自动将该机器上的pod迁移到另一台正常工作的机器上)时，容易因为缺少路由配置而出现采集中断的问题，这种部署形态捆绑束缚了prometheus的灵活部署，prometheus的横向扩展和tunnel隧道路由解析实例的横向扩展强耦合，无法实现弹性扩缩容。68.三是，基于tunnel隧道的监测方案难以处理边缘节点ip地址重复的问题(边缘节点ip地址重复在边缘计算场景中十分常见)，由于采集的目的地址是相同的ip，无论是tunnel的数据转发还是prometheus的数据采集都会遇到问题，为解决这一问题，业内通过节点名称访问边缘节点的方式存在配置复杂，自动化程度低，容易影响系统稳定性等缺点。69.最后，如果tunnel隧道断开，prometheus将无法采集到任何数据，边缘节点的弱网运行状态将无法被感知。70.本技术提供的一种全新的kubernetes边缘集群的数据监测方法，应用于边缘计算场景中的kubernetes边缘集群，依托kubernetes分发采集代理(实例)和采集配置到各个边缘节点上，由采集代理在边缘节点上发起metrics的采集并以push的方式将metrics发送到中间节点上的监测服务。这个监测服务通过唯一的eip(enterpriseinformationportal，企业信息门户)声明在采集配置信息中，让监测服务(如prometheus实例)不再和tunnel隧道路由解析实例产生联系，解决了横向扩展上的耦合约束。同时，在中心节点上接受metric推送结果的负载均衡服务可以自行决定是否横向扩容，监测方案的可用性更高。另外，采用push方式推送metrics，解耦了kubernetes边缘集群中控制面流量和监测数据采集流量，提升了集群的管控的可用性和稳定性。最后，监测数据的采集端运行在边缘节点上并配置了采集数据的存储空间缓存监测数据，来应对边缘节点弱网、断网运行的状态，最大限度的保留metrics数据。综上，这种全新的监测方案，解决了数据通道压力、监测服务横向扩容难、监测数据完整性等核心问题，提升了边缘容器产品的竞争力。71.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。72.示例性地，本技术提供的kubernetes边缘集群的数据监测方法，应用于边缘计算场景中的kubernetes边缘集群，基于如图2所示的架构进行部署，将采集agent(采集代理)以daemonset的方式部署到每一个边缘节点上，采集agent占用一个或者多个pod。在每个边缘节点上通过采集agent监测边缘节点和容器的监测数据(metrics)。kubernetes边缘集群中node-exporter服务和edgeagent也是以daemonset的方式部署到每一个边缘节点上。其中，采集agent和node-exporter服务都以hostnetwork的方式启动pod。另外，每一个边缘节点上部署了kubelet组件，kubelet组件中包含kubelet服务和cadvisor服务。node-exporter服务用于提供节点级的监测数据，kubelet服务用于提供pod级的监测数据，cadvisor服务用于提供容器级的监测数据。这样，通过宿主机网络，每个边缘节点上的采集agent只需要和本机的监测数据提供服务(包括node-exporter服务、kubelet服务和cadvisor服务)交互即可，在边缘节点自身网络内形成监测数据采集的闭环，不需要跨网络访问，从而实现一个封闭、稳定的采集环境。通过给采集agent挂载采集配置信息(如图2中所示的采集配置configmap)、kubelet证书文件(如图2中所示的kubelet证书secret)实现采集agent与同一节点上的node-exporter、kubelet、cadvisor对接，采集监测数据，并实现采集agent与中心节点上的监测服务的对接，推送(push)监测数据。73.另外，在实际应用中，可以根据实际需要，配置采集代理所需采集的监测数据。可以配置采集代理从node-exporter服务、kubelet服务和cadvisor服务中的一个或多个监测数据提供服务获取监测数据。74.图3为本技术一实施例提供的kubernetes边缘集群的数据监测方法流程图。本实施例提供的kubernetes边缘集群的数据监测方法具体可以应用于kubernetes边缘集群中监测边缘节点的监测数据(metrics)。75.如图3所示，该方法具体步骤如下：76.步骤s101、边缘节点通过采集代理挂载采集配置信息，采集配置信息包括监测数据的数据格式、访问监测数据提供服务所需的访问配置信息、推送指标数据的目标地址信息。77.本实施例中，每个边缘节点上均运行有采集代理，并且给采集代理挂载采集配置信息。78.其中，采集配置信息包括待采集的监测数据的数据格式、访问监测数据提供服务所需的访问配置信息、推送指标数据的目标地址信息。79.访问监测数据提供服务所需的访问配置信息包括：访问监测数据提供服务所需的协议、ip地址、端口号等信息。根据该访问配置信息，可以访问监测数据提供服务，从监测数据提供服务获取到监测数据。80.推送指标数据的目标地址信息是指中心节点上部署的用于监测服务中用于接收监测数据的服务的地址信息，可以是中心节点上负载均衡服务的地址信息。81.步骤s102、通过采集代理根据监测数据的数据格式和访问配置信息，在本地主机网络内访问监测数据提供服务，从监测数据提供服务获取边缘节点的监测数据。82.其中，监测数据提供服务包括：node-exporter服务、kubelet服务和cadvisor服务中一个或者多个。83.本实施例中，采集agent与node-exporter服务、kubelet服务和cadvisor服务等监测数据提供服务都运行在边缘节点上，采集agent与node-exporter服务都以hostnetwork的方式启动pod。当pod配置为hostnetwork：true时，在此类pod中运行的应用程序可以直接查看启动pod的边缘节点的网络接口。这样，通过宿主机网络，每个边缘节点上的采集agent通过和本机的监测数据提供服务交互即可实现监测数据的采集，在边缘节点自身网络内形成监测数据采集的闭环，不需要跨网络访问，从而实现一个封闭、稳定的采集环境。84.该步骤中，根据监测数据的数据格式和访问配置信息，通过采集代理访问监测数据提供服务，从监测数据提供服务获取边缘节点的监测数据。85.示例性地，node-exporter服务默认采用http协议9101端口暴露监测数据(metrics)，kubelet服务默认采用http协议10255端口暴露监测数据(metrics)，cadvisor服务默认采用https协议10250端口暴露监测数据(metrics)。通过采集agent直接通过宿主机的localhost访问上述端口加对应的统一资源标志符(uniformresourceidentifier，简称uri)即可获取到对应的监测数据(metrics)。86.步骤s103、通过采集代理根据目标地址信息，向中心节点推送边缘节点的监测数据。87.在采集到监测数据之后，通过采集代理根据目标地址信息向中心节点推送边缘节点的监测数据，采用数据push方式，监测服务端提供写的服务接口(如负载均衡服务接口)，监测服务不再需要解决寻找边缘节点路由的问题，从而实现监测系统的高可用性。88.步骤s104、中心节点通过负载均衡服务接收边缘节点推送的边缘节点的监测数据。89.本实施例中，监测服务部署在中心节点上，监测服务包含一个负载均衡服务，通过负载均衡服务接收边缘节点推送的监测数据。90.步骤s105、存储边缘节点的监测数据。91.在接收到边缘节点的监测数据后，根据负载均衡策略在中心节点存储边缘节点的监测数据。92.本实施例提供的kubernetes边缘集群的数据监测方法，通过将采集agent部署到每个边缘节点上，采集agent与node-exporter服务、kubelet服务和cadvisor服务等监测数据提供服务都运行在边缘节点上，采集agent与node-exporter服务都以hostnetwork的方式启动pod，通过宿主机网络，每个边缘节点上的采集agent只需要和本机的监测数据提供服务交互即可采集到监测数据，并采用数据push方式，通过采集agent向中心节点上的监测服务(包含负载均衡服务)推送监测数据，分离了监测数据采集流量和控制面流量，并且控制面流量用下行带宽，监测数据采集流量用上行带宽，使用不同的tcp连接，彻底地将监测数据采集流量从下行通道中剥离出来，保证控制命令通道不会被影响。93.进一步地，监测服务端提供一个用于接收监测数据的负载均衡服务，所有边缘节点的采集agent只需连接该负载均衡服务即可实现监测数据推送，监测数据采用push的方式走上行通道，由于在边缘方案中只有下行的流量才需要tunnelserver做路由边缘节点的路由，这样监测服务不再要求部署在tunnelserver所在节点，无需将监测服务与tunnelserver强绑定到同一节点，解耦监测服务的横向扩展和tunnel隧道路由解析实例的横向扩展，能够实现弹性扩缩容，提高监测服务的灵活性。94.在上述图1对应实施例的基础上，边缘节点上运行的监测数据提供服务包括node-exporter服务、kubelet服务和cadvisor服务。所需采集的监测数据可以包括以下至少一项：边缘节点的第一指标数据，边缘节点上运行的pod的第二指标数据，边缘节点上容器的第三指标数据，第一指标数据为节点级的指标数据，第二指标数据为pod级的指标数据，第三指标数据为容器级的指标数据。95.本实施例中，以所需采集的监测数据包括边缘节点的第一指标数据，边缘节点上运行的pod的第二指标数据和边缘节点上容器的第三指标数据，也即需要采集node-exporter服务、kubelet服务和cadvisor服务提供的监测数据为例，对kubernetes边缘集群的数据监测方法的详细流程进行示例性地说明。96.如图4所示，该方法具体步骤如下：97.步骤s201、边缘节点通过采集代理挂载采集配置信息和kubelet证书文件。98.其中，采集配置信息包括待采集的监测数据的数据格式、访问监测数据提供服务所需的访问配置信息、推送指标数据的目标地址信息。99.访问监测数据提供服务所需的访问配置信息包括：访问监测数据提供服务所需的协议、ip地址、端口号等信息。根据该访问配置信息，可以访问监测数据提供服务，从监测数据提供服务获取到监测数据。100.推送指标数据的目标地址信息是指中心节点上部署的用于监测服务中用于接收监测数据的服务的地址信息，可以是中心节点上负载均衡服务的地址信息。101.在访问cadvisor服务的时候需要使用kubelet的证书，本实施例中，可以复用apiserver使用的kubelet证书，可以根据kubernetes集群中接口服务器(即apiserver)所使用的kubelet证书生成的kubelet的证书文件(也即kubelet的证书secret)，并存储到边缘节点上，供采集代理挂载使用来连接cadvisor服务。102.可选地，边缘节点可以通过一个job拉起亲和到中心节点上的pod，为apiserver使用的kubelet证书生成对应的证书文件(secret)，并存储到宿主机上，供采集代理挂载和使用。103.其中，job一种特殊的pod，使用执行一次的任务，执行完释放资源。104.通过采集代理挂载采集配置信息和kubelet证书文件之后，执行步骤s202-s204，通过边缘节点运行的采集代理，在本地主机网络内访问监测数据提供服务，从监测数据提供服务获取边缘节点的监测数据。105.本实施例中，采集agent与node-exporter服务、kubelet服务和cadvisor服务等监测数据提供服务都运行在边缘节点上，采集agent与node-exporter服务都以hostnetwork的方式启动pod。当pod配置为hostnetwork：true时，在此类pod中运行的应用程序可以直接查看启动pod的边缘节点的网络接口。这样，如图5所示，通过宿主机网络，每个边缘节点上的采集agent(图5中所示的agentpod是指采集agent的pod)通过和本机的监测数据提供服务交互即可实现监测数据的采集，在边缘节点自身网络内形成监测数据采集的闭环，不需要跨网络访问，从而实现一个封闭、稳定的采集环境。106.在采集agent的pod启动时挂载采集配置信息和kubelet证书文件即可。107.步骤s202、通过采集代理在本地主机网络内访问node-exporter服务，从node-exporter服务获取边缘节点的第一指标数据，第一指标数据为节点级的指标数据。108.其中，第一指标数据是node-exporter服务提供的节点级的监测数据，包括至少一个指标项的指标数据。109.示例性地，第一指标数据可以包括节点的cpu、内存、磁盘、网络等相关的指标项的指标数据。110.另外，所需采集的监测数据中的第一指标数据具体包含哪些指标项，可以根据实际监测场景的需要在采集配置信息中进行设置和调整，此处不做具体限定。111.示例性地，node-exporter服务默认采用http协议9101端口暴露监测数据(metrics)。另外，node-exporter服务使用的端口还可以根据实际需要进行设置和调整，此处不做具体限定。112.该步骤中，采集agent通过宿主机的localhost访问node-exporter服务对应的端口加对应的uri即可获取到节点级的监测数据(第一指标数据)。113.步骤s203、通过采集代理在本地主机网络内访问kubelet服务，从kubelet服务获取边缘节点上运行的pod的第二指标数据，第二指标数据为pod级的指标数据。114.其中，第二指标数据是kubelet服务提供的pod级的监测数据，包括至少一个指标项的指标数据。115.示例性地，第二指标数据可以包括边缘节点上的pod使用的cpu、内存、磁盘、网络等相关的指标项的指标数据。116.另外，所需采集的监测数据中的第二指标数据具体包含哪些指标项，可以根据实际监测场景的需要在采集配置信息中进行设置和调整，此处不做具体限定。117.示例性地，kubelet服务默认采用http协议10255端口暴露监测数据(metrics)。另外，kubelet服务使用的端口还可以根据实际需要进行设置和调整，此处不做具体限定。118.该步骤中，采集agent通过宿主机的localhost访问kubelet服务对应的端口加对应的uri即可获取到边缘节点上pod级的监测数据(第二指标数据)。119.步骤s204、通过采集代理在本地主机网络内访问cadvisor服务，从cadvisor服务获取边缘节点上容器的第三指标数据，第三指标数据为容器级的指标数据。120.其中，第三指标数据是cadvisor服务提供的容器级的监测数据，包括至少一个指标项的指标数据。121.示例性地，第三指标数据可以包括边缘节点上的容器的cpu、内存、磁盘、网络等资源开销，容器的生命周期，容器的运行状态等相关的指标项的指标数据。122.另外，所需采集的监测数据中的第三指标数据具体包含哪些指标项，可以根据实际监测场景的需要在采集配置信息中进行设置和调整，此处不做具体限定。123.示例性地，cadvisor服务默认采用https协议10250端口暴露监测数据(metrics)。另外，cadvisor服务使用的端口还可以根据实际需要进行设置和调整，此处不做具体限定。124.该步骤中，采集agent通过宿主机的localhost访问cadvisor服务对应的端口加对应的uri即可获取到边缘节点上容器级的监测数据(第三指标数据)。125.需要说明的是，步骤s202、s203、s204这三个步骤可以并行地进行，也可以按照特定顺序依次进行，此处对于这三个步骤的执行顺序不做具体限定。126.步骤s205、根据目标地址信息，向中心节点推送边缘节点的节点名称和监测数据。127.在采集到监测数据之后，通过采集代理根据目标地址信息向中心节点推送边缘节点的监测数据，采用数据push方式，监测服务端提供写的服务接口(如负载均衡服务接口)，让监测服务不再需要解决寻找边缘节点路由的问题，从而实现监测系统的高可用性。128.其中，目标地址信息可以是中心节点上负载均衡服务的访问地址信息。129.本实施例中，由于采集agent的pod部署到了每个边缘节点上，可以通过kubernetes原生的方式获取边缘节点的节点名称(nodename)并加载到采集agent的pod上。130.在该步骤之前，采集代理获取所在边缘节点的节点名称。在推送边缘节点的监测数据时，将边缘节点的节点名称和监测数据一起推送，从而将监测数据打上边缘节点的节点名称的标记，很容易区分不同边缘节点的监测数据，解决了边缘节点ip地址重复的问题。131.可选地，中心节点的负载均衡服务接收边缘节点的监测数据成功之后，向边缘节点的采集agent反馈响应消息。边缘节点上的采集agent若在预设等待时长内没有接收到相应的响应消息，则确定边缘节点的监测数据推送失败，采集agent在本地存储空间存储边缘节点的监测数据。采集agent根据重新推送规则，重新推送边缘节点的监测数据。132.示例性地，若边缘节点处于断网或弱网环境下，会导致边缘节点的采集agent向中心节点推送监测数据失败，采集agent在本地存储空间存储边缘节点的监测数据；并根据重新推送规则，重新推送边缘节点的监测数据，解决了传统监测方案在断网或弱网环境下无法采集监测数据的问题。133.其中，根据重新推送规则，随着边缘节点的监测数据的推送次数的增加，重新推送边缘节点的监测数据的间隔时间增长。134.示例性地，重新推送规则可以为：按照30秒、1分、2分、4分、16分、32分、1小时……的时间间隔来尝试重新推送监测数据，通过用倍增重推的时间间隔来退避网络的异常，降低推送风暴出现的概率。135.可选地，还可以设置本地存储空间的存储上限，若本地存储空间中存储的数据量大于或等于存储上限，则边缘节点可以根据本地存储空间已存储的监测数据的时间信息，删除本地存储空间中的较早的部分数据，从而控制本地存储空间的上限，防止边缘节点的存储空间被打爆，造成边缘节点瘫痪。136.另外，在边缘节点的监测数据重新推送成功后，将推送成功的监测数据从本地存储空间删除。137.步骤s206、中心节点通过负载均衡服务接收边缘节点推送的边缘节点的监测数据。138.在采集到监测数据之后，通过采集代理根据目标地址信息向中心节点推送边缘节点的监测数据，采用数据push方式，监测服务端提供写的服务接口(负载均衡服务的接口)，监测服务不再需要解决寻找边缘节点路由的问题，从而实现监测系统的高可用性。139.本实施例中，监测服务包含负载均衡服务、数据插入服务和存储服务。140.其中，负载均衡服务用于接收边缘节点推送的监测数据，并根据各个数据插入服务的pod的负载情况，择优选择数据插入服务，将当前接收到的监测数据发送给数据插入服务。141.数据插入服务是专门用于写入监测数据的服务，具体用于将监测数据发送至存储服务。142.存储服务是专门用于存储和管理监测数据的服务，能实现监测数据的存储、数据冗余处理、数据压缩等。143.中心节点上运行有至少一个数据插入服务和至少一个存储服务。其中，数据插入服务的数量大于或等于存储服务的数量。144.通过设置较多数量的数据插入服务，多个数据插入服务可以并行地进行监测数据的写入处理，提高监测数据的吞吐量和连接数。145.通过设置多个存储服务，可以提高监测数据的存储效率和存储容灾性。146.可选地，根据实时负载情况，可以动态地扩展数据插入服务的数量和/或存储服务的数量。147.示例性地，本实施例提供的监测方案的架构如图6所示，以监测服务为prometheus实例为例，监测服务拆分成了负载均衡服务(如图6中所示的lb)、数据插入服务(如图6中所示的prometheusinsert)和存储服务(如图6中所示的prometheusstore)。边缘节点上的采集agent(如图6中所示的agent)将采集的边缘节点的监测数据推送给负载均衡服务lb。边缘节点本地设置用于存储监测数据metrics的本地存储空间，图6所示的/tmp/metrics-data表示边缘节点上用于存储监测数据metrics的本地存储空间。在断网时采集agent将边缘节点的监测数据缓存到本地存储空间，在网络恢复后(网通时)从本地存储空间读取边缘节点的监测数据，重新向负载均衡服务推送。148.步骤s207、通过负载均衡服务，根据负载均衡策略，将边缘节点监测数据发送给数据插入服务，并向边缘节点反馈响应消息。149.在接收到监测数据之后，负载均衡服务根据负载均衡策略，将边缘节点监测数据发送给数据插入服务。150.其中，负载均衡策略中设置了如何跟数据插入服务的pod的负载情况，择优选择数据插入服务进行监测数据的写入处理的规则，具体可以根据实际应用场景的需要进行设置和调整，此处不做具体限定。151.在将边缘节点监测数据发送给数据插入服务之后，向边缘节点的采集agent反馈响应消息，以通知采集agent监测数据推送成功。152.步骤s208、通过数据插入服务，将边缘节点的监测数据发送给存储服务。153.数据插入服务接收到边缘节点的监测数据后，将边缘节点的监测数据发送给存储服务，实现监测数据写入处理。154.步骤s209、通过存储服务存储边缘节点的监测数据。155.存储服务将接收到的边缘节点的监测数据进行存储，实现监测数据的存储。156.示例性地，本实施例提供的kubernetes边缘集群的数据监测方法的一种示例架构与数据链路如图7所示，中心节点与边缘节点的控制面流量依然通过tunnel隧道实现，本实施例中，中心节点上部署监测系统及监测系统对边缘节点提供的统一的负载均衡服务(如图7中的lb)，每一边缘节点上部署采集agent，边缘节点还部署有node-exporter，采集agent通过本地网络从node-exporter采集边缘节点的监测数据，通过push方式推送给负载均衡服务(lb)，负载均衡服务(lb)在将边缘节点的监测数据发送至监测系统实现监测数据的存储。另外，边缘节点本地还设置有用于存储监测数据metrics的本地存储空间(如图7所示的/tmp/metrics-data为监测数据的存储路径)。在断网时采集agent将边缘节点的监测数据缓存到本地存储空间，在网络恢复后(网通时)从本地存储空间读取边缘节点的监测数据，重新向负载均衡服务推送。如图7中所示，本实施例提供的kubernetes边缘集群的数据监测方法，管控使用的tunnel链路和监测数据上报的push链路分离，分离了监测数据采集流量和控制面流量，并且控制面流量用下行带宽，监测数据采集流量用上行带宽，使用不同的tcp连接，彻底地将监测数据采集流量从下行通道中剥离出来，保证控制命令通道不会被影响。157.本实施例中，通过将监测服务拆分为负载均衡服务、数据插入服务和存储服务，将整个监测流程拆分为采集、插入、存储、查询等多个模块，对于采集来说，只需要负载均衡服务(lb)代理好插入模块(比如nodeport方式loadbalancer方式的kubernetesservice)，采集agent连接lb即可，这样，监测数据采用push的方式走上行通道，由于在边缘方案中只有下行的流量才需要tunnelserver做路由边缘节点的路由，这样监测服务不再要求部署在tunnelserver所在节点，无需将监测服务与tunnelserver强绑定到同一节点，解耦监测服务的横向扩展和tunnel隧道路由解析实例的横向扩展，能够实现弹性扩缩容，提高监测服务的灵活性。158.图8为本技术一实施例提供的kubernetes边缘集群的数据监测装置的结构示意图。本技术实施例提供的kubernetes边缘集群的数据监测装置可以执行kubernetes边缘集群的数据监测方法实施例提供的处理流程。本技术实施例提供的kubernetes边缘集群的数据监测装置应用于kubernetes边缘集群中的边缘节点，边缘节点上运行有采集代理。如图8所示，kubernetes边缘集群的数据监测装置80包括：数据采集模块801。159.具体地，数据采集模块801，用于通过采集代理执行如下数据采集处理：160.挂载采集配置信息，采集配置信息包括监测数据的数据格式、访问监测数据提供服务所需的访问配置信息、推送指标数据的目标地址信息；根据监测数据的数据格式和访问配置信息，在本地主机网络内访问监测数据提供服务，从监测数据提供服务获取边缘节点的监测数据；根据目标地址信息，向中心节点推送边缘节点的监测数据。161.可选地，边缘节点上运行的监测数据提供服务包括node-exporter服务、kubelet服务和cadvisor服务。162.数据采集模块还用于：163.通过采集代理在本地主机网络内访问node-exporter服务，从node-exporter服务获取边缘节点的第一指标数据，第一指标数据为节点级的监测数据；通过采集代理在本地主机网络内访问kubelet服务，从kubelet服务获取边缘节点上运行的pod的第二指标数据，第二指标数据为pod级的监测数据；通过采集代理在本地主机网络内访问cadvisor服务，从cadvisor服务获取边缘节点上容器的第三指标数据，第三指标数据为容器级的监测数据。164.可选地，数据采集模块还用于：165.根据kubernetes边缘集群中接口服务器所使用的kubelet证书生成kubelet证书文件；通过采集代理挂载kubelet证书文件。166.可选地，数据采集模块还用于：167.获取边缘节点的节点名称；根据目标地址信息，向中心节点推送边缘节点的监测数据和节点名称。168.可选地，数据采集模块还用于：169.根据目标地址信息，向中心节点推送边缘节点的监测数据之后，若确定边缘节点的监测数据推送失败，则在本地存储空间存储边缘节点的监测数据；根据重新推送规则，重新推送边缘节点的监测数据，其中，随着边缘节点的监测数据的推送次数的增加，重新推送边缘节点的监测数据的间隔时间增长。170.可选地，数据采集模块还用于：171.若本地存储空间中存储的数据量大于或等于存储上限，则根据边缘节点的监测数据的时间信息，删除本地存储空间中的部分数据。172.本技术实施例提供的装置可以具体用于执行上述任一方法实施例中边缘节点所执行的处理流程，具体功能和所能实现的技术效果此处不再赘述。173.图9为本技术另一实施例提供的kubernetes边缘集群的数据监测装置的结构示意图。本技术实施例提供的kubernetes边缘集群的数据监测装置，可以执行kubernetes边缘集群的数据监测方法实施例提供的处理流程。本技术实施例提供的kubernetes边缘集群的数据监测装置应用于kubernetes边缘集群中的中心节点，中心节点上运行有负载均衡服务。如图9所示，kubernetes边缘集群的数据监测装置90包括：数据接收模块901和数据存储模块902。174.具体地，数据接收模块901，用于通过负载均衡服务接收边缘节点推送的边缘节点的监测数据。175.数据存储模块902，用于存储边缘节点的监测数据。176.可选地，中心节点上运行有至少一个数据插入服务和至少一个存储服务。177.数据存储模块还用于：178.通过负载均衡服务，根据负载均衡策略，将边缘节点监测数据发送给数据插入服务，并向边缘节点反馈响应消息；通过数据插入服务，将边缘节点的监测数据发送给存储服务；通过存储服务存储边缘节点的监测数据。179.本技术实施例提供的装置可以具体用于执行上述任一方法实施例中中心节点所执行的处理流程，具体功能和所能实现的技术效果此处不再赘述。180.本技术还提供一种电子设备，包括：处理器，以及与处理器通信连接的存储器，存储器存储计算机执行指令。其中，处理器执行存储器存储的计算机执行指令，以实现上述任一方法实施例中边缘节点所执行的处理流程，具体功能和所能实现的技术效果此处不再赘述。181.本技术还提供一种电子设备，包括：处理器，以及与处理器通信连接的存储器，存储器存储计算机执行指令。其中，处理器执行存储器存储的计算机执行指令，以实现上述任一方法实施例中中心节点所执行的处理流程，具体功能和所能实现的技术效果此处不再赘述。182.本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现上述任一方法实施例中边缘节点或者中心节点所执行的处理流程。183.本技术实施例还提供了一种计算机程序产品，程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一方法实施例中边缘节点或者中心节点所执行的处理流程。184.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。185.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。186.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。187.上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施例方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。188.本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。189.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本
技术领域：
：中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由下面的权利要求书指出。190.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。当前第1页12当前第1页12