CN112416737B - 一种容器的测试方法、装置、设备和存储介质 - Google Patents
一种容器的测试方法、装置、设备和存储介质 Download PDFInfo
- Publication number
- CN112416737B CN112416737B CN201910774958.9A CN201910774958A CN112416737B CN 112416737 B CN112416737 B CN 112416737B CN 201910774958 A CN201910774958 A CN 201910774958A CN 112416737 B CN112416737 B CN 112416737B
- Authority
- CN
- China
- Prior art keywords
- container
- debugging
- service
- debug
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012360 testing method Methods 0.000 title abstract description 5
- 238000000034 method Methods 0.000 claims abstract description 75
- 230000004048 modification Effects 0.000 claims abstract description 4
- 238000012986 modification Methods 0.000 claims abstract description 4
- 238000004891 communication Methods 0.000 claims description 28
- 230000015654 memory Effects 0.000 claims description 24
- 230000004044 response Effects 0.000 claims description 8
- 238000012544 monitoring process Methods 0.000 claims description 5
- 238000004458 analytical method Methods 0.000 claims description 2
- 238000011161 development Methods 0.000 abstract description 7
- 239000008186 active pharmaceutical agent Substances 0.000 description 48
- 238000007726 management method Methods 0.000 description 23
- 230000008569 process Effects 0.000 description 20
- 238000010586 diagram Methods 0.000 description 12
- 239000003795 chemical substances by application Substances 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 238000001824 photoionisation detection Methods 0.000 description 7
- 230000003068 static effect Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000013475 authorization Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 241001522296 Erithacus rubecula Species 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012550 audit Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000008602 contraction Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000009545 invasion Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3644—Software debugging by instrumenting at runtime
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明实施例公开了一种容器的测试方法、装置、设备和存储介质。该方法通过接收客户端发送的、针对业务容器的调试请求；响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；将所述运行信息发送至所述客户端，以实现避免对业务相关的容器镜像进行修改，减少开发人员的开发时间，增加容器镜像运行的稳定性，提高容器镜像的分发效率。
Description
技术领域
本发明实施例涉及虚拟容器的计算机技术，尤其涉及一种容器的测试方法、装置、设备和存储介质。
背景技术
容器技术作为一种虚拟化技术，已经成为一种被大家广泛认可的服务器资源共享方式。容器技术可以在按需构建容器技术操作系统实例的过程当中为系统管理员提供极大的灵活性。
一般的，在使用容器技术构建处理业务的后台服务器时，容易由于第三方提供的容器镜像不稳定，而造成后台服务器运行出错的问题，严重影响业务的处理。
现有的，可以通过以下几种方式，对容器镜像的运行进行调试，以保证业务的正常进行。
1、查看运行日志
对于docker容器而言，可以通过查看日志的命令(如，docker logs)观察容器的运行日志。但是，有时容器中运行的业务相关的程序仅从日志很难查明问题。
2、使用命令行工具
采用侵入的方式，在业务相关的容器镜像中添加一些基本的调试命令，如sh、bash、netstat、telnet等。但这个解决方案，一方面，会导致最终打出的镜像变大了不少，影响镜像的分发效率；另一方面，对于第三方开发的容器镜像无效，只能是进一步的，为第三方开发的容器镜像重新添加基本的调试命令，增加了开发人员的开发时间，且对容器镜像进行修改，容易减少容器镜像的运行稳定性。
3、更改容器镜像的管理软件的核心代码
Kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效。一般的，K8s设置有Kubctl命令，可以直接的、有效的操作Kubernetes容器集群，从而对集群中运行的镜像进行管理。进一步的，可以采用侵入的方式，对Kubctl命令的核心代码进行修改，使得可以通过Kubctl命令对运行在容器镜像中的、与业务相关的程序进行调试。但是，由于需要修改Kubctl命令的核心代码，容易影响到Kubernetes容器集群运行的稳定性。另外，由于改动范围比较大，也不利于Kubernetes容器集群的软件升级。
发明内容
本发明提供一种容器的测试方法、装置、设备和存储介质，以实现避免对业务相关的容器镜像进行修改，减少开发人员的开发时间，增加容器镜像运行的稳定性，提高容器镜像的分发效率。
第一方面，本发明实施例提供了一种容器的调试方法，该方法包括：
接收客户端发送的、针对业务容器的调试请求；
响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；
依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
将所述运行信息发送至所述客户端。
进一步的，所述接收客户端发送的、针对业务容器的调试请求，包括：
接收从客户端发送的调试请求；
当确定所述调试请求关联有调试服务时，则为所述调试请求分配针对容器的创建权限；
将所述调试请求转发至运行有所述调试服务的调试服务器，所述调试服务用于依据所述创建权限，执行所述响应所述调试请求的步骤。
进一步的，所述响应所述调试请求，在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，包括：
响应所述调试请求，以确定所述业务容器所归属的服务单元，其中，所述服务单元包括各容器的共享资源；
依据从调试请求中解析出的配置信息，修改所述服务单元关联的配置文件；
当检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器。
进一步的，所述在所述服务单元中创建一与所述配置文件匹配的调试容器，包括：
从所述配置文件中解析出镜像信息、资源限制信息；
将基于所述镜像信息所确定的镜像进行实例化，得到运行在所述服务单元的调试容器；
从所述资源限制信息读取所述调试容器的资源上限值；
限制所述调试容器在运行时所占用的资源不高于所述资源上限值。
进一步的，所述依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息，包括：
确定所述业务容器共享在所述服务单元中的命名空间；
在所述命名空间中运行所述调试工具，以从所述命名空间所确定的共享资源中获取所述业务容器的运行信息。
进一步的，所述依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息，还包括：
当所述调试容器在所述服务单元中成功运行时，建立所述调试容器与所述客户端之间的通信连接；
依据所述通信连接，从客户端接收调试指令；
在所述业务容器共享的命名空间中运行与所述调试指令关联的调试工具；
将所述调试工具的运行结果，作为在所述共享资源中获取所述业务容器的运行信息。
进一步的，所述依据所述通信连接，从客户端接收调试指令，包括：
依据所述通信连接，将进入所述调试容器的命令终端发送至客户端；
从所述命令终端接收所述客户端输入的调试指令。。
第二方面，本发明实施例还提供了一种容器的调试方法，该方法包括：
向容器集群发送针对业务容器的调试请求，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
从所述容器集群接收所述运行信息。
第三方面，本发明实施例还提供了一种容器的调试装置，该装置包括：
请求接收模块，用于接收客户端发送的、针对业务容器的调试请求；
请求响应模块，用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；
运行信息获取模块，用于依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
运行信息发送模块，用于将所述运行信息发送至所述客户端。
第四方面，本发明实施例还提供了一种容器的调试装置，该装置包括：
请求发送模块，用于向容器集群发送针对业务容器的调试请求，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
运行信息接收模块，用于从所述容器集群接收所述运行信息。
第五方面，本发明实施例还提供了一种容器的调试设备，包括：存储器以及一个或多个处理器；
所述存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面或第二方面中任一所述的容器的调试方法。
第六方面，本发明实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面或第二方面中任一所述的容器的调试方法。
本发明通过接收客户端发送的、针对业务容器的调试请求；响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；将所述运行信息发送至所述客户端，解决了因采用侵入的方式修改业务相关的容器镜像所带来的容器镜像运行不稳定的问题，以实现避免对业务相关的容器镜像进行修改，减少开发人员的开发时间，增加容器镜像运行的稳定性，提高容器镜像的分发效率。
附图说明
图1为本发明实施例一提供的一种容器的调试方法的流程图；
图2A为本发明实施例二提供的一种容器的调试方法的流程图；
图2B为本发明实施例二提供的一种容器的调试系统的架构图；
图2C为本发明实施例二提供的另一种容器的调试系统的架构图；
图3为本发明实施例三提供的一种容器的调试方法的流程图；
图4为本发明实施例四提供的一种容器的调试方法的流程图；
图5为本发明实施例五提供的一种容器的调试装置的结构示意图；
图6为本发明实施例六提供的一种容器的调试装置的结构示意图；
图7为本发明实施例七提供的一种容器的调试设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1为本发明实施例一提供的一种容器的调试方法的流程图，本实施例可适用于对业务容器进行调试的情况，具体的，应用于采用无侵入性的对业务容器进行调试。该方法可以由容器的调试设备来执行，该容器的调试设备可以是服务器、电脑、移动终端等。
本实施例中，以容器的调试设备为服务器为例进行说明。具体的，该服务器可以是集群服务器或者是独立服务器。进一步的，该服务器还用于运行至少一个容器。
参照图1，该方法具体包括如下步骤：
S110、接收客户端发送的、针对业务容器的调试请求。
本实施例中，业务容器是部署有业务应用的容器，可以部署在容器集群中。客户端可以用于管理业务容器，进一步的，还可以用于进入该业务容器，对该业务容器中的业务应用进行控制。客户端所发送的调试请求，用于建立客户端与业务容器之间的通信连接，并通过该通信连接对业务容器进行调试。
一般的，容器是运行在主机中，并与主机共享资源的独立进程。在容器中，运行应用程序所需的必要组件都打包为单个映像，可重复使用。执行映像时，它在主机的隔离环境中运行，不共享内存、中央处理器(central processing unit，CPU)或主机操作系统所在磁盘空间。这可以保证容器内的进程无法监视容器外的任何进程。将业务应用部署在容器中，可以使得所有业务应用可以直接运行在物理主机的操作系统之上，可以直接读写磁盘，而且应用之间通过计算、存储和网络资源的命名空间进行隔离，为每个应用形成一个逻辑上独立的“容器操作系统”。
进一步的，一旦面对着分布在多台主机上且拥有数百套容器的大规模应用程序时，传统的或单机的容器管理解决方案就会变得力不从心，需要将容器部署于容器集群中。
一般的，集群又称计算机集群，该计算机集群是一组松散或紧密连接在一起工作的计算机。由于这些计算机协同工作，在许多方面它们可以被视为单个系统。与网格计算机不同，计算机集群将每个节点设置为执行相同的任务，由软件控制和调度。
容器集群则是部署有多个容器的计算机集群。在容器集群中的容器或微服务都可以接受管理并有序接入外部环境，从而实现调度、负载均衡以及分配等任务。需要注意的是，在一个容器集群中的容器粒度越来越小、数量越来越多。
此时，简单而高效地管理数量快速增长的容器实例，自然成了一个容器编排系统的主要任务。一般的，可以使用容器集群管理工具，在一组服务器上管理多容器组合成的应用，每个应用集群在容器编排工具看来是一个部署或管理实体，容器集群管理工具全方位为应用集群实现自动化，包括应用实例部署、应用更新、健康检查、弹性伸缩、自动容错等等。
示例性的，该容器集群管理工具可以是Kubernetes，该Kubernetes简称K8s，是一个开源的、用于管理云平台中多个主机上的容器化的应用。
进一步的，本实施例中的客户端可以是容器集群管理工具Kubernetes提供的、是用于针对Kubernetes容器集群运行命令的命令行接口kubectl。
具体的，Kubernetes可以给业务容器分配静态互联网协议地址(InternetProtocol，IP)地址和域名来提供关于部署在业务容器中的业务应用的发现机制。进一步的，用于可以通过在客户端kubectl输入关于发出调试请求的调试指令，以访问业务容器对应的静态IP，并建立客户端kubectl与该静态IP的连接。
S120、响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源。
本实施例中，服务单元(Pod)代表集群上正在运行的一个进程，包含了一个或多个容器。进一步的，服务单元中的共享资源可以包括存储、网络等各个容器共享的资源。
示例性的，在Kubernetes容器集群中，Pod是Kubernetes创建或部署的最小/最简单的基本单位，是Kubernetes的基本调度单元，是Kubernetes容器集群中的一个应用实例，总是部署在同一个节点Node上。Kubernetes中的每个Pod都被分配一个唯一的(在容器集群内的)IP地址，这样就可以允许应用程序使用同一端口，而避免了发生冲突的问题。进一步的，Pod还可以定义一个卷，例如本地磁盘目录或网络磁盘，并将其暴露在Pod中的一个容器之中。
Pod支持多种容器环境，Docker则是最流行的容器环境。
·单容器Pod，最常见的应用方式。
·多容器Pod，对于多容器Pod，Kubernetes会保证所有的容器都在同一台物理主机或虚拟主机中运行。多容器Pod是相对高阶的使用方式，除非应用耦合特别严重，一般不推荐使用这种方式。一个Pod内的容器共享IP地址和端口范围，容器之间可以通过本地主机(localhost)互相访问。
Pod带来的好处：
·Pod作为一个可以独立运行的服务单元，简化了应用部署的难度，以更高的抽象层次为应用部署管提供了极大的方便。
·Pod作为最小的应用实例可以独立运行，因此可以方便的进行部署、水平扩展和收缩、方便进行调度管理与资源的分配。
·Pod中的容器共享相同的数据和网络地址空间，Pod之间也进行了统一的资源管理与分配。
进一步的，容器技术可以通过只将必要的可执行文件和运行库(Bin/Lib)打包进容器镜像中等精简的方式，使得容器满足轻量的特点。进一步的，可以主机可以加载该容器镜像，以运行容器镜像中的Bin/Lib。但这却会给排查问题带来麻烦：精简后的容器中普遍缺失常用的排障工具，部分容器镜像里甚至没有壳层与命令行界面(如，shell)。
由此，本实施例中，调试容器是包括调试工具的容器。该调试工具可以包括用于调试网络、内存、存储等资源的工具。
一方面，调试容器与业务容器运行于同一服务单元中，在无需对业务容器的容器镜像进行修改的前提下，仍然可以保证调试容器可以获取业务容器共享在服务单元中的共享资源，实现无侵入的访问业务容器的效果；另一方面，调试容器与业务容器进行解耦，在需要更新调试工具时，只需要修改调试容器对应的容器镜像即可，不会影响到业务容器的运行，从而保证业务容器中的业务应用正常运行。而且，还可以防止在为业务容器增加调试工具时，使得业务容器对应的容器镜像过大而增加容器分发效率的问题。
S130、依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息。
本实施例中，可以通过确定业务容器共享在服务单元中的命名空间；在命名空间中运行调试工具，以从命名空间所确定的共享资源中获取业务容器的运行信息。
其中，命名空间是Linux内核一个强大的特性。每个容器都有自己单独的命名空间，运行在其中的应用都像是在独立的操作系统中运行一样。命名空间保证了容器之间彼此互不影响。
以下是对各命名空间的介绍。
1、进程(PID)命名空间
不同用户的进程就是通过PID命名空间隔离开的，且不同命名空间中可以有相同PID。所有的LXC进程在Docker中的父进程为Docker进程，每个LXC进程具有不同的命名空间。同时由于允许嵌套，因此可以很方便的实现嵌套的Docker容器。
2、网络(NET)命名空间
有了PID命名空间,每个命名空间中的PID能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过NET命名空间实现的，每个NET命名空间有独立的网络设备,IP地址,路由表,/proc/NET目录。这样每个容器的网络就能隔离开来。Docker默认采用veth的方式，将容器中的虚拟网卡同host上的一个Docker网桥docker0连接在一起。
3、交互方法(IPC)命名空间
容器中进程交互还是采用了Linux常见的进程间交互方法(interprocesscommunication,IPC),包括信号量、消息队列和共享内存等。然而同虚拟机不同的是，容器的进程间交互实际上还是host上具有相同PID命名空间中的进程间交互，因此需要在IPC资源申请时加入命名空间信息，每个IPC资源有一个唯一的32位标是号。
4、挂载(MNT)命名空间
类似chroot，将一个进程放到一个特定的目录执行。MNT命名空间允许不同命名空间的进程看到的文件结构不同，这样每个命名空间中的进程所看到的文件目录就被隔离开了。同chroot不同，每个命名空间中的容器在/proc/mounts的信息只包含所在命名空间的mountpoint。
5、时间共享系统(UTS)命名空间
UTS("UNIX Time-sharing System")命名空间允许每个容器拥有独立的主机名(hostname)和域名(domainname),使其在网络上可以被视作一个独立的节点而非主机上的一个进程。
6、用户(USER)命名空间
每个容器可以有不同的用户和组标识号,也就是说可以在容器内用容器内部的用户执行程序而非主机上的用户。
进一步的，以Kubernetes为例进行说明，KuberNETes不直接运行容器；相反，它将一个或多个容器封装到一个称为Pod的高级结构中。相同Pod中的任何容器都将共享相同的命名空间和本地网络。容器可以很容易地与其他容器在相同的Pod中进行通信，就像它们在同一台机器上同时保持一定程度的隔离。
一共Pod中的各容器的共享资源有：
PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID；
NET命名空间：Pod中的多个容器能够访问同一个IP和端口范围；
IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信；
UTS命名空间：Pod中的多个容器共享一个主机名；
进一步的，还包括Volumes(共享存储卷)：Pod中的各个容器可以访问在Pod级别定义的Volumes。
进一步的，进入业务容器的命名空间，并运行调试工具，以从命名空间所确定的共享资源中获取业务容器的运行信息。如使用网络工具iftop，可以用于查看业务容器的网络流量；使用网络工具drill，可以用于诊断业务容器的DNS解析情况。
S140、将所述运行信息发送至所述客户端。
本实施例中，可以将运行调试工具得到的结果，作为运行信息发送至客户端进行显示。
本实施例的技术方案通过接收客户端发送的、针对业务容器的调试请求；响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；将所述运行信息发送至所述客户端，区别于通过在业务容器中集成调试工具的技术方案，本技术方案通过将包括调试工具的调试容器与业务容器运行于同一服务单元，以使得调试容器可以获取业务容器的共享资源，以在解决了因采用侵入的方式修改业务容器所带来的业务容器运行不稳定的问题，以实现减少开发人员的开发时间，增加业务容器运行的稳定性，保证正常业务的进行。
实施例二
图2A为本发明实施例二提供的一种容器的调试方法的流程图；图2B为本发明实施例二提供的一种容器的调试系统的架构图；图2C为本发明实施例二提供的另一种容器的调试系统的架构图。本实施例在上述实施例的基础上进一步细化，包括增加对该方法所适用的容器的调试系统的架构的描述。
参照图2A，该方法可以应用于容器集群，具体包括如下的步骤：
S210、接收从客户端发送的调试请求。
一般的，容器的调试系统包括客户端、容器集群。其中，容器集群可以使用容器集群管理工具进行管理，客户端可以是容器集群管理工具提供的应用，或者集成有容器集群管理工具提供的接口的应用。
参照图2B，以该容器集群管理工具为Kubernetes为例进行说明。客户端为Kubernetes提供的命令行接口kubectl。
进一步的，Kubernetes遵循主从式架构设计，容器集群中包括集群主机(K8SMaster)和集群节点(Node)。具体的，K8S Master是容器集群的主要控制单元，其用于管理其工作负载并指导整个系统的通信。Kubernetes支持Docker、rkt等容器的运行环境(Runtime)。本实施例中，以容器为在Docker运行环境下的容器为例进行说明。
其中，K8S Master可以包括应用程序接口(Application ProgrammingInterface，API)服务器、键值存储系统(Etcd)等。
1、API服务器
API服务器是一个Kubernetes的关键组件，并使用Kubernetes API和JSON overHTTP来提供了Kubernetes的内部和外部接口。API服务器处理和验证REST请求并更新API对象的状态，从而允许客户端在集群节点之间配置工作负载和容器。API服务器中的组件主要提供认证与授权、运行一组准入控制器以及管理API版本等功能，通过REST API向外提供服务，允许各类组件创建、读取、写入、更新和监视资源(如Pod)。
2、Etcd键值存储系统
Etcd是一种键值存储系统，用于可靠地存储集群的配置数据的一种持久性，轻量型的，分布式的键-值数据存储组件。该组件可表示在任何给定时间点处的集群的整体状态。其他组件在注意到存储的变化之后，会变成相应的状态。
其中，集群节点(Node)也称为Worker或Minion，是部署容器(工作负载)的单机器(或虚拟机)。容器集群中的每个集群节点都必须具备容器的运行环境(Runtime)。集群节点(Node)中包括服务单元Pod和容器守护进程(Docker daemon)等。
1、服务单元(Pod)
Kubernetes的基本调度单元称为“Pod”。通过该种抽象类别可以把更高级别的抽象内容增加到容器化组件。一个Pod一般包含一个或多个容器，这样可以保证它们一直位于主机上，并且可以共享资源。Kubernetes中的每个Pod都被分配一个唯一的(在集群内的)IP地址这样就可以允许应用程序使用同一端口，而避免了发生冲突的问题。Pod可以定义一个卷，例如本地磁盘目录或网络磁盘，并将其暴露在Pod中的一个容器之中。Pod可以通过Kubernetes API手动管理，也可以委托给控制器来实现自动管理。
2、容器守护进程(Docker daemon)
容器守护进程(Docker daemon)是Docker最核心的后台进程，它负责响应来自Docker client的请求，然后将这些请求翻译成系统调用完成容器管理操作。该进程会在后台启动一个API服务,负责接收由Docker client发送的请求；接收到的请求将通过Dockerdaemon内部的一个路由分发调度，再由具体的函数来执行请求。其中，Docker client是一个泛称,用来向指定的Docker daemon发起请求,执行相应的容器管理操作。它既可以是Docker命令行工具，也可以是任何遵循了Docker API的客户端。本实施例中，Dockerclient可以是遵循了Docker API的API服务器。
Kubernetes服务本质是一组协同工作的Pod，类同多层架构应用中的一层。构成服务的Pod组通过标签选择器来定义。Kubernetes通过给服务分配静态IP地址和域名来提供服务发现机制，并且以轮循调度的方式将流量负载均衡到能与选择器匹配的Pod的IP地址的网络连接上(即使是故障导致Pod从一台机器移动到另一台机器)。默认情况下，服务任务会暴露在集群中(例如，多个后端Pod可能被分组成一个服务，前端Pod的请求在它们之间负载平衡)；除此以外，服务任务也可以暴露在集群外部(例如，从客户端访问前端Pod)。
一般的，为了实现对业务容器的调试，可以通过修改Kubernetes的源代码进行实现。
具体的，K8s设置有Kubctl命令，可以直接的、有效的操作Kubernetes容器集群，从而对集群中运行的镜像进行管理。进一步的，可以采用侵入的方式，对Kubctl命令的核心代码进行修改，使得可以通过Kubctl命令对运行在容器镜像中的、与业务相关的程序进行调试。但是，由于需要修改Kubctl命令的核心代码，容易影响到Kubernetes容器集群运行的稳定性。另外，由于改动范围比较大，也不利于Kubernetes容器集群的软件升级。
为此，参照图2C，本实施例中的技术方案相对于图2B所示的架构，增加了调试服务器、调试代理端，以避免对Kubctl命令的核心代码进行修改，保证Kubernetes容器集群运行的稳定性。
具体的，包括增加了客户端、调试服务器、调试代理端的改进。
1、客户端
本实施例中，在客户端Kubctl安装有调试插件，并通过该调试插件提供发送调试请求或调试指令的接口，不涉及到更改客户端Kubctl的核心代码，保证客户端Kubctl运行的稳定性，也减少开发人员的时间。其中，调试请求是用于发起调试任务的请求。调试指令是用于确定执行何种调试任务的指令。
2、调试服务器
调试服务器主要用于提供调试业务容器所涉及的API。
具体的，Kubernetes的汇总(Aggregated)API允许开发人员编写一个自己的服务，并把这个服务注册到API服务器中的API。也就是说，调试服务器中的API可以使用Aggregated API的方式扩展到API服务器中的API。Kubernetes可以通过涉及到调试服务的API的所对应的服务(service)名称，将调试请求或调试指令转发到对应的调试服务器进行处理。
3、调试代理端
调试代理端以守护进程集合(DaemonSet)的形式部署在每个集群节点(K8S Node)上，用于响应调试请求。具体的，调试代理端负责监听针对业务容器所在服务单元(Pod)的调试请求。其中，DaemonSet能够让所有(或者一些特定)的K8S Node运行同一个Pod中。当K8S Node加入到Kubernetes容器集群中，Pod会被DaemonSet调度到该K8S Node上运行。当K8S Node从Kubernetes容器集群中被移除，被DaemonSet调度的Pod会被移除。如果删除DaemonSet，所有跟这个DaemonSet相关的Pods都会被删除。
S220、当确定所述调试请求关联有调试服务时，则为所述调试请求分配针对容器的创建权限；
本实施例中，当API服务器确定调试请求关联有调试服务时，可以为调试请求分配针对容器的创建权限。创建权限可以用于确定发送该调试请求的客户端是否有权限在服务单元中创建调试容器。
具体的，由于调试请求所对应的调试服务是通过Aggregated API进行扩展，API服务器将自动为对该调试请求进行权限校验，并为调试请求分配权限。示例性的，该分配的权限可以是基于角色的访问控制(Role-Based Access Control，RBAC)。其中，RBAC可以使用“rbac.authorization.k8s.io”API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略。
在RBAC API中，一个角色包含了一套表示一组权限的规则。权限以纯粹的累加形式累积(没有“否定”的规则)。角色可以由命名空间(namespace)内的角色(Role)对象定义。一个Role对象只能用于授予对某一单一命名空间中资源的访问权限。以下示例描述了“default”命名空间中的一个Role对象的定义，用于授予对Pod的读访问权限。
进一步的，确定调试请求所针对的业务容器所在的服务单元的命名空间，作为目标命名空间；为发送调试请求的客户端分配目标角色，并为该目标角色授予对该目标命名空间的权限，该权限包括访问权限、针对容器的创建权限。
S230、将所述调试请求转发至运行有所述调试服务的调试服务器。
本实施例中，具体的工作流程可以是客户端通过调试插件将调试请求发送至API服务器，API服务器在确定该调试请求关联有调试服务时，API服务器可以将该调试请求转发至与该调试服务的名称对应的调试服务器进行处理。
进一步的，所述调试服务用于依据所述创建权限，执行步骤S240。
S240、响应所述调试请求，以确定所述业务容器所归属的服务单元，其中，所述服务单元包括各容器的共享资源。
本实施例中，调试服务器运行有调试服务，用于响应该调试请求。具体的，调试请求中包括所针对的业务容器，该调试服务可以从调试请求中解析出所要调试的业务容器所归属的服务单元。
S250、依据从调试请求中解析出的配置信息，修改所述服务单元关联的配置文件。
本实施例中，调试请求中还可以包括配置信息，该配置信息为配置调试容器的信息。每个服务单元关联设置有配置文件，该配置文件包括配置服务单元的信息。进一步的，由于需要在服务单元中创建调试容器，可以将调试容器的配置信息写入服务单元的配置文件中，进而，根据该配置文件对服务单元中的容器资源进行修改。
S260、当检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器。
本实施例中，调试代理端设置有对配置文件的监听，当检测到服务单元的配置发生更新时，可以从配置文件中解析出镜像信息、资源限制信息；将基于镜像信息所确定的镜像进行实例化，得到运行在服务单元的调试容器；从资源限制信息读取调试容器的资源上限值；限制调试容器在运行时所占用的资源不高于资源上限值。
一般的，如果kubelet无法通过节点级别的资源回收获取足够的资源，就会开始驱逐用户的Pod，kubelet会按照下面的标准对Pod的驱逐行为进行判断
·Pod要求的服务质量(BestEffor，Bustable，Guaranteed)
·根据Pod调度请求的被耗尽资源的消耗量
本实施例中，根据资源限制信息对调试容器进行资源的限制，可以确保由于调试容器的资源超限，导致业务容器所在的服务单元遭到驱逐。当服务单元遭到驱逐时，运行在服务单元中的业务容器也会被资源回收，从而导致业务容器的业务应用受到影响。
S270、依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息。
本实施例中，当调试容器在服务单元中成功运行时，建立调试容器与客户端之间的通信连接；依据通信连接，从客户端接收调试指令；在业务容器共享的命名空间中运行与调试指令关联的调试工具；将调试工具的运行结果，作为在共享资源中获取业务容器的运行信息。
其中，该通信连接可以采用SPDY通信协议，该SPDY(读作“SPeeDY”)通信协议是基于传输控制协议(Transmission Control Protocol，TCP)的会话层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。
使用SPDY通信协议建立调试容器与客户端之间的通信连接，可以使得客户端可以通过访问Pod所在的域名，并只需使用一个连接来加载一个节点的所有资源(包括Pod资源、容器资源等)，在这个连接中可以打开多个流来同时传输数据。也就是说，依据该通信连接，可以客户端可以访问多个容器，而不会因等待与其他容器断开连接所造成的阻塞。
进一步的，本实施例中，通过依据通信连接，将进入调试容器的命令终端发送至客户端；从命令终端接收客户端输入的调试指令。
S280、将所述运行信息发送至所述客户端。
本实施例将对该方法的具体工作流程进行描述。
1.用户通过客户端kubectl的调试插件对API服务器发起调试请求/apis/debug，API服务器通过Aggregator API机制将调试请求转发到调试服务器。示例性的，该调试请求可以是：
kubectl debug-c debug-shell--image＝debian:8target-pod–bash
其中，debug为调试请求的名称，debug-shell为调试容器的名称，debian为所使用的操作系统的版本；target-pod为待调试的服务单元的名称。
2.调试服务器先对指定的target-pod进行patch操作,将调试容器的配置信息以json格式配置在服务单元target-pod的配置文件pod.metadata.annotations中，内容如下：
其中，"container_name":"debug-shell"用于指定调试容器“debug-container”的容器名称为“debug-shell”；"image":"debian:8"用于指定调试容器“debug-container”所使用的容器镜像为"debian:8"；"limits":{"cpu":"800m","memory":"2Gi"}，用于确定“debug-container”的资源限制信息，如限制CPU资源为800M，内存(memory)为2Gi。
3.部署在每个K8S Node上的调试代理端监听到本K8S Node上的Pod的配置文件更新，解析配置文件pod.metadata.annotation中关于调试容器的配置信息，通过dockerdaemon接口，使用指定的容器镜像"debian:8"，创建调试容器"debug-shell"，并将调试容器"debug-shell"指定到target-pod的命名空间,并且根据资源限制信息设置调试容器"debug-shell"的资源使用限制。
4.如果调试容器创建成功，调试服务器可以从客户端接收调试指令，并向容器守护进程发起关于该调试指令的exec请求，拿到调试容器的输入输出(input and output，I/O)，并且返回给客户端kubectl(命令终端)。如果调试容器创建失败，调试服务器将返回创建失败原因给客户端kubectl(命令终端)。
本实施例的技术方案，通过接收从客户端发送的调试请求；当确定所述调试请求关联有调试服务时，则为所述调试请求分配针对容器的创建权限；将所述调试请求转发至运行有所述调试服务的调试服务器，所述调试服务用于依据所述创建权限，响应所述调试请求，以确定所述业务容器所归属的服务单元，其中，所述服务单元包括各容器的共享资源；依据从调试请求中解析出的配置信息，修改所述服务单元关联的配置文件；当检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器；依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；将所述运行信息发送至所述客户端，区别于通过在业务容器中集成调试工具的技术方案，本技术方案通过将包括调试工具的调试容器与业务容器运行于同一服务单元，以使得调试容器可以获取业务容器的共享资源，以在解决了因采用侵入的方式修改业务容器所带来的业务容器运行不稳定的问题，以实现减少开发人员的开发时间，增加业务容器运行的稳定性，保证正常业务的进行。进一步的，可以依据该通信连接，可以客户端可以访问多个容器，而不会因等待与其他容器断开连接所造成的阻塞。
实施例三
图3为本发明实施例三提供的一种容器的调试方法的示意图。
在上述实施例的基础上，本实施例中的方法可以应用于客户端。参照图3，该方法具体包括如下步骤：
S310、向容器集群发送针对业务容器的调试请求。
本实施例中，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器。
其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息。
一般的，容器的调试系统包括客户端、容器集群。其中，容器集群可以使用容器集群管理工具进行管理，客户端可以是容器集群管理工具提供的应用，或者集成有容器集群管理工具提供的接口的应用。
参照图2B，以该容器集群管理工具为Kubernetes为例进行说明。客户端为Kubernetes提供的命令行接口kubectl。
进一步的，Kubernetes遵循主从式架构设计，容器集群中包括集群主机(K8SMaster)和集群节点(Node)。
其中，K8S Master可以包括应用程序接口(Application ProgrammingInterface，API)服务器、键值存储系统(Etcd)等。集群节点(Node)也称为Worker或Minion，是部署容器(工作负载)的单机器(或虚拟机)。容器集群中的每个集群节点都必须具备容器的运行环境(Runtime)。集群节点(Node)中包括服务单元Pod和容器守护进程(Dockerdaemon)等。
进一步的，参照图2C，本实施例中的技术方案相对于图2B所示的架构，增加了调试服务器、调试代理端，以避免对Kubctl命令的核心代码进行修改，保证Kubernetes容器集群运行的稳定性。具体的，包括增加了客户端、调试服务器、调试代理端的改进。
本实施例中，在客户端Kubctl安装有调试插件，并通过该调试插件提供发送调试请求或调试指令的接口，不涉及到更改客户端Kubctl的核心代码，保证客户端Kubctl运行的稳定性，也减少开发人员的时间。其中，调试请求是用于发起调试任务的请求。调试指令是用于确定执行何种调试任务的指令。
S320、从所述容器集群接收所述运行信息。
本实施例中，可以将运行调试工具得到的结果，作为运行信息发送至客户端进行显示。
本实施例的技术方案通过向容器集群发送针对业务容器的调试请求，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；从所述容器集群接收所述运行信息，区别于通过在业务容器中集成调试工具的技术方案，本技术方案通过将包括调试工具的调试容器与业务容器运行于同一服务单元，以使得调试容器可以获取业务容器的共享资源，以在解决了因采用侵入的方式修改业务容器所带来的业务容器运行不稳定的问题，以实现减少开发人员的开发时间，增加业务容器运行的稳定性，保证正常业务的进行。
实施例四
图4为本发明实施例四提供的一种容器的调试方法的示意图。
在上述实施例的基础上，本实施例将对容器的调试系统所执行的方法进行描述。
一般的，容器的调试系统包括客户端、容器集群。其中，容器集群可以使用容器集群管理工具进行管理，客户端可以是容器集群管理工具提供的应用，或者集成有容器集群管理工具提供的接口的应用。
参照图2B，以该容器集群管理工具为Kubernetes为例进行说明。客户端为Kubernetes提供的命令行接口kubectl。
其中，K8S Master可以包括应用程序接口(Application ProgrammingInterface，API)服务器、键值存储系统(Etcd)等。集群节点(Node)也称为Worker或Minion，是部署容器(工作负载)的单机器(或虚拟机)。容器集群中的每个集群节点都必须具备容器的运行环境(Runtime)。集群节点(Node)中包括服务单元Pod和容器守护进程(Dockerdaemon)等。
Kubernetes服务本质是一组协同工作的Pod，类同多层架构应用中的一层。构成服务的Pod组通过标签选择器来定义。Kubernetes通过给服务分配静态IP地址和域名来提供服务发现机制，并且以轮循调度的方式将流量负载均衡到能与选择器匹配的Pod的IP地址的网络连接上(即使是故障导致Pod从一台机器移动到另一台机器)。默认情况下，服务任务会暴露在集群中(例如，多个后端Pod可能被分组成一个服务，前端Pod的请求在它们之间负载平衡)；除此以外，服务任务也可以暴露在集群外部(例如，从客户端访问前端Pod)。
参照图2C，本实施例中的技术方案相对于图2B所示的架构，增加了调试服务器、调试代理端，以避免对Kubctl命令的核心代码进行修改，保证Kubernetes容器集群运行的稳定性。
具体的，包括增加了客户端、调试服务器、调试代理端的改进。
1、客户端
本实施例中，在客户端Kubctl安装有调试插件，并通过该调试插件提供发送调试请求或调试指令的接口，不涉及到更改客户端Kubctl的核心代码，保证客户端Kubctl运行的稳定性，也减少开发人员的时间。其中，调试请求是用于发起调试任务的请求。调试指令是用于确定执行何种调试任务的指令。
2、调试服务器
调试服务器主要用于提供调试业务容器所涉及的API。
具体的，Kubernetes的汇总(Aggregated)API允许开发人员编写一个自己的服务，并把这个服务注册到API服务器中的API。也就是说，调试服务器中的API可以使用Aggregated API的方式扩展到API服务器中的API。Kubernetes可以通过涉及到调试服务的API的所对应的服务(service)名称，将调试请求或调试指令转发到对应的调试服务器进行处理。
3、调试代理端
调试代理端以守护进程集合(DaemonSet)的形式部署在每个集群节点(K8S Node)上，用于响应调试请求。具体的，调试代理端负责监听针对业务容器所在服务单元(Pod)的调试请求。其中，DaemonSet能够让所有(或者一些特定)的K8S Node运行同一个Pod中。当K8S Node加入到Kubernetes容器集群中，Pod会被DaemonSet调度到该K8S Node上运行。当K8S Node从Kubernetes容器集群中被移除，被DaemonSet调度的Pod会被移除。如果删除DaemonSet，所有跟这个DaemonSet相关的Pods都会被删除。
参照图4，该方法具体包括如下步骤：
S410、客户端向容器集群发送针对业务容器的调试请求。
本实施例中，具体的工作流程可以是客户端通过调试插件将调试请求发送至容器集群中的API服务器，API服务器在确定该调试请求关联有调试服务时，API服务器可以将该调试请求转发至与该调试服务的名称对应的调试服务器进行处理。
S420、容器集群响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器。
其中，所述服务单元包括各容器的共享资源。
本实施例中，容器集群中的调试服务器运行有调试服务，用于响应该调试请求。调试请求中包括所针对的业务容器，该调试服务可以从调试请求中解析出所要调试的业务容器所归属的服务单元。依据从调试请求中解析出的配置信息，修改所述服务单元关联的配置文件；当容器集群中的调试代理端检测到配置文件发生更新时，则在服务单元中创建一与所述配置文件匹配的调试容器。
具体的，本实施例中，调试请求中还可以包括配置信息，该配置信息为配置调试容器的信息。每个服务单元关联设置有配置文件，该配置文件包括配置服务单元的信息。进一步的，由于需要在服务单元中创建调试容器，可以将调试容器的配置信息写入服务单元的配置文件中，进而，根据该配置文件对服务单元中的容器资源进行修改。
进一步的，容器集群中的调试代理端设置有对配置文件的监听，当检测到服务单元的配置发生更新时，可以从配置文件中解析出镜像信息、资源限制信息；将基于镜像信息所确定的镜像进行实例化，得到运行在服务单元的调试容器；从资源限制信息读取调试容器的资源上限值；限制调试容器在运行时所占用的资源不高于资源上限值。
S430、容器集群依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息。
本实施例中，当容器集群中的调试容器在服务单元中成功运行时，容器集群可以建立调试容器与客户端之间的通信连接；依据通信连接，从客户端接收调试指令；在业务容器共享的命名空间中运行与调试指令关联的调试工具；将调试工具的运行结果，作为在共享资源中获取业务容器的运行信息。
进一步的，本实施例中，通过依据通信连接，将进入调试容器的命令终端发送至客户端；从命令终端接收客户端输入的调试指令。
S440、客户端从所述容器集群接收所述运行信息。
实施例五
图5为本发明实施例五提供的一种容器的调试装置的结构示意图。
本实施例可适用于对业务容器进行调试的情况，具体的，应用于采用无侵入性的对业务容器进行调试。该装置可以集成于容器的调试设备，该容器的调试设备可以是服务器、电脑、移动终端等。
本实施例中，以容器的调试设备为服务器为例进行说明。具体的，该服务器可以是集群服务器或者是独立服务器。进一步的，该服务器还用于运行至少一个容器。
参照图5，该装置具体包括如下结构：请求接收模块510、请求响应模块520、运行信息获取模块530和运行信息发送模块540。
请求接收模块510，用于接收客户端发送的、针对业务容器的调试请求。
请求响应模块520，用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源。
运行信息获取模块530，用于依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息。
运行信息发送模块540，用于将所述运行信息发送至所述客户端。
本实施例的技术方案，通过接收客户端发送的、针对业务容器的调试请求；响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；将所述运行信息发送至所述客户端，区别于通过在业务容器中集成调试工具的技术方案，本技术方案通过将包括调试工具的调试容器与业务容器运行于同一服务单元，以使得调试容器可以获取业务容器的共享资源，以在解决了因采用侵入的方式修改业务容器所带来的业务容器运行不稳定的问题，以实现减少开发人员的开发时间，增加业务容器运行的稳定性，保证正常业务的进行。
在上述技术方案的基础上，所述请求接收模块510，包括：
调试请求接收单元，用于接收从客户端发送的调试请求。
权限分配单元，用于当确定所述调试请求关联有调试服务时，则为所述调试请求分配针对容器的创建权限。
请求转发单元，用于将所述调试请求转发至运行有所述调试服务的调试服务器，所述调试服务用于依据所述创建权限，执行所述响应所述调试请求的步骤。
在上述技术方案的基础上，所述请求响应模块520，包括：
调试请求响应单元，用于响应所述调试请求，以确定所述业务容器所归属的服务单元，其中，所述服务单元包括各容器的共享资源。
配置文件修改单元，用于依据从调试请求中解析出的配置信息，修改所述服务单元关联的配置文件。
调试容器创建单元，用于当检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器。
在上述技术方案的基础上，所述调试容器创建单元，包括：
信息解析子单元，用于从所述配置文件中解析出镜像信息、资源限制信息；
实例化子单元，用于将基于所述镜像信息所确定的镜像进行实例化，得到运行在所述服务单元的调试容器。
资源限制信息读取子单元，用于从所述资源限制信息读取所述调试容器的资源上限值。
限制子单元，用于限制所述调试容器在运行时所占用的资源不高于所述资源上限值。
在上述技术方案的基础上，所述运行信息获取模块530，包括：
命名空间确定单元，用于确定所述业务容器共享在所述服务单元中的命名空间。
运行信息获取单元，用于在所述命名空间中运行所述调试工具，以从所述命名空间所确定的共享资源中获取所述业务容器的运行信息。
在上述技术方案的基础上，所述运行信息获取模块530，还包括：
连接建立单元，用于当所述调试容器在所述服务单元中成功运行时，建立所述调试容器与所述客户端之间的通信连接。
调试指令接收单元，用于依据所述通信连接，从客户端接收调试指令。
调试工具运行单元，用于在所述业务容器共享的命名空间中运行与所述调试指令关联的调试工具。
运行信息获取单元，用于将所述调试工具的运行结果，作为在所述共享资源中获取所述业务容器的运行信息。
在上述技术方案的基础上，所述调试指令接收单元，包括：
命令终端发送子单元，用于依据所述通信连接，将进入所述调试容器的命令终端发送至客户端。
调试指令接收子单元，用于从所述命令终端接收所述客户端输入的调试指令。
上述产品可执行本发明任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。
实施例六
图6为本发明实施例六提供的一种容器的调试装置的结构示意图。
参照图6，该装置具体包括如下结构：请求发送模块610和运行信息接收模块620。
请求发送模块610，用于向容器集群发送针对业务容器的调试请求，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
运行信息接收模块620，用于从所述容器集群接收所述运行信息。
上述产品可执行本发明任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。
实施例七
图7为本发明实施例七提供的一种容器的调试设备的结构示意图。如图7所示，该容器的调试设备包括：处理器70、存储器71、输入装置72以及输出装置73。该容器的调试设备中处理器70的数量可以是一个或者多个，图7中以一个处理器70为例。该容器的调试设备中存储器71的数量可以是一个或者多个，图7中以一个存储器71为例。该容器的调试设备的处理器70、存储器71、输入装置72以及输出装置73可以通过总线或者其他方式连接，图7中以通过总线连接为例。该容器的调试设备可以是电脑和服务器等。本实施例以容器的调试设备为服务器进行详细说明，该服务器可以是独立服务器或集群服务器。
存储器71作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明任意实施例所述的容器的调试方法对应的程序指令/模块(例如，容器的调试装置中的请求接收模块510、请求响应模块520、运行信息获取模块530和运行信息发送模块540；又例如，容器的调试装置中的请求发送模块610和运行信息接收模块620)。存储器71可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据设备的使用所创建的数据等。此外，存储器71可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器71可进一步包括相对于处理器70远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置72可用于接收输入的数字或者字符信息，以及产生与容器的调试设备的观众用户设置以及功能控制有关的键信号输入，还可以是用于获取图像的摄像头以及获取音频数据的拾音设备。输出装置73可以包括扬声器等音频设备。需要说明的是，输入装置72和输出装置73的具体组成可以根据实际情况设定。
处理器70通过运行存储在存储器71中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的容器的调试方法。
实施例八
本发明实施例八还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种容器的调试方法。
在一实施例中，该方法应用于容器集群中，包括：
接收客户端发送的、针对业务容器的调试请求；
响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；
依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
将所述运行信息发送至所述客户端。
在又一实施例中，该方法应用于客户端中，包括：
向容器集群发送针对业务容器的调试请求，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
从所述容器集群接收所述运行信息。
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的容器的调试方法操作,还可以执行本发明任意实施例所提供的容器的调试方法中的相关操作，且具备相应的功能和有益效果。
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是机器人，个人计算机，服务器，或者网络设备等)执行本发明任意实施例所述的容器的调试方法。
值得注意的是，上述容器的调试装置中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。
应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。
在本说明书的描述中，参考术语“在一实施例”、“在又一实施例”或“示例性的”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。
Claims (10)
1.一种容器的调试方法，其特征在于，包括：
接收客户端发送的、针对业务容器的调试请求；
响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，所述调试容器与所述业务容器运行在同一服务单元中，其中，所述服务单元包括各容器的共享资源；
依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
将所述运行信息发送至所述客户端；
所述响应所述调试请求，在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，包括：
响应所述调试请求，以确定所述业务容器所归属的服务单元；
依据从调试请求中解析出的配置信息，修改所述服务单元关联的配置文件；
当检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器；所述在所述服务单元中创建一与所述配置文件匹配的调试容器，包括：
从所述配置文件中解析出镜像信息、资源限制信息；
将基于所述镜像信息所确定的镜像进行实例化，得到运行在所述服务单元的调试容器；
从所述资源限制信息读取所述调试容器的资源上限值；
限制所述调试容器在运行时所占用的资源不高于所述资源上限值。
2.根据权利要求1所述的方法，其特征在于，所述接收客户端发送的、针对业务容器的调试请求，包括：
接收从客户端发送的调试请求；
当确定所述调试请求关联有调试服务时，则为所述调试请求分配针对容器的创建权限；
将所述调试请求转发至运行有所述调试服务的调试服务器，所述调试服务用于依据所述创建权限，执行所述响应所述调试请求的步骤。
3.根据权利要求1所述的方法，其特征在于，所述依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息，包括：
确定所述业务容器共享在所述服务单元中的命名空间；
在所述命名空间中运行所述调试工具，以从所述命名空间所确定的共享资源中获取所述业务容器的运行信息。
4.根据权利要求1所述的方法，其特征在于，所述依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息，还包括：
当所述调试容器在所述服务单元中成功运行时，建立所述调试容器与所述客户端之间的通信连接；
依据所述通信连接，从客户端接收调试指令；
在所述业务容器共享的命名空间中运行与所述调试指令关联的调试工具；
将所述调试工具的运行结果，作为在所述共享资源中获取所述业务容器的运行信息。
5.根据权利要求4所述的方法，其特征在于，所述依据所述通信连接，从客户端接收调试指令，包括：
依据所述通信连接，将进入所述调试容器的命令终端发送至客户端；
从所述命令终端接收所述客户端输入的调试指令。
6.一种容器的调试方法，其特征在于，包括：
向容器集群发送针对业务容器的调试请求，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，所述调试容器与所述业务容器运行在同一服务单元中，其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
从所述容器集群接收所述运行信息；
所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，包括：
所述容器集群中的调试服务器运行有调试服务，用于响应所述调试请求；所述调试服务从所述调试请求中解析出所要调试的业务容器所归属的服务单元；依据从所述调试请求中解析出的配置信息，修改所述服务单元关联的配置文件；当所述容器集群中的调试代理端检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器；
所述在所述服务单元中创建一与所述配置文件匹配的调试容器，包括：
所述容器集群中的调试代理端设置有对所述配置文件的监听，当检测到所述服务单元的配置文件发生更新时，从所述配置文件中解析出镜像信息、资源限制信息；将基于所述镜像信息所确定的镜像进行实例化，得到运行在所述服务单元的调试容器；从所述资源限制信息读取所述调试容器的资源上限值；限制所述调试容器在运行时所占用的资源不高于所述资源上限值。
7.一种容器的调试装置，其特征在于，包括：
请求接收模块，用于接收客户端发送的、针对业务容器的调试请求；
请求响应模块，用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，所述调试容器与所述业务容器运行在同一服务单元中，其中，所述服务单元包括各容器的共享资源；
运行信息获取模块，用于依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
运行信息发送模块，用于将所述运行信息发送至所述客户端；所述请求响应模块，包括：
调试请求响应单元，用于响应所述调试请求，以确定所述业务容器所归属的服务单元；
配置文件修改单元，用于依据从调试请求中解析出的配置信息，修改所述服务单元关联的配置文件；
调试容器创建单元，用于当检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器；
所述调试容器创建单元，包括：
信息解析子单元，用于从所述配置文件中解析出镜像信息、资源限制信息；
实例化子单元，用于将基于所述镜像信息所确定的镜像进行实例化，得到运行在所述服务单元的调试容器；
资源限制信息读取子单元，用于从所述资源限制信息读取所述调试容器的资源上限值；
限制子单元，用于限制所述调试容器在运行时所占用的资源不高于所述资源上限值。
8.一种容器的调试装置，其特征在于，包括：
请求发送模块，用于向容器集群发送针对业务容器的调试请求，所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，所述调试容器与所述业务容器运行在同一服务单元中，其中，所述服务单元包括各容器的共享资源；并依据所述调试工具，在所述共享资源中获取所述业务容器的运行信息；
运行信息接收模块，用于从所述容器集群接收所述运行信息；
所述容器集群用于响应所述调试请求，以在所述业务容器所归属的服务单元中，创建集成有调试工具的调试容器，包括：
所述容器集群中的调试服务器运行有调试服务，用于响应所述调试请求；所述调试服务从所述调试请求中解析出所要调试的业务容器所归属的服务单元；依据从所述调试请求中解析出的配置信息，修改所述服务单元关联的配置文件；当所述容器集群中的调试代理端检测到所述配置文件发生更新时，则在所述服务单元中创建一与所述配置文件匹配的调试容器；
所述在所述服务单元中创建一与所述配置文件匹配的调试容器，包括：
所述容器集群中的调试代理端设置有对所述配置文件的监听，当检测到所述服务单元的配置文件发生更新时，从所述配置文件中解析出镜像信息、资源限制信息；将基于所述镜像信息所确定的镜像进行实例化，得到运行在所述服务单元的调试容器；从所述资源限制信息读取所述调试容器的资源上限值；限制所述调试容器在运行时所占用的资源不高于所述资源上限值。
9.一种容器的调试设备，其特征在于，包括：存储器以及一个或多个处理器；
所述存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-6中任一所述的容器的调试方法。
10.一种包含计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-6中任一所述的容器的调试方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910774958.9A CN112416737B (zh) | 2019-08-21 | 2019-08-21 | 一种容器的测试方法、装置、设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910774958.9A CN112416737B (zh) | 2019-08-21 | 2019-08-21 | 一种容器的测试方法、装置、设备和存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112416737A CN112416737A (zh) | 2021-02-26 |
| CN112416737B true CN112416737B (zh) | 2024-03-01 |
Family
ID=74779957
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910774958.9A Active CN112416737B (zh) | 2019-08-21 | 2019-08-21 | 一种容器的测试方法、装置、设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112416737B (zh) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112995325A (zh) * | 2021-03-10 | 2021-06-18 | 中国民航信息网络股份有限公司 | 服务调试方法、调试服务、电子设备及计算机存储介质 |
| CN113010342B (zh) * | 2021-03-12 | 2024-07-19 | 北京百度网讯科技有限公司 | 运维诊断的方法、装置、设备以及存储介质 |
| CN113031993A (zh) * | 2021-04-26 | 2021-06-25 | 中国工商银行股份有限公司 | 基于集群容器的应用升级方法及装置 |
| CN113296807B (zh) * | 2021-05-12 | 2023-10-31 | 阿里巴巴新加坡控股有限公司 | 数据更新方法 |
| CN113110918A (zh) * | 2021-05-13 | 2021-07-13 | 广州虎牙科技有限公司 | 读写速率管控方法、装置、节点设备及存储介质 |
| CN113391878A (zh) * | 2021-05-26 | 2021-09-14 | 浙江大华技术股份有限公司 | 远程访问方法、装置、系统和存储介质 |
| CN113377665B (zh) * | 2021-06-25 | 2024-08-06 | 北京百度网讯科技有限公司 | 基于容器技术的测试方法、装置、电子设备及存储介质 |
| CN114143315B (zh) * | 2021-11-30 | 2024-08-02 | 阿里巴巴（中国）有限公司 | 边缘云系统、主机访问方法及设备 |
| CN114138421A (zh) * | 2021-12-08 | 2022-03-04 | 兴业银行股份有限公司 | kubernetes的智能资源控制系统及方法 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108415795A (zh) * | 2018-02-12 | 2018-08-17 | 人和未来生物科技（长沙）有限公司 | 一种容器Dockerfile、容器镜像快速生成方法及系统 |
| US20180322163A1 (en) * | 2017-05-05 | 2018-11-08 | Servicenow, Inc. | Configuration management identification rule testing |
| CN109150978A (zh) * | 2018-07-24 | 2019-01-04 | 北京百度网讯科技有限公司 | 调试微服务的方法和装置 |
| CN109669680A (zh) * | 2017-10-16 | 2019-04-23 | 阿里巴巴集团控股有限公司 | 网页模块的开发处理方法、装置及电子设备 |
| CN109783374A (zh) * | 2018-12-27 | 2019-05-21 | 北京百度网讯科技有限公司 | 自动驾驶领域的代码处理方法、装置、设备和计算机存储介质 |
-
2019
- 2019-08-21 CN CN201910774958.9A patent/CN112416737B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180322163A1 (en) * | 2017-05-05 | 2018-11-08 | Servicenow, Inc. | Configuration management identification rule testing |
| CN109669680A (zh) * | 2017-10-16 | 2019-04-23 | 阿里巴巴集团控股有限公司 | 网页模块的开发处理方法、装置及电子设备 |
| CN108415795A (zh) * | 2018-02-12 | 2018-08-17 | 人和未来生物科技（长沙）有限公司 | 一种容器Dockerfile、容器镜像快速生成方法及系统 |
| CN109150978A (zh) * | 2018-07-24 | 2019-01-04 | 北京百度网讯科技有限公司 | 调试微服务的方法和装置 |
| CN109783374A (zh) * | 2018-12-27 | 2019-05-21 | 北京百度网讯科技有限公司 | 自动驾驶领域的代码处理方法、装置、设备和计算机存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112416737A (zh) | 2021-02-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112416737B (zh) | 一种容器的测试方法、装置、设备和存储介质 | |
| US11539753B2 (en) | Network-accessible service for executing virtual machines using client-provided virtual machine images | |
| US20240143381A1 (en) | Container orchestration in a clustered and virtualized computer system | |
| US20230104129A1 (en) | Network policy generation for continuous deployment | |
| Nurmi et al. | The eucalyptus open-source cloud-computing system | |
| US10719369B1 (en) | Network interfaces for containers running on a virtual machine instance in a distributed computing environment | |
| US9934073B2 (en) | Extension of resource constraints for service-defined containers | |
| US8856801B2 (en) | Techniques for executing normally interruptible threads in a non-preemptive manner | |
| WO2019195003A1 (en) | Virtual rdma switching for containerized applications | |
| US20150370582A1 (en) | At least one user space resident interface between at least one user space resident virtual appliance and at least one virtual data plane | |
| CN111404753A (zh) | 一种扁平网络配置方法、计算机设备及存储介质 | |
| US12074884B2 (en) | Role-based access control autogeneration in a cloud native software-defined network architecture | |
| EP4297359A1 (en) | Metric groups for software-defined network architectures | |
| EP4160408A1 (en) | Network policy generation for continuous deployment | |
| WO2022271223A1 (en) | Dynamic microservices allocation mechanism | |
| CN114510321A (zh) | 资源调度方法、相关装置和介质 | |
| US20230138867A1 (en) | Methods for application deployment across multiple computing domains and devices thereof | |
| Hao | Edge computing on low availability devices with K3S in a smart home IoT system | |
| Gu et al. | CNTC: A container aware network traffic control framework | |
| Bhonagiri et al. | Constraint based network communications in a virtual environment of a proprietary hardware | |
| Krishnakumar | Accelerated DPDK in containers for networking nodes | |
| US20240119020A1 (en) | Driver to provide configurable accesses to a device | |
| Al Jubury | Measure the data transfer performance between containers | |
| Bruzual Balzan | Distributed Computing Framework Based on Software Containers for Heterogeneous Embedded Devices | |
| Cañete Garrucho | Container-based deployment strategies on heterogeneous edge-to-cloud computing infrastructures |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |