具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

在云原生时代，企业为了改善企业数据中心的应用访问和用户体验，使用基于Kubernetes平台来部署和管理容器化应用，Kubernetes平台可以将物理服务器或者虚拟机作为节点纳入平台进行管理，将容器化应用部署在平台中的某个节点上之后，Kubernetes平台能够自动根据节点的情况对部署其上的应用进行调度。

容器裸金属服务器作为一种不同于“虚拟化服务器”的新型服务器，通过去除“虚拟化服务器”中的虚拟化平台和虚拟机，在物理服务器上直接运行容器，避免了虚拟化技术带来的性能损失和虚拟机相互干扰等问题，而且能够满足性能需求与减少运维成本。

但将容器裸金属服务器作为Kubernetes平台的节点投入使用，也带来了新的问题，随着容器裸金属服务器的普及，如何保证运行其上的应用不会因为容器裸金属服务器在物理上出现毁损灭失，而遭受毁灭性打击，成为一个重要问题。Kubernetes平台只能通过节点上的Kubelet组件来监测节点的运行状态，在外部物理环境出现问题之初，不能及时地发现异常，做出应对，造成容器裸金属服务器的硬件性能受到影响，甚至是受到物理损坏，使得应用的性能、数据受损。

举例来说，当容器裸金属服务器所在的机房空调因为某种不可预知的原因失效了，容器裸金属服务器的外部物理环境的温度将逐渐升高，但Kubernetes平台无法对节点外部物理环境进行监测，也不会做出相应的应对措施。

当温度升高至一定数值，容器裸金属服务器的散热受到影响，将自动降频来减少热量，从而影响容器裸金属服务器和部署其上的应用的性能，同时在高温环境下持续运行也会影响容器裸金属服务器的使用寿命。

此外，机房温度升高的原因不仅可能是由于空调失效，也可能是由于机房失火，一旦机房失火，将导致容器裸金属服务器在物理上毁损灭失，运行在其上的应用将遭受毁灭性打击。

为了解决上述问题，申请人提出了一种容器裸金属服务器的物理环境风险的应对方法。在本申请实施例中，容器裸金属服务器作为云原生平台的工作节点，即第一节点，其上部署云原生应用对外提供服务。

图1为根据本申请的一些实施例提供的一种容器裸金属服务器的物理环境风险的应对方法的流程示意图；如图1所示，该容器裸金属服务器的物理环境风险的应对方法包括：

步骤S101、代理应用采集并汇总容器裸金属服务器的物理环境信息，以得到监控指标数据。其中，代理应用部署于容器裸金属服务器上。

目前的云原生平台(比如，Kubernetes集群)是通过心跳机制来判断加入集群的每个节点的健康状态，具体通过节点上的Kubelet周期(10秒性)性的向控制节点同步工作节点的状态信息，Kubernetes编排引擎周期(5秒)性的检查节点的Kubelet同步过来的状态信息，如果在一定的时间范围(40秒)内某个节点没有同步状态信息过来，控制节点则认为该节点处于不可用状态。这种节点状态监测方法只能通过工作节点上的Kubelet组件监测节点上的容器组的运行状态，在外部物理环境出现问题之初，不能及时发现异常，进而做出相应的应对措施。使得容器裸金属服务器的硬件性能因外部物理环境出现危险而受到影响甚至物理损坏，容器裸金属服务器上部署的应用的性能、数据受损。

在一些可选实施例中，在代理应用采集并汇总容器裸金属服务器的物理环境信息，以得到监控指标数据时，通过设置在容器裸金属服务器上的传感器周期性地采集容器裸金属服务器的物理环境信息，并发送给代理应用；代理应用接收到传感器采集的物理信息后，汇总为监控指标数据。

在本申请实施例中，通过在容器裸金属服务器上设置多种传感器，对容器裸金属服务器周围的物理环境信息进行采集，并转换成相应的传感器信息发送给代理应用。

在本申请实施例中，在云原生平台中的所有容器裸金属服务器上以容器化形式部署代理(Agent)应用，由Agent应用负责通过硬件信息采集工具(比如：redifish、impitool)接收节点上的传感器发送的传感器信息、装置信息，并汇总为监控指标数据(metrics)。

在一具体的例子中，传感器包括温度检测传感器、烟雾检测传感器和图像传感器中的至少一种，对应的，监控指标数据包括温度数据、烟雾数据和图像数据中的至少一种。

