应用诊断辅助方法、计算设备及机器可读存储介质与流程

1.本公开涉及云计算技术，特别涉及针对基于容器及kubernetes平台的应用进行辅助诊断的应用诊断辅助方法、计算设备及机器可读存储介质。


背景技术：

2.随着互联网技术的快速发展，云计算越来越成为重要的发展方向。
3.云计算中涉及的服务包括基础设施即服务（iaas）、平台即服务（paas）和软件即服务（saas）三个层次的服务。
4.平台即服务（paas）是云计算的重要组成部分，提供运算平台与解决方案服务。在云计算的典型层级中，paas层介于软件即服务（saas）与基础设施即服务（iaas）之间。
5.paas平台是一种云计算平台，可用于简化和自动化整个应用程序生命周期管理，包括开发、部署和运行，降低it基础设施支出，减少应用开发和运维成本及时间。
6.kubernetes（简称“k8s”）是一种容器集群管理系统，是可自动实施linux容器操作的开源平台，使用其可运行和管理多个容器。
7.用户使用paas/k8s这种云原生应用调度平台时，需要创建或者变更应用。例如，在k8s集群上部署或者更新无状态负载（deployment）、服务（service）、数据卷（volume）等资源，然后在k8s管理的机器节点上创建容器以满足这些资源。
8.不同于本机运行的程序，在k8s中运行的应用出现错误时，用户难以诊断。这是因为可能出现问题的层次分布在进程、操作系统（os）、容器、k8s平台等多个层面。
9.现有的k8s资源观测工具如kubewatch可以侦听指定k8s资源的状况。当出现资源事件时，kubewatch会发送通知。kubewatch注重资源的变化，但是对应用的资源结构没有感知，对应用的状态也没有感知，无法主动记录应用变更时的资源状态。
10.换言之，在现有技术中，会对平台上各种资源的资源信息进行扫描，获知各个资源的状况。而这样的资源状况信息收集是为平台服务商服务的，便于平台服务商了解自己所拥有或掌握的各种资源的状况。而这些资源分别服务于大量不同的应用。对于用户的单个应用而言，则难以分析错误或异常的原因，难以对问题定位，即难以进行诊断。
11.另一种现有的k8s诊断工具kubectl debug通过复制原有pod、增加容器或者改变命令的方式来进行调试，但是没有办法完成容器启动前和启动后的诊断，能做到的调试手段也仅限于原容器镜像自带的工具。
12.因此，仍然需要一种针对基于容器及k8s平台的应用（可以称为“云原生应用”）的多层次诊断辅助方案，以便于收集在应用变更期间从用户进程到k8s各个层次的信息，提高用户定位问题的效率。


技术实现要素：

13.本公开要解决的一个技术问题是针对基于容器及k8s平台的应用，提供一种多层次的诊断辅助方案，其能够收集从进程到k8s各个层次在应用变更期间的信息，从而提高后
期定位问题的效率。
14.根据本公开的第一个方面，提供了一种应用诊断辅助方法，用于针对基于容器及k8s平台的应用进行辅助诊断，该方法包括：基于针对应用配置的资源树定义，生成应用所使用的资源的资源树，资源树包括以树的形式组织的多个资源节点，多个资源节点分别对应于应用所使用的多个资源；在应用变更期间，基于资源树获取各资源节点对应资源的诊断信息，其中，诊断信息是有助于进行诊断的信息；以及存储所获取的各资源节点对应资源的诊断信息。
15.可选地，在应用变更期间基于资源树获取各资源节点对应资源的诊断信息的步骤包括：响应于根资源的创建或更新，在应用创建或更新结束之前，遍历该应用所对应的资源树至少一次，以获取资源树上各个资源节点对应资源的诊断信息。
16.可选地，遍历该应用所对应的资源树的步骤包括：将根资源节点放入队列；从队列中获取资源节点，获取资源节点对应资源的诊断信息；以及如果资源节点具有子资源节点，则将子资源节点放入队列。
17.可选地，资源的诊断信息包括下述至少一项：资源的元信息；资源的配置信息；资源的状态信息；事件信息，用于描述资源的各种变化信息；资源的描述信息。
18.可选地，每次遍历结束后，执行上述存储所获取的各资源节点对应资源的诊断信息的步骤。其中，对于本轮次遍历中新出现的资源节点，将其对应的诊断信息全部保存；对于先前轮次遍历中存在且本轮次遍历中仍然存在的资源节点，保存新的元信息、配置、状态和/或描述信息，而将新旧事件信息聚合在一起以体现资源在整个变更周期中的变化；对于先前轮次遍历中存在而本轮次遍历中消失的资源节点，保存有关资源节点已消失的信息。
19.可选地，该方法还可以包括：响应于从资源的诊断信息中检测到异常工作负载资源，查询异常工作负载资源的资源信息；复制异常工作负载资源所涉及的容器组，得到复制容器组；以及对复制容器组进行修改，以得到便于容器组诊断器进行诊断信息收集的诊断容器组；由容器组诊断器对诊断容器组中的容器进行诊断信息收集，以获取该容器的诊断信息。
20.可选地，对复制容器组进行修改的步骤包括：在复制容器组中的容器的启动命令的基础上，加入运行前暂停程序和/或运行后暂停程序；在复制容器组的容器中添加与运行前暂停程序和/或运行后暂停程序关联的辅助程序，从而得到用于诊断的诊断容器组。
21.可选地，由容器组诊断器对诊断容器组中的容器进行诊断信息收集的步骤包括：对诊断容器组中的容器进行运行前诊断信息收集、运行跟踪诊断信息收集以及运行后诊断信息收集中的至少一项。
22.可选地，容器组诊断器通过调用诊断插件来对容器进行诊断信息收集，诊断插件包括下述至少一项：系统调用插件，用于获取容器执行过程中所有发生的系统调用和事件，从操作系统层观测应用变更失败的原因；日志收集插件，用于获取容器执行输出的日志，以避免容器删除后日志丢失的情形发生；执行跟踪插件，用于跟踪用户态程序的执行，以从应用层观测失败的原因；资源收集插件，用于收集容器启动中的cpu、内存、网络、io和文件中至少一项的信息，以辅助对问题进行定位；核心转储插件，用于基于程序异常退出时生成的核心转储，获取程序处于异常时的现场信息，以用于对故障进行定位；自定义插件，用于执行用户自定义的容器诊断功能。
23.可选地，容器组诊断器在容器运行前时机点设置运行前钩子，将容器运行前需要调用执行的诊断插件注册到运行前钩子，在诊断容器组中的容器启动后，先执行运行前暂停程序，进入运行前暂停状态，调用执行运行前钩子上注册的诊断插件，收集第一诊断信息，当所有运行前钩子上注册的诊断插件被调用执行完成后，容器组诊断器终止运行前暂停程序，自动执行原容器启动命令；并且/或者容器组诊断器在容器运行期间，调用执行跟踪插件启动后台程序来跟踪容器的执行，以收集第二诊断信息；并且/或者容器组诊断器在容器运行后时机点设置运行后钩子，将容器运行后需要调用执行的诊断插件注册到运行后钩子，当诊断容器组中的所有容器运行结束或因运行时间超出辅助诊断时间而被容器组诊断器关闭，执行运行后暂停程序，进入运行后暂停状态，调用执行运行后钩子上注册的诊断插件，收集进程遗留的信息，以获取第三诊断信息，当所有运行后钩子上注册的诊断插件被调用执行完成后，容器组诊断器终止运行后暂停程序，结束对容器进行的诊断信息收集流程。
24.可选地，将诊断容器组和容器组诊断器部署在同一个机器节点上；并且/或者将诊断容器组和容器组诊断器部署在异常负载原来部署的节点上；并且/或者选择具有充足资源以承载诊断容器组和容器组诊断器的节点，并将诊断容器组和容器组诊断器部署在所选择的节点上。
25.根据本公开的第二个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第一方面所述的方法。
26.根据本公开的第三个方面，提供了一种计算机程序产品，包括可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如上述第一方面所述的方法。
27.根据本公开的第四个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第一方面所述的方法。
28.由此，针对基于容器及k8s平台的应用，提供了一种多层次的诊断辅助方案，能够收集从用户进程到k8s各个层次在应用变更期间的信息，提高了用户定位问题的效率。
附图说明
29.通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。
30.图1是根据本公开在基于容器及k8s平台的应用发生变更时对其进行辅助诊断的系统整体架构图。
31.图2是根据本公开对基于容器及k8s平台的应用进行辅助诊断的方法的示意性流程图。
32.图3是根据本公开对k8s资源进行辅助诊断的示意性架构图。
33.图4示意性地示出了一种示例性应用资源树。
34.图5示例性地示出了可以针对各个资源通过访问api服务器收集整理的诊断信息。
35.图6是pod诊断器对出现异常的工作负载架构图。
36.图7是pod诊断过程的示意性流程图。
37.图8示出了根据本发明一实施例可用于实现上述应用诊断辅助方法的计算设备的结构示意图。
具体实施方式
38.下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
39.本公开提出了一种针对基于容器及k8s平台的应用进行辅助诊断的应用诊断辅助方法。通过辅助诊断，获取相应的有助于进行诊断的诊断信息。用户可以基于所获取的诊断信息进行诊断分析，在存在异常或问题的情况下，对异常或问题所在进行方便快捷的分析和定位。
40.在一些实施例中，本公开的“辅助诊断”也可以理解为“诊断信息收集”。应用诊断工作人员，例如用户、k8s平台服务商、或其他经授权的第三方，可以基于根据本公开的应用诊断辅助方法所获取的诊断信息，方便地进行诊断分析，例如对所存在的异常或问题进行分析和定位。
41.即，根据本公开，可以通过对诊断信息的收集，来对用户等应用诊断工作人员的诊断工作提供辅助，提高用户进行诊断分析（如问题定位）的效率和准确性。
42.下文中提到的“k8s资源诊断控制器”、“pod诊断控制器”以及“pod诊断器”等，也可以分别理解为“k8s资源辅助诊断控制器”、“pod辅助诊断控制器”以及“pod辅助诊断器”，属于诊断辅助控制工具或诊断辅助工具。
43.首先，参考图1简要描述根据这本公开针对基于容器及k8s平台的应用在其变更期间对其进行辅助诊断的系统整体架构图。
44.图1是根据本公开在基于容器及k8s平台的应用发生变更时对其进行辅助诊断的系统整体架构图。
45.如图1所示，整个系统架构包括kubernetes（k8s）集群和存储系统。
46.kubernetes集群是运行应用、诊断控制器和诊断器的平台。本公开的应用诊断辅助方案可以完全基于kubernetes来实现。
47.存储系统则提供对应用诊断信息的存储方案，包括数据库、日志存储和文件存储等。
48.kubernetes集群可以包括控制面和若干机器节点。
49.控制面包括api服务器（api server）以及k8s集群中负责在应用变更期间进行辅助诊断的诊断控制器。
50.api服务器（api server）是kubernetes的一种服务端组件，通过它可以访问和操作kubernetes集群内部的数据。
51.api服务器维护着集群上各类原生资源信息和自定义资源信息，如应用配置（applicationconfiguration）、镜像构建（imagebuilder）、日志采集（logcollector）、无状态负载（deployment）、服务（service）、容器组（pod）等。这些资源信息保存了用户创建或者
变更应用的信息。诊断控制器可以根据这些资源信息来对应用进行诊断信息收集。
52.其中，容器组（pod）是kubernetes的容器沙箱，可以运行多个容器，是集群中实际的工作负载单元。
53.无状态负载（deployment）是kubernetes中pod的封装，可以指定pod的数量，并保证该数量的pod正在运行。
54.如图1所述，本技术的控制面包括两方面的诊断控制器，即k8s资源诊断控制器和pod诊断控制器。
55.paas平台上部署的应用会涉及到多个k8s资源。这些k8s资源可以组织成一个资源树。k8s资源诊断控制器可以跟踪应用在变更期间的资源信息，定时查询整个资源树的信息，当应用到达终态后，将资源信息会持久化存储到存储系统的例如数据库中。
56.pod诊断控制器则根据异常负载信息创建诊断任务（job），并在诊断完成后释放诊断任务占用的资源。这里，job是kubernetes中pod的封装，用于运行一定数量的pod到成功退出状态。
57.机器节点是k8s集群中实际运行容器的机器，负责运行应用容器和诊断器容器。
58.诊断器容器中运行pod诊断器，负责复制异常的pod重新运行，对异常pod中的容器进行诊断信息收集，完成后进行持久化存储。
59.下面，结合图1简要描述本公开的应用诊断辅助方案。
60.首先，在步骤a1，获取应用k8s资源信息。
61.k8s资源诊断控制器可以从api服务器获取应用所涉及的所有资源的相关资源信息，并整理出利于用户进行诊断的信息。
62.在步骤a2，生成应用资源树信息。
63.本公开提出，可以将所获取到的应用资源信息组织成一个资源树。资源树可以包括以树的形式组织的多个资源节点。多个资源节点分别对应于应用所使用的多个资源。
64.每个资源（节点）可以有对应的子资源（节点）和父资源（节点）。根资源（节点）没有父资源（节点）。末端资源（节点）则没有子资源（节点）。
65.控制器可以在应用变更期间跟踪应用的资源信息，定时查询整个资源树的信息，并将这些资源信息持久化存储到数据库，用于后续查询。下文中将对此进行详细描述。
66.对于一般资源，资源相关的信息较为容易分析。当出现异常时，可以直接通过分析从资源信息整理出的诊断信息即可实现对问题的定位。
67.而对于工作负载，情况则要复杂一些。当工作负载出现异常时，可以进行进一步的分析处理，收集更进一步的诊断信息，以便于后期更好地进行诊断分析，实现对问题更好的定位。
68.这样，在步骤a3，可以向pod诊断控制器提交异常工作负载。
69.具体说来，如果k8s资源诊断控制器从资源信息中检测到处于异常的工作负载，如pod（容器组）、deployment（无状态负载）和replicaset（副本集）等，则将这个工作负载的相关信息提交给pod诊断控制器。
70.于是，在步骤a4，pod诊断控制器从k8s资源诊断控制器获取异常工作负载信息。
71.pod诊断控制器可以根据异常工作负载信息，向api服务器查询该异常工作负载的具体信息，以便后续在对该异常工作负载进行诊断信息收集时，生成用于诊断的工作负载
（如诊断容器组）。
72.在步骤a5，pod诊断控制器控制诊断任务（job），诊断任务用来进行关于诊断信息的信息收集。
73.pod诊断控制器在机器节点上创建诊断任务，并控制诊断任务的运行。
74.另外，当诊断任务运行完成后，pod诊断控制器还会对用于进行诊断信息收集的诊断任务和容器组（pod）进行清理。
75.在步骤a6，对容器进行诊断信息收集。
76.机器节点上的pod诊断器会复制异常的pod，并对所复制的pod进行侵入，增加生命周期跟踪，以对其中的容器进行诊断信息收集。
77.然后，在步骤a7，存储容器诊断信息。
78.这里，在诊断完成后，pod诊断器可以在存储系统中将容器的诊断信息存储为日志或者文件，以便提供给用户。
79.上文中参考图1简要描述了根据本公开的应用变更期间诊断辅助方案的整体架构和大致流程。
80.如图1所示，根据本公开的应用诊断辅助方案整体架构主要涉及两方面诊断：（1）k8s资源诊断控制器的k8s资源诊断信息收集；（2）pod诊断控制器和pod诊断器的pod诊断信息收集。
81.如上文所述，第(2)方面是在第(1)方面对k8s资源进行诊断信息收集的基础上，在检测到处于异常k8s资源为工作负载资源，如pod（容器组）、deployment（无状态负载）和replicaset（副本集）等的情况下，为便于对异常工作负载进行进一步的诊断信息收集而提出的。
82.下面，对这两方面分别进行详细描述。
83.一、k8s资源诊断信息收集。
84.首先，参考图2简要描述根据本公开对基于容器及k8s平台的应用的进行辅助诊断的方法。
85.图2是根据本公开对基于容器及k8s平台的应用进行辅助诊断的方法的示意性流程图。
86.如图2所示，首先在步骤s210，基于针对应用配置的资源树定义，生成应用所使用的资源的资源树。
87.资源树可以包括以树的形式组织的多个资源节点。这些资源节点分别对应于应用所使用的多个资源。资源树中，子资源节点从属于父资源节点。
88.这样，在步骤s220，可以在应用变更期间，基于资源树获取各节点对应资源的诊断信息。
89.应当理解，“诊断信息”是指有助于进行诊断的信息。对于各种资源，可以收集相应的有助于进行诊断的信息，应用诊断工作人员（如用户等）基于这些诊断信息可以发现异常，定位问题。下文中将参考图5描述资源的诊断信息的示例。但是应当理解，诊断信息不限于此。可以针对各种资源和各种诊断任务设定相应需要收集的诊断信息。
90.然后，在步骤s230，可以存储步骤s220所获取的各资源节点对应资源的诊断信息，作为该应用的诊断信息。
91.资源的诊断信息例如可以以列表的形式存储。一个应用的诊断信息例如可以存储为一个文件或一个表。
92.下面，参考图3进一步详细描述根据本公开对基于容器及k8s平台的应用的k8s资源进行辅助诊断的示例性方法。
93.图3是根据本公开对k8s资源进行辅助诊断的示意性架构图。
94.如图3所示，在步骤b1，k8s资源诊断控制器获取资源树定义，解析并获取应用相关资源信息。
95.在k8s资源诊断控制器启动时，需要提供应用相关的k8s资源树的定义。k8s资源诊断控制器可以根据所配置的资源树来查询应用变更期间的应用资源状况。
96.本公开的应用资源树可以表示任意资源结构和类型。通过指定资源树的定义，控制器可以动态解析树的结构。
97.下面参考图4详细描述一下根据本公开的应用资源树。
98.资源树的结构可以不受控制器的限制。而且，资源树还可以按实际状况更新。
99.图4示意性地示出了一种示例性应用资源树。
100.如图4所示，每个资源（或称为“资源节点”）可以有0到多个子资源节点。
101.图4中，applicationconfiguration（应用配置/应用）是根资源节点，代表某一个应用。其它子资源节点分别负责维护应用的各个功能。
102.例如，如图4所示，applicationconfiguration（应用配置/应用）的子资源节点可以有rollout（部署）、servicetrait（slb/服务）、imagebuilder（镜像构建）、logcollector（日志采集）、dynamiclabel（动态标）、autoscaling（弹性伸缩）等。
103.rollout（部署）的子资源节点可以有deployment（无状态负载）。deployment（无状态负载）的子资源节点可以有replicaset（副本集）。replicaset（副本集）的的子资源节点可以有pod（容器组）。
104.servicetrait（slb/服务）的子资源节点可以有service（服务）。
105.logcollector（日志采集）的子资源节点可以有aliyunlogconfig（sls配置）。
106.autoscaling（弹性伸缩）的子资源节点可以有scaledobject（keda弹性资源）。scaledobject（keda弹性资源）的子资源节点可以有hpa（水平弹性伸缩）。
107.该资源树可以使用yaml（一种数据序列化语言）进行定义。
108.如果一个资源节点有子资源节点，则可以将该资源节点定义为yaml对象。如果有多个子资源节点，可以用yaml数组表示。如果只有单个子资源，则可以用yaml对象表示。
109.如果某个资源节点没有子资源节点，则可以使用字符串表示。
110.按照该规则，对yaml配置进行增删改，可以任意定义满足各种复合需求的资源树。
111.图4所示示例性资源树对应的yaml定义可以如下：resourcetree:
ꢀꢀꢀꢀ
applicationconfiguration:
ꢀꢀꢀꢀꢀꢀꢀꢀ‑ꢀ
rollout:
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
deployment:
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
replicaset: pod
ꢀꢀꢀꢀꢀꢀꢀꢀ‑ꢀ
servicetrait: service
ꢀꢀꢀꢀꢀꢀꢀꢀ‑ꢀ
imagebuilder
ꢀꢀꢀꢀꢀꢀꢀꢀ‑ꢀ
logcollector: aliyunlogconfig
ꢀꢀꢀꢀꢀꢀꢀꢀ‑ꢀ
dynamiclabel
ꢀꢀꢀꢀꢀꢀꢀꢀ‑ꢀ
autoscaling:
ꢀꢀꢀꢀꢀꢀꢀꢀ
scaledobject: hpa应当理解，这里给出的仅是一种示例性yaml定义。
112.这样，k8s资源诊断控制器在启动时会读取资源树的yaml配置，使用递归的方式将其解析成对应的k8s资源树。由此，在上述步骤s210，基于针对应用配置的资源树定义，生成应用所使用的资源的资源树。
113.资源节点可以保存k8s资源的具体类型、从属于该资源节点的子资源节点以及该资源节点所从属的父资源节点。通过当前资源节点的子资源节点可以向下遍历资源树。通过父资源节点可以判断当前资源节点是否属于子资源节点。
114.资源节点可以代表任意k8s资源类型。而且，资源树可以任意定义。
115.资源节点的定义可以如下例：type resourcenode struct {
ꢀꢀꢀꢀꢀ
gvk
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
schema.groupversionkind
ꢀꢀꢀꢀꢀ
parent
ꢀꢀꢀ
*resourcenode
ꢀꢀꢀꢀꢀ
children []*resourcenode}应当理解，这里给出的仅是一种示例性资源节点定义。
[0116]
下面，继续参考图3进一步描述根据本公开的应用跟踪方案。参考图3，详细描述在图2的步骤s220，在应用变更期间，可以如何通过对应用的变更过程进行跟踪，来基于资源树收集整理各节点对应资源的诊断信息。
[0117]
集群中会存在多个发生变更的应用。对于每个应用，k8s资源诊断控制器需要单独跟踪资源状况的变化。
[0118]
如图3所示，本公开可以采用并发的方式，同时对变更中的多个（甚至所有）应用（应用a、应用b）进行跟踪。
[0119]
在图3的步骤b2，获取根资源的变化，并且响应于根资源发生变化，对根资源对应的应用进行跟踪。
[0120]
根资源出现变化表示应用可能出现变更。
[0121]
此时，可以判断所出现的变化是属于资源创建、资源更新还是资源删除。
[0122]
当根资源的变化属于资源删除时，该根资源对应的应用不复存在了，也就不会再出错，因此可以不再对其进行诊断了。
[0123]
而当根资源的变化属于资源创建或者资源更新时，说明这是应用的创建或更新，需要对其进行变更期间的诊断操作。
[0124]
由此，响应于根资源的创建或更新，可以在应用创建或更新结束之前，遍历应用对应的资源树至少一次，以获取资源树上各个资源节点对应资源的诊断信息。
[0125]
例如，可以将新创建或发生更新的根资源对应的应用放入待跟踪应用队列中。
[0126]
k8s资源诊断控制器可以从待跟踪应用队列中获取待跟踪的变更应用。
[0127]
例如，可以检查该应用是否已被跟踪。如果已被跟踪，则可以将其忽略。如果还未被跟踪，则可以启动协程，开始对该应用进行循环跟踪。
[0128]
每个处于变更中的应用有一个对应的协程进行跟踪，控制器会记录正在跟踪的协程，当应用到达终态后控制器会取消对应用的跟踪，当应用再次出现变更时会重新跟踪。
[0129]
应用相关的资源信息存储在api服务器中。因此，在图3的步骤b3，控制器可以从api服务器中获取资源信息。
[0130]
在图3的步骤b4，在应用变更过程中，应用到达终态（也即变更结束，应用不再发生变化）之前，也即在应用创建或更新结束之前，对该应用对应的资源树遍历至少一次。例如，可以周期性地，每隔一段时间，对资源树遍历一次。
[0131]
例如，可以使用广度优先遍历方案。对每个变更期间的应用，k8s资源诊断控制器可以从资源树的根资源开始使用广度优先遍历方案进行搜索，对于每一个资源节点，从api服务器查询出其对应资源的状况（例如可以称为“资源信息”），并将其整理为便于诊断的形式，得到对应资源的诊断信息。例如，可以从冗杂繁多的资源信息中抽取进行诊断需要的信息，并将所抽取的信息按设定的格式或形式，整理为对应资源的诊断信息。
[0132]
下面，详细描述遍历应用资源树的示例性方案。
[0133]
首先，可以将根资源放入队列。
[0134]
于是，可以每次从队列中获取资源节点，获取资源节点对应资源的诊断信息。例如，可以从api服务器获取该资源节点对应资源的资源信息，并进行整理得到诊断信息。
[0135]
然后，如果该资源节点具有子资源节点，则将子资源节点加入队列。
[0136]
由此循环，直到队列为空，也即所有资源节点都被遍历到了。
[0137]
图5示例性地示出了可以针对各个资源通过访问api服务器收集整理的诊断信息。
[0138]
如图5所示，对于资源如deployment（无状态负载），收集整理的资源的诊断信息可以包括下述至少一项：（1）资源的元信息（metadata），例如包括资源名称、标签（lable）、创建时间等信息；（2）资源的配置信息（spec），例如资源的预期配置等；（3）资源的状态信息（status），表明资源的当前状态，包含是否已经到达终态等信息；（4）事件信息，记录资源相关的事件，包括信息（info）级别事件和警告（warning）级别事件；（5）资源的描述信息（describeinfo）。
[0139]
其中，资源的元信息、配置信息和状态信息属于资源的基础信息。
[0140]
资源的事件信息描述了资源的各种变化信息。k8s中的事件存活1个小时，每次只能获取到最近1小时的事件。
[0141]
资源的描述信息可以与使用kubectl describe获取的信息一致，其可以采用更便于用户阅读的形式。其中，kubectl是kubernetes的命令行客户端。
[0142]
k8s资源诊断控制器可以对每个资源收集整理这些诊断信息。这些信息可以帮助用户快速判断资源是否健康，并对所存在的问题进行定位。
[0143]
然后，在图3的步骤b5，当应用变更到达终态（变更结束，不再继续变更）后，k8s资
源诊断控制器可以对最新的（变更后的，终态的）应用涉及各资源的诊断信息进行存储。
[0144]
由此，可以将应用涉及各资源的诊断信息进行更新。
[0145]
可以在每次对资源树进行遍历结束后，存储所获取的各资源节点对应资源的诊断信息。例如，可以将获得的资源的诊断信息序列化为json格式，存储到例如kubernetes configmap中。
[0146]
如果是第一次遍历，可以直接创建存储项目。否则，可以对先前记录的内容进行更新。更新时可以进行如下操作中的一项或多项：（1）对于本轮次遍历中新出现的资源节点，将其对应资源的诊断信息全部保存；（2）对于先前轮次遍历中存在且本轮次遍历中仍然存在的资源节点，保存新的元信息、配置、状态和/或描述信息，而将新旧事件信息聚合在一起以体现资源在整个变更周期中的变化；（3）对于先前轮次遍历中存在而本轮次遍历中消失的资源节点，保存有关资源节点已消失的信息。
[0147]
至此，已详细描述了根据本公开针对基于容器及k8s平台的应用在变更期间对k8s资源进行辅助诊断的方案。
[0148]
对于如图4所示的资源树中，服务（service）、日志采集（logcollector）、镜像构建（imagebuilder）、动态标（dynamiclabel）等资源而言，从api服务器收集并整理上述诊断信息往往已经足够进行资源诊断和问题定位。
[0149]
而对于无状态负载（deployment），也即工作负载而言，能够通过相应资源的诊断信息判断工作负载出现异常，但是也有可能还需要更进一步的分析，以获取更具体的信息。
[0150]
下面参考图6详细描述根据本公开的pod诊断信息收集。
[0151]
二、pod诊断信息收集。
[0152]
图1中主要通过pod（容器组）诊断控制器和pod（容器组）诊断器两部分来执行pod诊断信息收集。
[0153]
首先，简要描述pod诊断控制器。pod诊断控制器的操作可以有如下几个方面。
[0154]
第一，获取异常工作负载信息。
[0155]
pod诊断控制器从k8s资源诊断控制器获取工作负载异常的信息（图1中的步骤a3），创建pod诊断器对工作负载进行诊断信息收集（或“辅助诊断”）（图1中的步骤a4），维护pod诊断器的状态（图1中的步骤a5）。
[0156]
在收到工作负载异常的信息后，pod诊断控制器从api服务器获取异常工作负载。例如，可以从api服务器查询异常工作负载的名称、命名空间和所在节点等信息，以用于诊断。
[0157]
第二，创建pod诊断器。
[0158]
基于所获取的信息，pod诊断控制器可以创建pod诊断器。
[0159]
可以在有充足资源以承载容器组诊断任务的机器节点上部署pod诊断器。这样，可以避免资源不足无法进行辅助诊断。
[0160]
或者，也可以在异常负载原来部署的机器节点上部署pod诊断器。这样，可以避免拉取镜像消耗的时间。
[0161]
如果异常负载原来部署的节点正好具有充足的资源以承载容器组诊断任务，则同
时可以避免上述两方面问题。
[0162]
可以使用kubernetes任务（job）的形式来进行部署，需要指定部署的节点。
[0163]
可以令pod诊断器和被诊断pod（诊断容器组或诊断pod）在同一各机器节点上，使用根命名空间，使得pod诊断器可以访问被诊断pod的进程，同时配置容器进程权限，让诊断容器可以对容器进程进行侦听和控制。
[0164]
第三，维护pod诊断器状态。
[0165]
pod诊断控制器还可以用于维护pod诊断器状态。
[0166]
pod诊断控制器可以检查诊断器job的状态。当诊断器job到达成功状态（诊断成功）后，pod诊断控制器可以删除诊断器job和可能残留的诊断pod。当诊断器job到达失败状态（诊断失败）时，可以记录该次失败pod诊断的信息。
[0167]
下面，参考图6和图7进一步详细描述根据本公开的pod诊断辅助方案。
[0168]
图6是pod诊断器对出现异常的工作负载架构图。
[0169]
图7是pod诊断过程的示意性流程图。
[0170]
pod诊断器首先通过入侵pod（图6中的c2.1），创建专门用于诊断的诊断pod，然后由pod诊断器对诊断pod进行诊断信息收集。
[0171]
首先，在步骤s710，响应于从资源的诊断信息中检测到异常工作负载资源，pod诊断器查询异常工作负载资源的资源信息。
[0172]
pod诊断器需要获取异常pod的定义，包括配置信息、pod信息、容器信息等资源信息，以便在步骤s720复制出一个用于诊断的pod，并在步骤s730修改得到便于pod诊断器进行诊断信息收集的诊断pod，从而在步骤s740启动对异常pod的诊断信息收集。
[0173]
在此分别对这些资源信息进行说明如下。
[0174]
c1.1配置信息配置信息包括例如工作负载信息、节点信息、容器运行时、诊断插件等。
[0175]
(1)工作负载：要指定目标工作负载的类型和名称，包括pod定义的类型如deployment、job和pod本身都支持。结合工作负载的类型和名称，可以定位具体的资源。
[0176]
(2)节点信息：指定用于进行诊断信息收集的节点，诊断工具和异常工作负载可以在同一个节点上运行。
[0177]
(3)容器运行时：容器运行时有containerd和docker，它们的api有区别，使用诊断工具需要指定具体的运行时，以用于查询容器信息。其中，docker等虚拟化技术用来运行的虚拟化环境。
[0178]
(4)诊断插件：指定诊断需要启动的插件，可以根据场景启用部分插件。关于诊断插件，将在后文中进一步说明。
[0179]
c1.2pod信息获取异常pod的定义，可以用于复制一个新的pod用于侵入和诊断。后文中将对异常pod的复制进行更详细的描述。
[0180]
c1.3容器信息
基于容器信息，可以获取容器镜像的启动命令，用于封装原有的启动命令，加入暂停进程；获取容器的进程id信息，提供给诊断插件用于跟踪指定容器进程。后文中将对启动命令的封装、诊断插件的提供等内容进行更详细的描述。
[0181]
然后，在s720，复制异常工作负载资源所涉及的pod，得到复制pod。
[0182]
这里，可以拉取异常pod里指定的镜像，以便复制异常pod。
[0183]
镜像里含有默认的启动命令，当pod定义里没有指定启动命令时会使用镜像自带的命令。
[0184]
然后，在步骤s730，也即图6中的c2.2，对复制pod进行修改，以得到便于pod诊断器进行诊断信息收集的诊断pod。
[0185]
对复制pod的修改可以包括下述两方面。
[0186]
一个方面是包装启动命令，即在复制pod的容器的原有启动命令的基础上，加入运行前暂停程序和/或运行后暂停程序。
[0187]
包装逻辑可以如下：假设应用原启动命令为cmd，则包装为bash
ꢀ‑
c "pause; cmd; pause"，在原命令前后加入暂停程序。其中使用了bash依次运行程序的功能，下面是一个具体例子：// 1. 应用启动命令/bin/bash /home/admin/start.sh// 2. 包装后的启动命令bash
ꢀ‑
c "pause; /bin/bash start.sh; pause"应当理解，这里给出的仅是一种示例性的命令包装方案。
[0188]
另一个方面是添加辅助程序，即在复制pod的容器中添加与运行前暂停程序和/或运行后暂停程序关联的辅助程序。
[0189]
例如，如上所述，包装启动命令需要pause暂停程序和bash脚本解释器。
[0190]
这些程序在异常pod的容器中不存在。因此，需要通过kubernets volume（数据卷）的方式引入。pod诊断器会在pod定义里加上辅助程序volume（数据卷）。
[0191]
其中，bash是一种命令行解释器，可以执行程序。volume（数据卷）是kubernetes中的存储资源，可以在pod内的所有容器进行共享。
[0192]
通过以上基于异常pod的定义，对复制pod进行侵入后，额外创建了一个专门用于诊断的pod，可以称为“诊断pod”。
[0193]
然后，可以在步骤s740，由pod诊断器对诊断pod中的容器进行诊断信息收集，以获取该容器的诊断信息。
[0194]
pod诊断器对诊断pod中的容器进行运行前诊断信息收集、运行跟踪诊断信息收集以及运行后诊断信息收集中的至少一项。
[0195]
通过执行运行前诊断信息收集、运行跟踪诊断信息收集和运行后诊断信息收集，可以对容器进行全生命周期诊断信息收集。
[0196]
下面进一步描述对容器进行的全生命周期诊断（图6中的c3）。
[0197]
使用包装后的启动命令，可以在容器运行前和运行后暂停。pod诊断器利用暂停提供运行前后时机点的钩子点，并提供容器的名称，镜像和进程等信息。诊断插件在这些钩子点上定义钩子函数，利用pod诊断控制器提供的容器信息完成全生命周期的诊断信息收集。
[0198]
下面分别描述运行前诊断信息收集、运行跟踪诊断信息收集和运行后诊断信息收集。
[0199]
操作c3.1，运行前诊断信息收集。
[0200]
pod诊断器在容器运行前时机点设置运行前钩子，将容器运行前需要调用执行的诊断插件注册到运行前钩子。
[0201]
在诊断容器组中的容器启动后，先执行运行前暂停程序，进入运行前暂停状态。
[0202]
于是，可以调用执行运行前钩子上注册的诊断插件，收集第一诊断信息（也可以称为“运行前诊断信息”）。
[0203]
诊断插件可以将运行前需要的操作注册到运行前钩子上，如系统调用插件在此时动态附着到容器进程中。
[0204]
当所有运行前钩子注册的诊断插件被调用执行完成后，pod诊断器会终止运行前暂停进程，bash会自动执行原应用启动命令。
[0205]
操作c3.2，运行跟踪诊断信息收集。
[0206]
pod诊断器在容器运行期间，调用执行跟踪插件可以启动后台程序跟踪应用的执行，以收集第二诊断信息（也可以称为“运行中诊断信息”）。
[0207]
操作c3.3，运行后诊断信息收集。
[0208]
pod诊断器在容器运行后时机点设置运行后钩子，将容器运行后需要调用执行的诊断插件注册到运行后钩子。
[0209]
pod诊断器会一直侦听应用/容器的运行，当超出预订的辅助诊断时间，诊断器会将应用/容器进程关闭，进入运行后诊断阶段，或者所有应用/容器结束，也会自动进入运行后诊断信息收集阶段。
[0210]
这样，当诊断pod中的所有容器运行结束或因运行时间超出辅助诊断时间而被容器组诊断器关闭，pod诊断器执行运行后暂停程序，进入运行后暂停状态。
[0211]
当到达这个阶段，pod诊断器会运行运行后钩子，调用执行运行后钩子上注册的诊断插件，收集进程遗留的信息，以获取第三诊断信息（也可以称为“运行后诊断信息”）。
[0212]
当所有运行后钩子上注册的诊断插件被调用执行完成后，pod诊断器会终止运行后暂停进程，结束整个诊断流程。
[0213]
这样，前述容器的诊断信息可以包括第一诊断信息（运行前诊断信息）、第二诊断信息（运行中诊断信息）以及第三诊断信息（运行后诊断信息）。而如此获取的容器的诊断信息也可以作为前述应用的诊断信息的一部分进行存储。
[0214]
如上文所提到，pod诊断器可以通过调用诊断插件来对容器进行诊断信息收集。
[0215]
这里，pod诊断器采用插件形式来定义诊断功能，可以按配置启动特定插件，每种插件负责一种诊断功能，相应收集一个方面的诊断信息。
[0216]
在图6中，作为示例，示出了下述六种诊断插件（c4）。
[0217]
1.系统调用插件：用于获取容器执行过程中所有发生的系统调用和事件，从操作系统（os）层观测应用变更失败的原因。
[0218]
2.日志收集插件：用于获取容器执行输出的日志，可以避免容器删除后日志丢失的情形发生。
[0219]
3.执行跟踪插件：用于例如使用ebpf来跟踪用户态程序的执行，从应用层观测失
败的原因。ebpf是一种可以在操作系统内核中运行沙箱程序，在不需要改变源码的情况下使得内核可编程化。
[0220]
4.资源收集插件：用于收集容器启动中的cpu、内存、网络、io和文件信息，以辅助对问题进行定位。
[0221]
5.核心转储（coredump）插件：用于基于程序异常退出时生成的核心转储，获取程序处于异常时的现场信息，以用于对故障进行定位，二进制程序异常退出会生成coredump，java程序异常退出也会产生coredump，这些信息保留了程序处于异常时的现场，可以用于定位故障。
[0222]
6.自定义插件：用于执行用户自定义的容器诊断功能，用户可以自定义任意容器诊断插件，而本公开的pod诊断器可以支持横向插件拓展。
[0223]
当诊断器完成对pod的诊断后，诊断器会将这些插件获得的应用诊断信息持久化到日志或者文件存储里（图6中的c5），供用户查询辅助诊断。
[0224]
至此，已详细描述了根据本公开的应用诊断辅助方法。
[0225]
在本公开的实施例中，使用资源树来定义应用所涉及的所有k8s资源，并且支持任意树状结构，可以获取变更期间应用所有的相关资源的诊断信息。可以感知应用的资源树和状态，收集变更期间应用所有相关资源的诊断信息并将其存储。
[0226]
通过采用资源树，本公开实施例的应用诊断辅助方法支持对进程、操作系统、容器、k8s等多个层面进行诊断信息收集，获取应用在多层次的统一诊断信息。
[0227]
另外，在进一步的实施例中，通过更改容器的启动命令，可以使容器的启动退出暂停，从而能够完成对容器全生命周期的诊断信息收集。而且，可以做到容器启动前和退出后的诊断信息收集，避免容器快速退出或者丢失现场。
[0228]
另外，对容器的诊断辅助手段不受限于镜像自带的工具，本公开还可以采用插件形式，可以自由拓展诊断组件，也可以选择性地启用部分插件。
[0229]
图8示出了根据本发明一实施例可用于实现上述应用诊断辅助方法的计算设备的结构示意图。
[0230]
参见图8，计算设备800包括存储器810和处理器820。
[0231]
处理器820可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器820可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器（gpu）、数字信号处理器（dsp）等等。在一些实施例中，处理器820可以使用定制的电路实现，例如特定用途集成电路（asic，application specific integrated circuit）或者现场可编程逻辑门阵列（fpga，field programmable gate arrays）。
[0232]
存储器810可以包括各种类型的存储单元，例如系统内存、只读存储器（rom），和永久存储装置。其中，rom可以存储处理器820或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置（例如磁或光盘、闪存）作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备（例如软盘、光驱）。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器810可以包括任意计算机可读存储媒介的组合，
包括各种类型的半导体存储芯片（dram，sram，sdram，闪存，可编程只读存储器），磁盘和/或光盘也可以采用。在一些实施方式中，存储器810可以包括可读和/或写的可移除的存储设备，例如激光唱片（cd）、只读数字多功能光盘（例如dvd
‑
rom，双层dvd
‑
rom）、只读蓝光光盘、超密度光盘、闪存卡（例如sd卡、min sd卡、micro
‑
sd卡等等）、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。
[0233]
存储器810上存储有可执行代码，当可执行代码被处理器820处理时，可以使处理器820执行上文述及的应用诊断辅助方法。
[0234]
上文中已经参考附图详细描述了根据本发明的应用诊断辅助方法。
[0235]
此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。
[0236]
或者，本发明还可以实施为一种非暂时性机器可读存储介质（或计算机可读存储介质、或机器可读存储介质），其上存储有可执行代码（或计算机程序、或计算机指令代码），当所述可执行代码（或计算机程序、或计算机指令代码）被电子设备（或计算设备、服务器等）的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。
[0237]
本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。
[0238]
附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
[0239]
以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。