在本申请实施例中，通过容器裸金属服务器上设置的物理传感器，对容器裸金属服务器所处的物理环境的温度、烟雾浓度等参数进行监测，以及，对容器裸金属服务器周围环境进行固定位置的长期图像监测，将持续采集的画面进行差值运算，如果差值超过预设范围，则说明存在异常亮光。籍此，实现从多个不同的维度对容器裸金属服务器的物理环境进行监测判断，有效避免对容器裸金属服务器所处物理环境的误判，提高对容器裸金属服务器的应对准确性。

步骤S102、监控告警模块根据代理应用发出的监控指标数据确定警告类型。

在本申请实施例中，监控告警模块根据监控指标数据对容器裸金属服务器的物理环境进行判断，确定警告类型。在一些可选实施例中，监控告警模块包括监控单元和告警单元，监控单元和告警单元分别以容器化形式部署在云原生平台的第二节点上，监控单元根据预设的风险类型判定规则对监控指标数据进行分析，确定物理环境风险的类型，并生成对应的警告；告警单元将不同类型的警告发送给不同的应用。

应当理解，监控单元应当根据预设的风险类型判定规则，对代理应用多次发出的监控指标数据进行分析后，确定物理环境风险的类型，以防监控指标数据有误。

比如说，当metrics中包括的温度数据升高，说明可能是机房空调故障，也可能是周围环境出现异常热源；当metrics中包括的烟雾浓度升高，则说明周围环境中存在大量烟雾，可能有人在机房抽烟，也可能是周围环境起火；当metrics中包括的图像数据中存在异常亮光，则说明周围环境存在异常光源，可能是周围环境起火。

当出现这些状况时，首先可以确定容器裸金属服务器的物理环境出现了异常情况，需要立即通知机房维护人员。监控单元生成异常警告，由告警单元将异常警告发送给通知应用，通过短信、电话、邮件、警报等各种方式通知机房维护人员。其次，监控单元还可以通过对metrics进行综合分析，确定风险的类型。

如果温度数据持续升高至预设温度阈值，烟雾浓度持续升高至预设浓度阈值，且周围环境中存在异常亮光，那么监控单元可以确定物理环境风险的类型为火灾，属于高危风险，需要将运行在容器裸金属服务器上的应用调度至云原生平台上的健康节点上，监控单元在确定风险类型为高危风险后，生成物理环境高危警告，由告警单元将物理环境高危警告发送给控制应用(Controller应用)，由Controller应用将运行在容器裸金属服务器上的应用调度至云原生平台上的健康节点上。

如果仅仅是温度数据持续升高，容器裸金属服务器的性能会因为外界温度升高而受影响，那么监控单元可以判定为轻微风险，应当拒绝云原生平台继续将新的应用部署至容器裸金属服务器上，监控单元在确定风险类型为轻微风险后，生成物理环境轻微警告，由告警单元将物理环境轻微警告发送给拒绝应用，由拒绝应用拒绝云原生平台继续将新的应用部署至容器裸金属服务器上。

如果仅仅是烟雾浓度持续升高，那么监控单元可以将风险类型确定为中度风险，并生成物理环境中度警告，监控单元在确定风险类型为中度风险后，生成物理环境中度警告，由告警单元将物理环境中度警告发送给告警应用，由告警应用拒绝云原生平台继续将新的应用部署至容器裸金属服务器上，并立即通知所在建筑物的负责人员。

在一具体的例子中，如图2、图3所示，监控单元采用Prometheus系统对监控指标数据进行分析，确定物理环境风险的类型；对应的，代理应用采用Prometheus Exporter采集并汇总容器裸金属服务器的物理环境信息，以得到监控指标数据；告警单元采用AlertManager模块将不同类型的警告发送给不同的应用。

在本申请实施例中，在云原生平台的控制节点或者告警节点(不同于控制节点和第一节点的其它任一节点)上以容器化形式部署Prometheus系统、AlertManager模块以及控制(Controller)应用，其中，Controller应用以Deployment方式部署。Prometheus系统通过第一节点中的代理(Agent)应用的Prometheus exporter来获取metrics，并基于metrics来判断是否需要发出警告，如果需要发出警告，则将警告传输给AlertManager模块，由AlertManager模块根据警告的类型，将警告发个不同的Controller应用。

具体的，容器裸金属服务器上设置的多种传感器将周期性地(比如每隔10秒)采集周围物理环境信息，Prometheus系统周期性地获取对应的metrics，在判断是否需要发出警告时，Prometheus系统对多次获取的metrics进行分析后，确定是否需要发出警告，以防误报。

在另一具体的例子中，如图4、图5所示，监控单元采用zabbix系统的zabbixserver组件对监控指标数据进行分析，确定物理环境风险的类型；对应的，代理应用采用zabbix系统的zabbix agent组件采集并汇总容器裸金属服务器的物理环境信息，以得到监控指标数据。

在本申请实施例中，在云原生平台的控制节点或者告警节点上以容器化形式部署zabbix server组件、告警脚本和Controller应用。zabbix server组件通过第一节点中的Agent应用的zabbix agent组件来获取metrics，并基于metrics来判断是否需要发出警告，如果需要发出警告，则将警告传输给告警脚本，由告警脚本根据警告的类型，将警告发给不同的应用。

在另一具体的例子中，如图6、图7所示，监控单元采用open-falcon系统的Judge组件对监控指标数据进行分析，确定物理环境风险的类型；对应的，代理应用采用falcon-agent组件采集并汇总容器裸金属服务器的物理环境信息，以得到监控指标数据。

在本申请实施例中，在云原生平台的控制节点或者告警节点上以容器化形式部署Judge组件、Alarm组件和Controller应用。Judge组件通过第一节点中的Agent应用的falcon-agent组件来获取metrics，并基于metrics来判断是否需要发出警告，如果需要发出警告，则将警告传输给Alarm组件，由Alarm组件根据警告的类型，将警告发个不同的应用。

步骤S103、响应于监控告警模块发出的物理环境高危警告，控制应用将容器裸金属服务器标记为不可用。

其中，监控告警模块和控制应用(Controller应用)均部署于云原生平台的第二节点上。

在本申请实施例中，监控告警模块发出的物理环境高危警告，说明周围物理环境已经对容器裸金属服务器造成严重威胁，此时，Controller应用将容器裸金属服务器标记为不可用。

具体的，如图8所示，响应于监控告警模块发出物理环境高危警告，控制应用(Controller应用)访问云原生平台的API-Server，以将容器裸金属服务器标记为不可用。

然后，控制应用(Controller应用)通过云原生平台的API-Server访问ETCD，以获取容器裸金属服务器上的全部容器组。具体的，Controller应用通过API-Server访问云原生平台中控制节点上的ETCD，获取ETCD中记录的部署于容器裸金属服务器上的容器组列表。

其中，容器裸金属服务器上的容器组列表中包括守护进程容器组(DaemonSet管理的容器组)、镜像容器组(Mirror Pod)和应用容器组中至少一种。镜像容器组和守护进程容器组在每个节点上均有部署，用于运行所在节点的核心组件应用和守护进程，维持节点的基本运行，本申请中的Agent应用也部署在守护进程容器组中。节点被标记为不可用，不会影响镜像容器组和守护进程容器组在节点的部署。

最后，控制应用(Controller应用)在容器裸金属服务器上删除应用容器组。具体的，控制应用(Controller应用)通过云原生平台的API-Server控制容器裸金属服务器上的Kubelet组件，删除应用容器组。

在本申请实施例中，Controller应用滤除容器组列表中的镜像容器组和守护进程容器组，并通过控制节点中的API-Server控制第一节点中Kubelet组件，按照容器组列表中滤除镜像容器组和守护进程容器组后剩余的容器组将容器裸金属服务器上的应用容器组按序删除。

步骤S104、云原生平台将容器裸金属服务器中的容器组调度至云原生平台的健康节点。

目前，在云原生平台中，通过云原生平台的编排引擎通过节点选择器(NodeSelector)或者节点亲和性(NodeAffinity)实现节点的调度和管理。比如，在Kubernetes集群中，Kubernetes平台自动获知加入集群的每个节点的健康状态，并自动为每个节点打上相应标签；在某一个节点在一段时间没有进行上报后，Kubernetes平台将为该节点打上标签，将该节点标记为NotReady(不可用)的状态；将原本运行在该节点上的容器组，依据之前同步在Kubernetes平台上ETCD中的信息在健康节点上重新启动，一旦与失联的节点取得联系，则立即通知其删除已在其他节点上重新启动的容器组。当Kubernetes的调度机制通过现有的节点调度方法，将完全损坏的节点上的容器组调度到健康节点上时，在将完全损坏的节点上的容器组在健康节点上重新启动这段时间内，部署于该容器组中的应用的正常功能将受到巨大的影响，甚至无法使用。因而，无法确保部署在容器裸金属服务器上的云原生应用的可靠性。

在本申请实施例中，在Controller应用将容器裸金属服务器上的应用容器组按序删除后，由云原生平台将容器裸金属服务器中的应用容器组调度至云原生平台的健康节点。籍此，确保应用能够时刻正常运行，容器裸金属服务器始终提供高性能的服务，将周围物理环境的影响降到最低。

在一些可选实施例中，在云原生平台将容器裸金属服务器中的容器组调度至云原生平台的健康节点之后，监控告警模块根据代理应用发出的监控指标数据确定警告解除；响应于监控告警模块发出的物理环境危险解除信息，控制应用(Controller应用)去除容器裸金属服务器上的不可用标记。

在本身申请实施例中，容器裸金属服务器上设置的传感器采集容器裸金属服务器的物理环境信息，并由代理应用汇总为监控指标数据，当监控告警模块根据实时的监控指标数据确定警告解除时，发出物理环境危险解除信息，并由控制节点上的Controller应用去除容器裸金属服务器上的不可用标记。

比如，当容器裸金属服务器周围物理环境恢复正常后，Prometheus系统基于容器裸金属服务器上设置的传感器采集、汇总的metrics，确定容器裸金属服务器的周围物理环境恢复正常，则通过AlertManager模块、Controller应用、API-Server，去除容器裸金属服务器的不可用标记，允许Kubernetes集群在容器裸金属服务器上部署新的应用。

在本申请实施例中，应用包括Controller应用和通知/告警应用；Controller应用主要用于对容器裸金属服务器进行标记和/或调度；通知/告警应用用于根据容器裸金属服务器的周围物理环境的危险程度通知不同的相关人员。比如，在周围物理环境出现异常情况时，通知机房维护人员，以及在周围物理环境出现中度及以上风险时，通知级别更高的相关负责人员。

在本申请实施例中，容器裸金属服务器还可以与周围物理环境的报警系统进行关联，比如与机房所在大楼的火警系统进行关联，在机房所在大楼出现火警时，立即将容器裸金属服务器上运行的应用调度到健康节点。此外，还可以与当地与地质灾害预警中心、地震预警中心进行关联。

在本申请实施例中，同一个机房中可以部署多个容器裸金属服务器，可以将同一个机房中的全部容器裸金属服务器编为一个小组。在对周围物理环境进行检测时，可以将同一个小组中的容器裸金属服务器上的传感器所采集的传感器信息作为一组metrics，由监控告警模块对一组metrics进行综合分析，甚至可以将容器裸金属服务器在机房中的部署位置作为监控告警模块进行数据分析的参数，以提高对周围物理环境的判定准确度。在对周围物理环境进行判定时，当确定周围物理环境将对容器裸金属服务器造成严重威胁时，将整个小组中的容器裸金属服务器集体标记为不可用。

基于本申请实施例提供的容器裸金属服务器的物理环境风险的应对方法，使得云原生平台能够实时感知容器裸金属服务器的外部物理环境，并在外部物理环境中的危险即将发生或已经发生时通过预设的途径通知相关人员，及时处理问题；当发现外部物理环境中出现可能对容器裸金属服务器造成严重损伤的危险时，及时将处于危险物理环境中的容器裸金属服务器上部署的应用调度到健康节点上，确保应用能够在云原生平台上安全、正常地对外提供服务。

图9为根据本申请的一些实施例提供的一种容器裸金属服务器的物理环境风险的应对系统的结构示意图；如图9所示，该容器裸金属服务器的物理环境风险的应对系统包括：采集单元901、监控单元902、标记单元903和调度单元904。采集单元901配置为代理应用采集并汇总所述容器裸金属服务器的物理环境信息，以得到监控指标数据；其中，所述代理应用部署于所述容器裸金属服务器上；监控单元902配置为监控告警模块根据所述代理应用发出的所述监控指标数据确定警告类型；标记单元903配置为响应于所述监控告警模块发出的物理环境高危警告，控制应用(Controller应用)将所述容器裸金属服务器标记为不可用；其中，所述监控告警模块和所述控制应用(Controller应用)部署于所述云原生平台的第二节点上；调度单元904配置为所述云原生平台将所述容器裸金属服务器中的容器组调度至所述云原生平台的健康节点。

本申请实施例提供的容器裸金属服务器的物理环境风险的应对系统能够实现上述任一容器裸金属服务器的物理环境风险的应对方法实施例的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

本申请实施例还提供一种容器裸金属服务器，应用于上述任一容器裸金属服务器的物理环境风险的应对方法，所述容器裸金属服务器上部署有代理应用，所述容器裸金属服务器还包括：传感器所述传感器设置在所述容器裸金属服务器上，用于对所述容器裸金属服务器的物理环境信息进行监测，并发送给所述代理应用，以由所述代理应用将所述物理环境信息汇总为监控指标数据。

本申请实施例提供的容器裸金属服务器应用于上述任一容器裸金属服务器的物理环境风险的应对方法时，能够实现上述任一容器裸金属服务器的物理环境风险的应对方法的步骤、流程，并达到相应的技术效果，在此不再一一赘述。

以上所述仅为本申请的优选实施例，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。