CN117807039A - 一种容器处理方法、装置、设备、介质及程序产品 - Google Patents

Abstract

本申请实施例提供了一种容器处理方法、装置、设备、介质及程序产品；其中的方法包括：获取用户空间中任一系统容器发送的文件操作请求；响应于文件操作请求调用内核空间中的第一内核函数；根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件；根据第一内核函数所指示的处理逻辑，对任一系统容器对应的资源文件进行文件操作。采用本申请实施例能够提高容器隔离的准确性。

Description

一种容器处理方法、装置、设备、介质及程序产品

技术领域

本申请涉及计算机技术领域，具体涉及一种容器处理方法、装置、设备、介质及程序产品。

背景技术

为充分利用服务器的计算资源，往往可以在同一服务器上部署大量的系统容器。

经实践发现，在系统容器运行时很可能因为容器隔离的不彻底性，导致系统容器的性能下降，甚至破坏系统容器的运行状态。例如，系统容器在关闭时会遍历用户态文件系统（filesystem in userspace，fuse）下的connection文件（一种用于反映系统目前已经挂载的所有用户态文件系统的文件），并卸载connection文件，但由于不同系统容器挂载的fuse用户态文件系统下的connection文件是互相可见的，系统容器会不加区分地将其他系统容器挂载的fuse用户态文件系统下的connection文件卸载，导致其他系统容器的运行故障。

因此，如何提高容器隔离的彻底性成为研究热点。

发明内容

本申请实施例提供一种容器处理方法、装置、设备、介质及程序产品，能够提高容器隔离的准确性。

一方面，本申请实施例提供了一种容器处理方法，应用于操作系统，操作系统中包括用户空间和内核空间；内核空间中包含多个系统容器，多个系统容器中的第一系统容器允许访问第二系统容器的资源文件，第一系统容器和第二系统容器不同；该方法包括：

获取用户空间中任一系统容器发送的文件操作请求，文件操作请求用于请求在内核空间中针对资源文件执行文件操作；

响应于文件操作请求调用内核空间中的第一内核函数；第一内核函数用于指示系统容器的文件视图以及针对文件视图内的资源文件执行文件操作时的处理逻辑；

根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件；

根据第一内核函数所指示的处理逻辑，对任一系统容器对应的资源文件进行文件操作。

另一方面，本申请实施例提供了一种容器处理装置，搭载于操作系统，操作系统中包括用户空间和内核空间；内核空间中包含多个系统容器，多个系统容器中的第一系统容器允许访问第二系统容器的资源文件，第一系统容器和第二系统容器不同；该装置包括：

获取单元，用于获取用户空间中任一系统容器发送的文件操作请求，文件操作请求用于请求在内核空间中针对资源文件执行文件操作；

处理单元，用于响应于文件操作请求调用内核空间中的第一内核函数；第一内核函数用于指示系统容器的文件视图以及针对文件视图内的资源文件执行文件操作时的处理逻辑；

处理单元，还用于根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件；

处理单元，还用于根据第一内核函数所指示的处理逻辑，对任一系统容器对应的资源文件进行文件操作。

在一种实现方式中，文件操作请求中携带任一系统容器的容器标识；第一内核函数所指示的系统容器的文件视图包括：系统容器对内核空间中与相应系统容器的容器标识相匹配的资源文件具有视图权限；处理单元，用于根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件时，具体用于：

获取文件标识集合；文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识；

根据任一系统容器的容器标识，从文件标识集合中筛选出与任一系统容器的容器标识相匹配的资源文件的文件标识；

基于与任一系统容器的容器标识相匹配的资源文件的文件标识，从所述内核空间中扫描到与所述任一系统容器的容器标识相匹配的资源文件；与所述任一系统容器的容器标识相匹配的资源文件为所述任一系统容器对应的资源文件。

在一种实现方式中，第一内核函数所指示的处理逻辑包括向系统容器返回资源文件；处理单元，用于根据所述第一内核函数所指示的处理逻辑，对所述任一系统容器对应的资源文件进行文件操作时，具体用于：

根据所述第一内核函数所指示的处理逻辑，将所述任一系统容器对应的资源文件添加至文件缓存空间；

将所述文件缓存空间中的资源文件返回至所述任一系统容器。

在一种实现方式中，处理单元，还用于：

在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数；所述第二内核函数是指在内核调用路径上能够针对资源文件执行文件操作的关键函数；

按照文件视图调整策略对所述第二内核函数进行容器隔离处理，得到第一内核函数；

其中，所述第一内核函数能够限制不同系统容器在所述内核空间中的文件视图。

在一种实现方式中，函数截取处理和所述容器隔离处理是由内核模块执行，所述内核模块部署于所述操作系统中的所述内核空间中，且所述内核模块中包括动态检测内核函数框架；

处理单元，用于在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数时，具体用于：

在所述内核空间中加载所述内核模块的过程中，通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数。

在一种实现方式中，内核空间中的任一资源文件表示为参考资源文件；处理单元，用于通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数时，具体用于：

通过所述内核模块中的所述动态检测内核函数框架，对所述参考资源文件的内核调用路径进行调用层次分析，得到所述内核调用路径上的一个或多个候选函数；所述参考资源文件的内核调用路径指示访问所述参考资源文件所需经历的调用路径；

从所述一个或多个候选函数中筛选出能够针对所述参考资源文件执行文件操作的关键函数；

截取所述关键函数作为第二内核函数。

在一种实现方式中，内核空间中包括文件系统层，所述文件系统层中包括第一文件子系统层和第二文件子系统层；所述第二文件子系统层中包括至少一个文件系统，所述文件系统中包括资源文件及与资源文件相关的处理逻辑；所述第一文件子系统层为所述第二文件子系统层中的每个文件系统提供调用接口；

其中，从所述内核空间中截取的第二内核函数位于访问文件系统时针对所述第一文件子系统层的调用路径上，或者，位于访问文件系统时针对所述第二文件子系统层的调用路径上。

在一种实现方式中，内核空间中还包括内核机制层；所述内核机制层中包括至少一个子系统，一个子系统与所述文件系统层中的一个文件系统对应；处理单元，还用于：

若所述文件系统层中被容器隔离处理后的所述第一内核函数的执行需要所述内核机制层的配合，则从所述内核机制层中确定所述第一内核函数所访问的文件系统对应的子系统；

对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统；所述系统逻辑调整由所述内核空间中的内核模块执行。

在一种实现方式中，处理单元，还用于对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统时，具体用于：

在所述第一内核函数所访问的文件系统对应的子系统中建立文件标识集合；所述文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识。

在一种实现方式中，内核模块中包括容器隔离功能对应的模块参数；所述容器隔离功能被启动时所述内核模块执行所述函数截取处理，所述容器隔离处理和所述系统逻辑调整；

当所述容器隔离功能对应的模块参数被赋予第一参数值时，所述内核模块中的所述容器隔离功能被启动；

当所述容器隔离功能对应的模块参数被赋予第二参数值时，所述内核模块中的所述容器隔离功能被关闭。

又一方面，本申请实施例提供了一种计算机设备，该设备包括：

处理器，用于加载并执行计算机程序；

计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，该计算机程序被处理器执行时，实现上述容器处理方法。

又一方面，本申请提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行上述容器处理方法。

又一方面，本申请提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述容器处理方法。

本申请实施例中，支持对操作系统的内核空间中关键的第二内核函数进行逻辑调整，具体是增加容器隔离的语义，使得增加容器隔离的语义所得的第一内核函数（即对第二内核函数进行逻辑调整所得的内核函数）不仅能够用于指示针对内核空间中的资源文件执行文件操作时的处理逻辑，而且还用于指示操作系统的用户空间中的系统容器的文件视图（即限制系统容器的文件视图）。这样，在获取到用户空间中任一系统容器发送的文件操作请求（该文件操作请求用于请求在内核空间中针对资源文件执行文件操作）时，可以响应于该文件操作请求调用逻辑调整后的第一内核函数，并根据该第一内核函数所指示的系统容器的文件视图，有选择地从内核空间中筛选出发起本次文件操作请求的该任一系统容器对应的资源文件；相比于相关技术中调用逻辑调整前的第二内核函数选择内核空间中的全部资源文件而言，能够区分来自于不同系统容器的文件操作请求，针对不同的系统容器仅筛选相应系统容器相关的资源文件，有效限制不同系统容器的文件视图，达到较为精准的容器隔离。进一步的，在筛选到当前发起文件操作请求的该任一系统容器对应的资源文件后，仅对该任一系统容器对应的资源文件进行文件操作；相比于相关技术中未进行容器隔离时对全部资源文件进行文件操作而言，在确保该任一系统容器对应的资源文件得到文件操作的情况下，不影响用户空间中其他系统容器的运行状态，且减少文件操作所耗费的资源量，提高文件操作效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1a是本申请一个示例性实施例提供的一种Linux系统的架构示意图；

图1b是本申请一个示例性实施例提供的一种文件系统层的结构示意图；

图2是本申请一个示例性实施例提供的一种在内核空间中部署内核模块的示意图；

图3a是一种现有的容器隔离方案的架构示意图；

图3b是另一种现有的容器隔离方案的架构示意图；

图4是本申请一个示例性实施例提供的一种云游戏的架构示意图；

图5是本申请一个示例性实施例提供的一种容器处理方法的流程示意图；

图6是本申请一个示例性实施例提供的另一种容器处理方法的流程示意图；

图7是一种EventHub模块的结构示意图；

图8是一种调用资源文件的流程示意图；

图9是本申请一个示例性实施例提供的一种有选择地调用资源文件的流程示意图；

图10是本申请一个示例性实施例提供的一种容器处理装置的结构示意图；

图11是本申请一个示例性实施例提供的一种计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面先对本申请实施例涉及的技术术语和相关概念进行简单介绍，其中：

一、插桩技术。

插桩技术是指保证原有程序逻辑完整性的基础上，在程序中插入探针，通过探针采集代码中的信息（如方法本身、方法参数值或返回值等）；具体是在程序中的特定位置插入代码段（即探针），从而收集程序运行时的动态上下文信息。例如，内核调测工具（function tracer，ftrace）是Linux内核（一种开源的操作系统内核）的一个内部探针程序，该内核调测工具也可以表示为ftrace hook（Function Tracer Hook，函数检测器钩子），可以理解为Linux内核中的一套动态检测内核函数的框架；支持选择性对Linux内核中的大部分函数进行劫持和检测（此处劫持和检测可以是由hook（钩子，用于实现函数截取的探针程序）实现），以此可以调整和控制内核的一些函数过程和机制，旨在帮助操作系统的开发人员和设计人员弄清楚系统内核内部发生的情况；具体可以用于调试或分析操作系统中除用户空间之外发生的延迟和性能等问题。其中，Linux内核是Linux操作系统的核心部分，能够管理计算机设备的硬件设备和供计算机设备中部署的应用程序的使用；Linux内核的具体作用是支持将计算机设备中的应用层的请求传递给计算机设备的硬件，并充当底层启动程序，对计算机设备中的各种设备和组件进行寻址。

二、操作系统（Operating System，OS）。

操作系统是计算机设备的内置程序，用于协作计算机设备内部的各种硬件和软件，使得部署有操作系统的计算机设备能够与用户进行交互；其中，计算机设备可以称为Host（主机），主机为运行操作系统的计算资源实例，在主机上的操作为主机操作。具体来说，操作系统是计算机设备中的软件的一部分，是计算机设备中硬件基础上的第一层软件，作为计算机设备中的硬件和其它软件沟通的桥梁（或接口）；操作系统可以控制计算机设备中的其他程序的运行，管理计算机设备的系统资源，提供最基本的计算功能（如管理和配置内存、决定系统资源供需的优先次序及提供一些基本的服务程序等）。其中，操作系统可以包括但是不限于：Linux（基于Linux内核的操作系统）、Windows（微软操作系统）、Android（安卓操作系统）及IOS（Internetworking Operating System，苹果操作系统）等等。为便于阐述，本申请实施例以Android操作系统为例进行阐述；Android操作系统是一种主流的手机操作系统，是Android游戏运行的基础系统；具体是一种运行于Linux上的操作系统，即Android的核心架构是基于Linux系统实现的。

示例性地，Linux系统的系统结构可以参见图1a，主要分为两部分，分别为用户空间（UserSpace）和内核空间（KernelSpace）。其中，用户空间和内核空间都属于操作系统中的虚拟内存（Virtual Memory），是操作系统为一个进程虚拟出来的内存空间，为该进程提供独立且私有的内存空间；以虚拟内存为48位的操作系统为例，其虚拟地址空间（即进程的进程地址空间）的范围为太字节（TeraByte，TB），按照1:1的比例划分，内核空间（KernelSpace）和用户空间（UserSpace）各占128TB；通过虚拟内存机制，使得进程以为自己占用了全部的物理内存。其中，上述提及的进程（Process），是计算机设备中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。简单来说，进程可以理解为在操作系统中运行的程序；例如，在计算机设备打开并运行游戏类应用程序时，需要为该游戏的运行启动一个进程，以通过该进程来实现游戏的成功运行。

基于上述对虚拟内存的简单介绍，下面分别对虚拟内存中的用户空间和内核空间进行介绍，其中：

（1）用户空间。

用户空间是一个相对内核空间而言虚拟的概念，它指的是用户在使用计算机设备时所能看到的和操作的环境，包括Shell（命令行解释器）终端、文件系统、应用程序、系统库和配置文件等，是运行应用程序的环境，以及支持用户进行文件和目录的创建、删除、修改等操作的空间。如图1a所示，用户空间中可以运行系统容器（或简称容器），该系统容器可以理解为一个独立的进程；其中，系统容器是操作系统的一种轻量的虚拟化，运行于具体的操作系统之上，是一种可以在操作系统实例上运行的独立环境，用于隔离和封装应用及其依赖项。例如，Android操作系统下的用户空间中创建的系统容器可以称为Android容器，该Android容器是容器的一种实例，在游戏场景下一个Android容器可以独立运行Android游戏。

（2）内核空间。

内核空间是操作系统的核心，负责管理操作系统的硬件和软件资源，控制着操作系统的硬件和软件的运行。内核空间提供了各种系统服务和资源管理功能，如进程管理、内存管理、设备驱动程序和文件系统等。如图1a所示，内核空间中可以主要包括文件系统层和内核机制层。其中：

①在内核层面，文件系统层包含两个主要部分，如图1b所示，分别为第一文件子系统层（或称为虚拟文件系统（Virtual File System，VFS））和第二文件子系统层（或称为文件系统）。其中，第二文件子系统层中包括至少一个文件系统（如ramfs（Random AccessMemory File System，基于随机存取的内存文件系统），fusectl（FUSE ControlFilesystem，FUSE控制文件系统）等），每个文件系统中包含用户空间中的系统容器创建的资源文件及与资源文件相关的处理逻辑，用于实现具体的文件功能。第一文件子系统层的设计目标是实现对底层的第二文件子系统层的透明访问，使得用户空间中的不同系统容器（或进程）能够以一致的方式访问第二文件子系统层中的不同文件系统；该第一文件子系统层具体可以基于通用的文件系统数据结构和标准函数接口，为第二文件子系统层中的每个文件系统提供统一的调用接口。如图1b所示，在第一文件子系统层中可以包括dentry（directory entry，目录项结构），inode（index node，索引节点结构）和file（文件结构）等；这三个结构是虚拟文件系统使用的通用结构，用于抽象统一出不同的文件系统，基于这些通用的结构虚拟文件系统向用户提供了统一的文件抽象，不同的文件系统通过实现虚拟文件系统的接口来加入内核文件系统服务。

具体地，用户空间中的进程（或系统容器）可以通过系统调用访问文件系统层中的上层抽象地虚拟文件系统（即第一文件子系统层），该虚拟文件系统会根据进程的访问路径路由到相应的文件。在根据进程的访问路径路由相应资源文件的过程中，虚拟文件系统会使用通用的文件系统数据结构（如图1b所示的inode索引节点结构和dentry目录项结构等）来表示资源文件的访问操作过程，具体会基于虚拟文件系统中这些通用的数据结构和操作接口调用到第二文件子系统层中的文件系统的文件具体实现，在文件系统中的实现函数中完成最终的资源文件请求访问。

②内核空间中的内核机制层中包括多个独立的子系统，每个子系统负责系统的特定功能，可以简化操作系统的设计和实现，为操作系统中的应用程序和硬件提供稳定且高效的运行环境。内核机制层主要通过管理硬件资源、进程调度和内存管理等机制，确保操作系统的稳定性和高效性。其中，一个子系统与文件系统层中的一个文件系统对应；如图1a所示，文件系统层中的/dev/input（输入设备的设备文件存放目录）在内核机制层中对应有input子系统（一种用于管理输入的子系统）；该input子系统由三部分组成：input driver（驱动层，用于实现输入设备的控制），input core（核心层，用于处理和管理所有输入设备的事件）和input handle（事件处理层，用于将输入设备产生的事件传递给相应的事件处理函数进行处理）；可以用于Linux系统下的输入设备，具体是针对输入设备的一套管理框架，用于控制和处理输入设备的事件。同理，文件系统层中的cgroup（control groups，控制组群）文件系统在内核机制层中对应有cgroup子系统，cgroup是Linux内核中用于资源限制的技术，它提供了进程间资源隔离的机制；device cgroup（Device Control Groups，设备控制组）是cgroup中一个子系统，用于控制cgroup中进程任务可以访问的设备资源；其他的cgroup子系统有中央处理器（central processing unit，CPU）和memory（内存资源控制组）等等。

正如前述所描述的，用户空间中可以包括多个系统容器（或简称容器），而该多个系统容器中的第一系统容器允许访问第二系统容器的资源文件，该第一系统容器和第二系统容器是多个系统容器中的不同系统容器。这导致Android系统容器运行时，系统容器之间隔离的不彻底，而这种容器隔离的不彻底性导致内核空间中的一些资源文件是系统容器互相可见的。例如，系统容器在关闭时会遍历fuse用户态文件系统（如lxcfs（Linux容器文件系统，即一种为容器技术设计的用户态文件系统）是一个开源的fuse用户态文件系统的实现，用于限制系统容器的进程信息伪文件系统（process information pseudo-filesystem，procfs）下文件的访问，能够让系统容器看到被限制的资源信息，让主机资源信息对系统容器不可见）下的connection文件，并逐个卸载该connection文件，而不同系统容器挂载的fuse用户态文件系统下的connection文件是互相可见的（即系统容器对其他系统容器挂载的fuse用户态文件系统下的connection文件是可见的），因此系统容器在关闭时会不加区分地把操作系统的所有connection文件关闭，即不仅关闭挂载于自己的fuse用户态文件系统下的connection文件，还关闭挂载于其他系统容器的fuse用户态文件系统下的connection文件，这导致对系统容器持有资源敏感的应用或场景会因隔离不彻底而受到影响，造成系统容器的性能降低，甚至破坏系统容器的运行状态，引起运行故障。

为解决系统容器隔离不足带来的运行缺陷，本申请实施例充分利用用户空间和内核空间之间通过文件实现交互的性质（即：在Linux中，用户空间主要通过内核空间暴露出来的资源文件与内核空间进行交互，即用户空间中的进程采用访问内核空间中的文件系统层的形式来获取对应内核空间中的资源文件；这种通过文件实现内核通信的机制也同样适用于Android系统容器，如用户空间中的Android系统容器会通过访问内核空间中的文件系统层中的/proc（用于存储进程信息的目录），/sys（用于存储针对设备管理或处理所产生信息的目录）和/dev（用于存储硬件设备信息的目录）下的资源文件进行工作），即基于文件系统层作为Linux内核的门户的特点，提出一种容器处理方案。该容器处理方案具体是一种利用动态内核插桩技术ftrace的容器隔离方案，可以通过使用ftrace hook截取内核空间中的关键函数并修改该关键函数的部分逻辑，为关键函数的特定行为增添容器隔离的语义，达到限制系统容器之间关键可见资源的互相访问。本申请实施例提供的容器处理方案可以由计算机设备执行，该计算机设备中部署的操作系统是基于Linux内核实现的，且该Linux内核的内核空间中部署有内核模块；该内核模块为集成了本申请实施例提供的容器处理方案的模块，该模块中安装有ftrace hook工具，以通过该ftrace hook工具实现动态内核插桩，以从内核空间中的文件系统层中截取出内核调用路径上的关键函数，从而对关键函数增加容器隔离的语义，提高容器隔离的彻底性。此外，为配合完成内核空间中针对文件系统层的截取处理，在针对具体问题时还需截取处理对应的内核机制层，以在内核机制层的基础上进行文件系统层的处理。

示例性地，在Linux系统的内核空间部署内核模块的示意图可以参见图2；如图2所示，在内核空间中部署有内核模块，该内核模块中包括ftrace hook工具。当在内核空间中加载该内核模块时，一方面，可以借助该内核模块中的ftrace hook工具从文件系统层中截取出关键的内核函数或内核结构（在本申请实施例中称为第二内核函数），并对该第二内核函数增加容器隔离的语义，以更改Linux内核的文件系统逻辑，通过改变这些内核函数的工作例程和行为，让文件系统层区别来自不同系统容器的文件操作请求，针对不同的系统容器有选择性地对相关的资源文件进行文件操作（如返回资源文件至系统容器）。

另一方面，为了保证Linux内核上下的一致性，在一些情况下，仅处理内核空间中的文件系统层来限制系统容器的文件视图是不够的，针对内核机制层中的一些子系统或者机制，如文件系统层中的/dev/input（Linux操作系统下的目录，包含事件捕获器，反映Linux上的输入设备文件）对应到内核机制层中的input子系统，文件系统层中的cgroup对应到内核机制层中cgroup子系统等，需对内核机制层中这些子系统或者机制中的一些核心部分作处理。例如，在内核机制层中的input子系统中需要截取处理输入设备结构的创建和销毁，绑定输入设备的资源文件（如虚拟设备文件）和创建该输入设的系统容器之间的联系；使得文件系统层可以利用内核机制层中被额外处理的部分来正确处理来自不同系统容器的隔离访问请求。

通过内核模块中的ftrace hook工具截取并修改内核空间中的关键函数以及内核机制层中的相应逻辑后，Linux系统可以根据修改后的关键函数和内核机制层限制不同系统容器的文件视图，达到系统容器的视图隔离的目的。具体地，用户空间中的任一系统容器可以发起文件操作请求，该文件操作请求用于请求在内核空间中针对资源文件执行文件操作（如资源文件的返回或删除等）。内核空间在获取到该任一系统容器发起的文件操作请求时，可以响应于该文件操作请求调用内核空间中的第一内核函数；该第一内核函数是内核空间中的内核模块对内核空间中原本的第二内核函数进行逻辑更改所得的，且该第一内核函数用于指示系统容器的文件视图，以及针对资源文件执行文件操作时的处理逻辑。可以根据第一内核函数所指示的系统容器的文件视图，在内核空间中筛选出该任一系统容器对应的资源文件；也就是说，本申请实施例通过限制该任一系统容器的文件视图，使得只需从内核空间中筛选出位于该任一系统容器的文件视图内的资源文件。这样，可以根据第一内核函数所指示的针对资源文件执行文件操作时的处理逻辑对该任一系统容器对应的资源文件（即上述提及的属于该任一系统容器的文件视图内的资源文件）进行文件操作。

经实践发现，本申请实施例提供的容器处理方案，相比于现有主流的容器隔离的方案更加具有优势。下面对本申请实施例提供的容器处理方案和现有主力方案进行对比，以给出本申请实施例提供的容器处理方案的优势；其中：

现有主流的容器隔离方案可以大致包括：device cgroup技术和lxcfs技术。其中：①device cgroup技术的原理示意图可以参见图3a，device cgroup技术的技术原理是：Linux内核的cgroup可以限制用户空间中的进程对内核空间中的资源的访问，且内核空间中不同的cgroup子系统控制不同的资源。内核空间中的devices（设备）子系统则限制了系统容器内进程对资源（或设备资源）的访问，基于cgroup-v1（cgroup的v1版本）文件系统对相关的device cgroup的文件device.allow（设备白名单，用于列出允许cgroup中的任务访问的设备）或者文件device.deny（设备黑名单，用于列出禁止cgroup中的任务访问的设备）进行操作，就可以限制属于该cgroup内的进程对特定设备的设备资源的访问，同时也可以限制系统容器对设备资源的访问。通过配置device cgroup，使得系统容器只能访问允许其访问的设备资源，以此解决系统容器访问其他容器设备带来的运行问题。然而，devicecgroup技术的使用场景受限于容器对设备资源的访问，无法进行额外的扩展；也就是说，如果要限制系统容器对设备资源的访问，操作系统需手动配置device cgroup的device.allow或者device.deny文件，这样对于主机上任意一个容器创建的设备（如输入设备），操作系统需为每个系统容器单独配置一遍设备资源的限制信息，大大降低了可管理性和灵活性。并且，尽管通过写入device cgroup文件系统的文件能够控制系统容器对设备资源的打开、读取和写入，但系统容器依然能够看到所有系统容器对应的设备资源，且能够知晓操作系统存在哪些设备资源。

②lxcfs技术的原理示意图可以参见图3b，lxcfs技术的技术原理是：Lxcfs技术主要依赖于fuse用户态文件系统，具体是通过在用户态实现一个用户态文件系统并挂载到系统容器的proc文件系统（即前述提及的procfs文件系统）对应文件下，限制系统容器对proc文件的访问，达到让系统容器在访问这些反映系统资源的文件时只能看到自己被系统限制的资源信息。不难发现，由于lxcfs技术依赖于fuse用户态文件系统的特点，导致lxcfs技术的性能低效，需要多次系统调用满足用户的访问请求，难以满足系统容器的高并发访问的需求，系统容器的用户请求依赖于系统的单个lxcfs守护进程，需开启多线程处理处理用户的并发访问，额外占用系统资源。并且，如果要进一步增添lxcfs的隔离文件的支持能力，需实现文件系统的大部分基础功能，导致调试周期较长。因此，Lxcfs技术提供了使用用户态文件系统思路来解决因容器隔离缺陷带来的实际运行问题，但用户态文件系统难以广泛普适的使用，需要针对特定场景实现单独的用户态文件系统处理。

与主流的device cgroup技术和lxcfs技术不同的是，本发明提出的基于ftracehook技术的容器隔离方案，提供了解决容器隔离实际问题的新方案；该新方案可以针对每个容器隔离问题的具体场景，灵活的根据内核的工作原理定制问题的解决方法，具有较好的扩展性和适用性，且从内核函数代码层面对关键函数进行修改，这种函数粒度的修改控制可以作到灵活的处理而不影响整体的内核功能，且能够补足内核函数的功能，扩展内核namespace（命名空间，一种存储命名信息的存储空间）的语义的同时，确保侵入内核的过程可以轻量化实现，不需牺牲容器太多的性能。并且，由于系统容器主要靠文件抽象的形式与内核空间进行通信，使得通过对文件系统的准确截取，能够在限制容器的文件视图解决大部分系统容器的文件隔离不足的实际问题。

进一步的，本申请实施例提供的容器处理方案可以适用于任何需要容器隔离的应用场景。例如，本申请实施例提供的容器处理方案可以应用于云游戏场景；其中，云游戏场景的架构示意图可以参见图4。如图4所示，用户终端中部署的客户端应用可以向边缘服务器请求Android容器，服务器在接收到客户端应用发送的请求时可以启动游戏镜像，创建对应的Android系统容器，并实现客户端应用和对应Android系统容器之间的连接。客户端应用在游戏运行时记录用户输入的指令，并将该指令转化为控制指令流发送至边缘服务器中的Android系统容器，使得Android系统容器能够模拟指令流收集云游戏的渲染图像和音频等信息，并将这些信息编码为相关数据流发送回客户端应用，确保客户端应用收到相关数据流后，解码相关数据流并显示云游戏的游戏图像。在上述描述的客户端应用和服务器之间持续的交互过程中，云游戏得以服务用户。

本申请实施例应用于云游戏场景时，可以用于解决实际云游戏场景中的Android容器隔离不彻底的所导致的问题。具体地，在云游戏场景下，边缘服务器拥有Android游戏镜像，在一个云游戏启动时边缘服务器可以拉起运行游戏镜像创建对应Android系统容器，以通过在该Android系统容器中运行相应的云游戏；一个Android系统容器可以运行一个云游戏。在实际云游戏场景中，为充分利用边缘服务器的计算资源会在一台服务器上部署大量的Android系统容器，每个系统容器单独运行一个Android游戏镜像，即在同一台服务器上通过多个Android系统容器运行多个云游戏；在这种情况下，同一台服务器上部署的大量Android系统容器会因为隔离不足导致相互访问资源文件，不仅造成云游戏场景中服务器的资源浪费，而且还会导致各云游戏之间相互影响，甚至造成云游戏的中断和异常等等。基于此，将本申请实施例提供的容器处理方案应用于云游戏场景时，能够有效隔离服务器中部署的多个Android系统容器，从而在确保服务器中运行的多个云游戏能够各自独立运行的情况下，避免服务器的资源浪费。由此可见，将本申请实施例应用于云游戏场景时，操作系统可以以高效快速地形式解决系统容器中一些细致的隔离问题，针对不同的关键函数提出相应合适的轻量化处理过程，避免了引入繁杂的处理逻辑和底层机制的修改。

基于上述对容器处理方案、方案所适用场景等的相关描述，还需说明的是：

①本申请实施例提供的容器处理方案并不仅限于应用于云游戏场景；如还可以应用于云手机场景等，云手机的原理与云游戏的原理是类似的，强调在云服务端实现手机的相关逻辑。

②本申请实施例中相关数据收集处理应该严格根据相关法律法规的要求，获取个人信息需得到个人主体的知情或同意（或具备信息获取的合法性基础），并在法律法规及个人信息主体的授权范围内，开展后续数据使用及处理行为。例如，本申请实施例运用到具体产品或技术中时，需要获得用户的许可或者同意，且相关数据的收集、使用和处理（如对象发布的弹幕的收集和发布等）需要遵守相关地区的相关法律法规和标准。

基于上述关于容器处理方案的相关描述，本申请实施例提出了一种图5所示的容器处理方法。该方法可由上述提及的计算机设备执行，该计算机设备所搭载的操作系统的Linux内核中部署有内核模块。参见图5所示，该容器处理方法可包括如下步骤S501-S504：

S501：获取用户空间中任一系统容器发送的文件操作请求。

正如前述所描述的，Linux系统的用户空间中的系统容器和内核空间主要是依靠文件抽象的形式进行通信的；也就是说，用户空间中的系统容器向内核空间进行访问时主要是访问文件，而内核空间向用户空间中的系统容器返回时也返回的是文件。因此，用户空间中的任一系统容器具有访问内核空间的需求时，可以向内核空间发起文件操作请求，此时该文件操作请求用于请求在内核空间中针对资源文件执行文件操作；其中，资源文件可以泛指内核空间中的各类文件，如系统容器对应的虚拟设备文件等等，本申请实施例对资源文件的文件类型不做限定。

应当理解的是，系统容器与内核空间之间的交互需求不同，用户空间中的不同系统容器发起的文件操作请求所请求的资源文件和针对资源文件的文件操作并不相同。下面给出两种示例性地文件操作请求，其中：

例如：在云游戏场景中，服务器中可以部署用于运行云游戏的系统容器；假设用户所使用的游戏终端中增加一个输入设备（如外接一个实体键盘等），那么该游戏终端可以上报该输入设备至服务器（具体是该服务器中运行该游戏终端中的云游戏的系统容器）。这样，服务器中的系统容器向服务器中部署Linux系统的内核空间中发起文件操作请求，此时该文件操作请求可以是用于请求在内核空间中创建该输入设备对应的虚拟设备文件，以通过该虚拟设备文件记录云游戏运行过程中与输入设备相关的数据。

再如：在云游戏场景中，如果用户使用游戏终端游玩云游戏的过程中具有获取关于输入设备的数据的需求，那么游戏终端可以向服务器发起数据获取请求，该数据获取请求用于请求服务器返回与输入设备相关的数据。服务器中的系统容器（具体是运行游戏终端中的云游戏的系统容器）在接收到游戏终端发送的数据获取请求后，可以向内核空间发起文件操作请求，此时该文件操作请求用于请求内核空间返回输入设备的虚拟设备文件。

又如：在云游戏场景中，如果用户在使用游戏终端时关闭云游戏，那么游戏终端向服务器中运行该云游戏的系统容器发起关闭请求；服务器中的系统容器接收到该关闭请求后，可以向内核空间发起文件操作请求，此时该文件操作请求用于请求在内核空间中关闭fuse用户态文件系统下的connection文件。内核空间在接收到该文件操作请求后可以仅从内核空间中删除与该系统容器相关的connection文件。

S502：响应于文件操作请求调用内核空间中的第一内核函数。

S503：根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件。

步骤S502-S503中，内核空间接收到用户空间中的任一系统容器通过系统调用发起的文件操作请求后，可以响应于该文件操作请求根据该任一系统容器的内核调用路径路由到相应的资源文件。其中，该任一系统容器的内核调用路径是指响应于文件操作请求需要调用的内核函数所组成的调用路径。应当理解的是，内核调用路径上涉及的内核函数的数量往往是多个，而多个内核函数中包括关键的内核函数或内核结构，这类关键的内核函数是指能够控制或者影响资源文件的文件操作的函数；也就是说，这类关键的内核函数具有针对资源文件执行文件操作时的具体处理逻辑，能够实现对资源文件执行文件操作。

在本申请实施例中，将内核调用路径上关键的内核函数表示为第一内核函数，该第一内核函数已经增加有容器隔离的语义；这使得该第一内核函数不仅用于指示针对资源文件执行文件操作时的处理逻辑，还用于指示系统容器的文件视图，即通过该第一内核函数能够有选择地针对当前发起文件操作请求的系统容器相关的资源文件执行文件操作。一种示例性地根据第一内核函数所指示的系统容器的文件视图，在内核空间中筛选该任一系统容器对应的资源文件的过程可以包括：获取文件标识集合，该文件标识集合中关联存储系统容器的容器标识和与相应容器标识相匹配的资源文件的文件标识；该文件标识集合是由内核空间中的子系统创建并缓存的。然后，根据用户空间中的该任一系统容器发起的文件操作请求中携带的该任一系统容器的容器标识，从文件标识集合中筛选出与该任一系统容器的容器标识相匹配的资源文件的文件标识；这样，可以基于与该任一系统容器的容器标识相匹配的资源文件的文件标识，从内核空间中扫描到与任一系统容器的容器标识相匹配的资源文件，确定与该任一系统容器的容器标识相匹配的资源文件为该任一系统容器对应的资源文件。

由此可见，本申请实施例通过对内核调用路径上的关键内核函数添加容器隔离的语义，使得添加容器隔离的语义所得的第一内核函数能够有选择的筛选允许当前发起文件操作请求的系统容器可见的资源文件；相比于未添加容器隔离的语义的内核函数对内核空间的全量资源文件进行处理而言，不仅确保系统容器通过系统调用访问到的资源文件仅为与系统容器相关，以此实现容器之间的文件隔离，而且通过修改内核函数的逻辑，以函数粒度的修改控制可以作到灵活的处理而不影响整体的内核功能，从而能够以轻量快速的方式处理容器隔离的实际问题。

S504：根据第一内核函数所指示的处理逻辑，对任一系统容器对应的资源文件进行文件操作。

应当理解的是，内核空间中不同的文件系统和系统容器发起的不同文件操作请求在内核调用路径上使用的关键内核函数和结构是不同的；例如，在proc文件系统时并不需要与存储设备进行交互，因而页缓存是不需要的，但是在ext4（Fourth extendedfilesystem，第四代扩展文件系统）文件系统中页缓存结构是文件读写的关键结构。因此，根据第一内核函数所指示的处理逻辑不同，对筛选出来的与该任一系统容器相关的资源文件执行的文件操作并不相同。

示例性地，以第一内核函数所指示的针对资源文件执行文件操作时的处理逻辑包括向系统容器返回资源文件为例，计算机设备根据第一内核函数所指示的处理逻辑针对该任一系统容器对应的资源文件进行的文件操作可以包括：根据该第一内核函数所指示的处理逻辑，将该任一系统容器对应的资源文件添加至文件缓存空间，该文件缓存空间可以是操作系统中开辟的用于缓存待返回系统容器的资源文件的内存空间。然后，将缓存至该文件缓存空间中的资源文件（即与该任一系统容器相关的资源文件）返回至该任一系统容器，以完成对该任一系统容器发起的文件操作请求的响应。

综上所述，支持对操作系统的内核空间中关键的第二内核函数进行逻辑调整，具体是增加容器隔离的语义，使得增加容器隔离的语义所得的第一内核函数（即对第二内核函数进行逻辑调整所得的内核函数）不仅能够用于指示针对内核空间中的资源文件执行文件操作时的处理逻辑，而且还用于指示操作系统的用户空间中的系统容器的文件视图（即限制系统容器的文件视图）。这样，在获取到用户空间中任一系统容器发送的文件操作请求（该文件操作请求用于请求在内核空间中针对资源文件执行文件操作）时，可以响应于该文件操作请求调用逻辑调整后的第一内核函数，并根据该第一内核函数所指示的系统容器的文件视图，有选择地从内核空间中筛选出发起本次文件操作请求的该任一系统容器对应的资源文件；相比于相关技术中调用逻辑调整前的第二内核函数选择内核空间中的全部资源文件而言，能够区分来自于不同系统容器的文件操作请求，针对不同的系统容器仅筛选相应系统容器相关的资源文件，有效限制不同系统容器的文件视图，达到较为精准的容器隔离。进一步的，在筛选到当前发起文件操作请求的该任一系统容器对应的资源文件后，仅对该任一系统容器对应的资源文件进行文件操作；相比于相关技术中未进行容器隔离时对全部资源文件进行文件操作而言，在确保该任一系统容器对应的资源文件得到文件操作的情况下，不影响用户空间中其他系统容器的运行状态，且减少文件操作所耗费的资源量，提高文件操作效率。

上述图5所示实施例是以用户空间中的任一系统容器发起文件操作请求为例，对内核空间中的关键函数被修改后的容器隔离过程进行介绍。下面结合图6所示实施例对基于ftrace hook截取关键函数以及修改相应内核机制层的逻辑的具体实施过程进行介绍。图6是本申请一个示例性实施例提供的一种容器处理方法，该方法可由上述提及的计算机设备执行，该计算机设备所搭载的操作系统的Linux内核中部署有内核模块。参见图6所示，该容器处理方法可包括如下步骤S601-S606：

S601：在内核空间中执行函数截取处理，以从内核空间中截取得到第二内核函数。

S602：按照文件视图调整策略对第二内核函数进行容器隔离处理，得到第一内核函数。

步骤S601-S602中，本申请实施例支持从内核代码层面出发，在Linux系统的内核空间中执行函数截取处理，以从内核空间中截取出第二内核函数，该第二内核函数是在内核调用路径上能够针对资源文件执行文件操作的关键函数；也就是说，该第二内核函数是前述提及的增加容器隔离语义所得到的第一内核函数对应的原内核函数。从内核空间中筛选出第二内核函数后，可以按照限制系统容器的文件视图的文件视图调整策略，对该第二内核函数进行容器隔离处理，得到第一内核函数；该第一内核函数能够限制不同系统容器在内核空间中的文件视图。

正如前述所描述的，本申请实施例支持将容器处理方案集成至内核模块，那么上述描述的函数截取处理和容器隔离处理的过程可以是由内核模块执行的。具体地，该内核模块部署于操作系统中的内核空间中，且该内核模块中包括动态检测内核函数框架ftracehook，具体可以是在内核空间中加载该内核模块的过程中，通过该内核模块中的动态检测内核函数框架ftrace hook从内核空间中截取第二内核函数，以及对该第二内核函数进行容器隔离处理，以为该第二内核函数增加容器隔离的语义。其中，关于动态检测内核函数框架ftrace hook的相关介绍可以参见前述相关描述，在此不做赘述。

考虑到不同的文件系统和文件操作请求在内核调用路径上和使用的内核关键结构是不同的，因此对不同的资源文件的视图隔离问题，需要先分析资源文件的内核调用层次，找出其关键函数（即第二内核函数），再对这些关键函数进行处理。为便于理解，下面以内核访问路径想要路由的资源文件表示为参考资源文件，或者内核空间中的任一资源文件表示为参考资源文件为例，对基于动态检测内核函数框架ftrace hook从内核空间中截取第二内核函数的过程进行介绍。具体实现中，通过内核模块中的动态检测内核函数框架ftrace hook，对参考资源文件的内核调用路径进行调用层次分析，得到内核调用路径上的一个或多个候选函数；此处的参考资源文件的内核调用路径用于指示从该内核空间中访问该参考资源文件所需经历的调用路径，而调用层次分析可以简单理解为内核调用路径上各函数的调用顺序或层次，如先调用函数1，再调用函数2等。然后，从一个或多个候选函数中筛选出能够针对参考资源文件执行文件操作的关键函数；也就是说，从一个或多个候选函数中将能够控制或影响参考文件的函数作为关键函数。这样，就可以截取该关键函数作为待进行逻辑修改的第二内核函数。

值得注意的是，根据内核空间中包括的不同文件系统的类型，采用动态检测内核函数框架ftrace hook从内核空间中截取的第二内核函数可以在内核空间中文件系统层中的虚拟文件系统的调用路径上，也可以在具体文件系统的处理上。换句话说，从内核空间中截取的第二内核函数位于访问文件系统时针对第一文件子系统层（即虚拟文件系统）的调用路径上，或者，位于访问文件系统时针对第二文件子系统层（即文件系统层中出虚拟文件系统外的用于实现文件操作的文件系统）的调用路径上。本申请实施例对采用动态检测内核函数框架ftrace hook截取的第二内核函数的位置不做限定。

进一步的，本申请实施例采用内核模块中的动态检测内核函数框架ftrace hook截取出第二内核函数后，还会对该第二内核函数修改部分逻辑，使得修改部分逻辑后的第二内核函数（在本申请实施例中称为第一内核函数）能够限制不同系统容器的文件视图，使得不同系统容器只能从内核空间中看见与自己相关的资源文件，从而达到容器隔离的目的。应当理解的是，根据从内核空间中截取的第二内核函数的不同，针对该第二内核函数执行的容器隔离处理（即增加容器隔离的语义）的具体实施方式并不相同。本申请实施例以动态检测内核函数框架ftrace hook技术为基础，创新性地引入ftrace hook技术来解决内核中特定场景隔离不足的特性导致的问题，能够从内核函数代码层面补足内核函数的功能。

更进一步的，由前述对Linux系统的相关介绍可以，Linux系统的内核空间中从上至下包括文件系统层和内核机制层。因此，为了保证内核空间的上下层的一致性，仅对内核空间中的文件系统层中的关键函数进行修改来限制系统容器的文件视图是不够的；在一些场景下，需要对内核机制层中的部分子系统的核心逻辑进行处理，以确保文件系统层可以利用内核机制层中被额外处理的部分来正确处理来自不同系统容器的隔离访问请求。举例来说，文件系统层中/dev/input对应于内核机制层中的input子系统，文件系统层中cgroup文件系统对应于内核机制层中的cgroup子系统；那么，在文件系统层中的/dev/input和cgroup的部分逻辑被修改的情况下，需对/dev/input和cgroup对应的子系统中核心部分作处理。例如，在内核机制层中的input子系统中需截取处理系统容器的输入设备结构的创建和销毁，绑定输入设备的虚拟设备文件和系统容器之间的联系。

具体实现中，基于动态检测内核函数框架ftrace hook对文件系统层中的第二内核函数进行部分逻辑修改后，若被容器隔离处理后的第一内核函数的执行需要内核空间中的内核机制层的配合，则可以从内核机制层中确定第一内核函数所访问的文件系统对应的子系统。然后，对该第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统；此处的系统逻辑调整由内核空间中的内核模块执行。示例性地，对第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整的过程可以包括：在第一内核函数所访问的文件系统对应的子系统中建立文件标识集合，该文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识。

需要说明的是，根据针对文件系统层中的不同第二内核函数的逻辑修改，为配合完成文件系统层的截取处理，在针对具体问题时截取处理第二内核函数对应的内核机制层中的子系统不同，针对子系统执行的系统逻辑调整也不相同。上述是以在子系统中创建文件标识集合为例，给出一种示例性的系统逻辑调整，并不会对本申请实施例产生限定。

此外，本申请实施例提供的内核模块包括不同的模块功能对应的模块参数；如模块功能为本申请实施例涉及的容器隔离功能，该容器隔离功能支持执行前述提及的函数截取处理，容器隔离处理和系统逻辑调整的逻辑，以限制不同系统容器的文件视图，从而达到提高容器隔离的准确性的效果。当然，内核模块中还可以集成有其他的模块功能，本申请实施例对内核模块中的集成的模块功能的数量和种类不作限定。为提高模块功能的灵活性，本申请实施例支持通过控制模块功能的模块参数，动态实现模块功能的装载和卸载。以内核模块中集成的模块功能为容器隔离功能为例，当容器隔离功能对应的模块参数被赋予第一参数值时，内核模块中的该容器隔离功能被启动，且在该容器隔离功能被启动时，该内核模块执行前述提及的函数截取处理，容器隔离处理和系统逻辑调整的操作。反之，当容器隔离功能对应的模块参数被赋予第二参数值时，内核模块中的容器隔离功能被关闭，那么内核空间可以执行自己原本的逻辑。

由此可见，本申请实施例基于内核模块，能够利用内核模块中容器隔离功能对应的模块参数实现动态装载和卸载该容器隔离功能，不仅可以方便地控制容器隔离功能的启停，而且具有良好的可管理性，避免内核空间中原本的执行逻辑被影响。

S603：获取用户空间中任一系统容器发送的文件操作请求。

S604：响应于文件操作请求调用内核空间中的第一内核函数。

S605：根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件。

S606：根据第一内核函数所指示的处理逻辑，对任一系统容器对应的资源文件进行文件操作。

需要说明的是，步骤S603-S606所示实施例的具体实施过程，与前述图5所示实施例中步骤S501-S504所示的具体实施过程是类似的，可以参见前述步骤S501-S504所示的具体实施过程的相关描述，在此不作赘述。

上述步骤S601-S606对本申请实施例提供的容器处理方法的整体技术实现进行了介绍。为便于理解，下面以本申请实施例提供的容器处理方法应用于Android系统容器，对解决Android系统容器隔离不足造成系统容器中的EventHub（Azure Event Hubs，事件流处理服务）模块的性能损失的过程进行介绍。其中，EventHub模块是Android系统容器运行时的一个关键模块，是一种事件中心，提供订阅、取消订阅和触发事件的能力；例如，用户空间中的Android系统可以基于EventHub模块处理各种输入设备的事件，如鼠标和键盘的插入事件、点击事件等等。

示例性地，EventHub模块的工作原理示意图可以参见图7；如图7所示，系统容器中的EventHub模块的底层原理是与Linux内核空间中的input子系统进行交互。详细地，input子系统将资源文件（如/dev/input/event0（Linux操作系统中第一个输入设备的文件节点路径）文件，/dev/input/event1（Linux操作系统中第二个输入设备的文件节点路径）文件等等）暴露于文件系统层中的/dev/input目录下，EventHub模块可以通过访问文件的形式获取和处理输入设备的输入事件。例如，在Linux内核空间中输入设备的输入事件（如evdev_open（Linux输入子系统的一个函数，用于打开evdev设备（采用evdev通信协议的设备）并获取其文件描述符）事件、evdev_read（Linux输入子系统的一个函数，用于从evdev设备中读取输入事件）事件和evdev_poll（Linux输入子系统的一个函数，用于轮询evdev设备的输入事件）事件等）是由input子系统中的evdev input handler（Linux输入子系统的一个处理程序，用于处理evdev设备的输入事件）控制，因此EventHub模块主要与evdevhandler（即上述的evdev input handler）进行交互。具体实现中，系统容器中的EventHub模块调用getEvents（具有读取输入设备的事件的函数）函数处理输入设备的事件的过程中，首先EventHub模块会调用scanDevicesLocked（具有扫描设备文件功能的函数）扫描文件系统层中/dev/input目录下的资源文件（如前述提及的/dev/input/event0文件，/dev/input/event1文件等等），并将扫描到的资源文件逐个打开加入epoll（event poll，事件轮询）队列，然后EventHub模块会持续调用epoll_wait（用于等待事件发生的函数）等待evdev设备的回复，最后逐个调用epoll_read（用于读取事件的函数）读取evdev设备文件中的事件信息，以实现对输入设备的事件响应。

由上述图7所示的EventHub模块的工作原理可知，由于容器隔离的不彻底，内核空间中的文件系统层中/dev/input目录下的所有资源文件（如/dev/input/event0文件，/dev/input/event1文件等等）对用户空间中的所有系统容器都可见。也就是说，即使一个系统容器通过/dev/input目录创建了一个虚拟设备的资源文件（或称为虚拟设备文件），用户空间中除该系统容器外的其他系统容器仍能看到该系统容器对应的资源文件；这样，在具有多个系统容器的主机（或服务器）上，假如每个系统容器都创建虚拟设备，那么每个Android系统容器的EventHub模块就不得不处理用户空间中全部Android系统容器中每个Android系统容器的输入设备的事件，造成系统容器的性能损耗。

为了让系统容器在文件视角层面只能看到自己创建的虚拟设备的资源文件，即每个系统容器只能看到自己需要的/dev/input目录下的资源文件，让系统容器的EventHub模块只需处理属于该系统容器的虚拟设备的事件。本申请实施例支持在文件系统层截取处理/dev/input目录的文件操作，具体是在文件系统层中找到访问/dev/input目录的关键函数。传统的查看/dev/input目录的调用示意图可以参见图8；如图8所示，在Linux系统中iterate_dir（是一种Linux函数，通常用于遍历指定目录下的所有文件和子目录）函数是获取/dev/input目录下文件的文件操作接口，通过该函数会调用/dev/input目录文件的iterate（是一种用于实现读取目录内容的函数接口）或者iterate_shared（是一种用于实现读取目录内容的函数接口）方法，这些方法指向了/dev/input文件的目录项获取的具体实现。进一步的，/dev/input目录的底层文件系统是设备临时文件系统（device temporaryfile system，devtmpfs），其本质是ramfs文件系统或者shmemfs（Shared Memory FileSystem，基于分享的内存文件系统），这两种文件系统在实现目录项的文件操作时统一使用了Linux文件系统提供的libfs（是Linux内核提供的一个函数集）中的文件操作方法实现，即simple_dir_operations（一种简单的目录操作）函数，因此负责/dev/input目录项获取的具体实现函数是simple_dir_operations中的dcache_readdir（与目录缓存相关的读取操作）函数，从而可以将该dcache_readdir函数作为内核调用路径上的关键函数。通过该关键函数扫描父目录dentry下所属的子目录dentry目录项，可以将目录列表以一定的格式写入用户空间的缓存（即写入文件缓存空间）。

基于上述描述从文件系统层中截取出关键内核函数（即第二内核函数）dcache_readdir后，本申请实施例支持针对该dcache_readdir函数改写例程中往用户空间写目录项内容的逻辑。具体地，不同于dcache_readdir函数原本直接向系统容器的文件缓存空间中写入整个目录列表的资源文件，改写后的dcache_readdir函数支持使用当前发起文件操作请求的容器标识（如pid_namespace（进程ID（Identification，标识号）命名空间）标识）来标识不同系统容器发起的文件操作请求；这样，在往文件缓存空间中填充资源文件时，根据系统容器所属的文件操作请求有选择地将希望该系统容器看到目录列表内容（即与该系统容器相关的资源文件）写入文件缓存空间中。在系统容器的文件视角，系统容器通过系统调用从内核空间中访问到的资源文件均是与该系统容器相关的，以此实现系统容器之间的文件隔离。

应当理解的是，在文件系统层要正确的判断哪些资源文件应返回给当前发起文件操作请求的系统容器，就需要确认系统容器和对应资源文件之间的关系，而文件系统层并不包含系统容器和资源文件的关系；此情况下，需要对内核空间中内核机制层中的input子系统作出一些配合，具体创建文件标识集合，该文件标识集合中关联存储系统容器和相关的资源文件，即通过该文件标识集合对该input子系统建立系统容器和其对应的资源文件的联系。其中，建立系统容器和对应的资源文件的联系的大致思路是：截取系统容器对应的虚拟设备的创建和销毁过程，在evdev handler为虚拟设备创建handle（句柄，是指核心对象在进程中的唯一索引）和资源文件的过程中，使用系统容器的容器标识pid_namespace主动标识每个资源文件，记录资源文件和相应的系统容器之间的联系。具体做法是截取evdev_connect（用于建立用户空间程序与evdev设备之间的连接的函数）函数和evdev_disconnect（用于断开用户空间程序与evdev设备之间的连接的函数）函数，这两个函数负责为每个虚拟设备（如输入设备）创建和销毁evdev资源文件，在每次evdev_connect被调用时使用当前发起文件操作请求的系统容器的pid_namespace标识该过程创建的/dev/input目录下的资源文件。这样，当访问/dev/input目录调用第一内核函数dcache_readdir时，便可以根据当前发起文件操作请求的pid_namespace标识（即容器标识）和/dev/input目录下当前系统容器的容器标识pid_namespace所标识的资源文件，来判断资源文件是否对当前系统容器可见。

基于上述对关键函数dcache_readdir和input子系统的调整，用户空间中的任一系统容器发起文件操作请求时关于/dev/input目录的调用流程示意图可以参见图9。如图9所示，通过加载内核空间中的内核模块，可以预先在内核机制层中建立系统容器和与该系统容器相关的资源文件的联系（即建立文件标识集合）。在用户空间中的任一系统容器通过命令行#Is /dev/input（用于实现用户和设备进行交互的命令行）发起文件操作请求时，文件系统层中的第一内核函数dcache_readdir在调用scan_positives（能够进行扫描的函数）函数扫描目录项时，不再是全部扫描，而是根据内核机制层中建立的文件标识集合选择性地将目录项中扫描到的与当前发起文件操作请求的系统容器相关的资源文件填充至文件缓存空间中。由此可见，本申请实施例通过侵入文件系统层和内核机制层，可以限制系统容器的文件视图，防止系统容器访问属于其他系统容器的资源文件，增强系统容器运行的独立性，以轻量化的内核函数修改和高灵活性的处理方式，提供了解决因隔离不彻底可能带来的容器运行问题。

综上所述，支持对操作系统的内核空间中关键的第二内核函数进行逻辑调整，具体是增加容器隔离的语义，使得增加容器隔离的语义所得的第一内核函数（即对第二内核函数进行逻辑调整所得的内核函数）不仅能够用于指示针对内核空间中的资源文件执行文件操作时的处理逻辑，而且还用于指示操作系统的用户空间中的系统容器的文件视图（即限制系统容器的文件视图）。这样，在获取到用户空间中任一系统容器发送的文件操作请求（该文件操作请求用于请求在内核空间中针对资源文件执行文件操作）时，可以响应于该文件操作请求调用逻辑调整后的第一内核函数，并根据该第一内核函数所指示的系统容器的文件视图，有选择地从内核空间中筛选出发起本次文件操作请求的该任一系统容器对应的资源文件；相比于相关技术中调用逻辑调整前的第二内核函数选择内核空间中的全部资源文件而言，能够区分来自于不同系统容器的文件操作请求，针对不同的系统容器仅筛选相应系统容器相关的资源文件，有效限制不同系统容器的文件视图，达到较为精准的容器隔离。进一步的，在筛选到当前发起文件操作请求的该任一系统容器对应的资源文件后，仅对该任一系统容器对应的资源文件进行文件操作；相比于相关技术中未进行容器隔离时对全部资源文件进行文件操作而言，在确保该任一系统容器对应的资源文件得到文件操作的情况下，不影响用户空间中其他系统容器的运行状态，且减少文件操作所耗费的资源量，提高文件操作效率。此外，本申请实施例基于内核模块，利用内核模块中的模块功能的模块参数，能够实现动态装载和卸载模块功能，方便控制模块功能的启停，具有良好的可管理性。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面提供了本申请实施例的装置。本申请实施例中，术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分，并与其他相关部分一起工作以实现预定目标，并且可以通过使用软件、硬件（如处理电路或存储器）或其组合来全部或部分实现。同样的，一个处理器（或多个处理器或存储器）可以用来实现一个或多个模块或单元。此外，每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。

图10示出了本申请一个示例性实施例提供的一种容器处理装置的结构示意图；该容器处理装置可以是运行于计算机设备的一个计算机程序（包括程序代码），例如该容器处理装置可以是计算机设备的应用程序或是芯片内的计算机程序；该容器处理装置可以用于执行图5和图6所示的方法实施例中的部分或全部步骤。请参见图10，该容器处理装置搭载有操作系统，操作系统中包括用户空间和内核空间；内核空间中包含多个系统容器，多个系统容器中的第一系统容器允许访问第二系统容器的资源文件，第一系统容器和第二系统容器不同；该装置包括：

获取单元1001，用于获取用户空间中任一系统容器发送的文件操作请求，文件操作请求用于请求在内核空间中针对资源文件执行文件操作；

处理单元1002，用于响应于文件操作请求调用内核空间中的第一内核函数；第一内核函数用于指示系统容器的文件视图以及针对文件视图内的资源文件执行文件操作时的处理逻辑；

处理单元1002，还用于根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件；

处理单元1002，还用于根据第一内核函数所指示的处理逻辑，对任一系统容器对应的资源文件进行文件操作。

在一种实现方式中，文件操作请求中携带任一系统容器的容器标识；第一内核函数所指示的系统容器的文件视图包括：系统容器对内核空间中与相应系统容器的容器标识相匹配的资源文件具有视图权限；处理单元1002，用于根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件时，具体用于：

获取文件标识集合；文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识；

根据任一系统容器的容器标识，从文件标识集合中筛选出与任一系统容器的容器标识相匹配的资源文件的文件标识；

基于与任一系统容器的容器标识相匹配的资源文件的文件标识，从所述内核空间中扫描到与所述任一系统容器的容器标识相匹配的资源文件；与所述任一系统容器的容器标识相匹配的资源文件为所述任一系统容器对应的资源文件。

在一种实现方式中，第一内核函数所指示的处理逻辑包括向系统容器返回资源文件；处理单元1002，用于根据所述第一内核函数所指示的处理逻辑，对所述任一系统容器对应的资源文件进行文件操作时，具体用于：

根据所述第一内核函数所指示的处理逻辑，将所述任一系统容器对应的资源文件添加至文件缓存空间；

将所述文件缓存空间中的资源文件返回至所述任一系统容器。

在一种实现方式中，处理单元1002，还用于：

在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数；所述第二内核函数是指在内核调用路径上能够针对资源文件执行文件操作的关键函数；

按照文件视图调整策略对所述第二内核函数进行容器隔离处理，得到第一内核函数；

其中，所述第一内核函数能够限制不同系统容器在所述内核空间中的文件视图。

在一种实现方式中，函数截取处理和所述容器隔离处理是由内核模块执行，所述内核模块部署于所述操作系统中的所述内核空间中，且所述内核模块中包括动态检测内核函数框架；

处理单元1002，用于在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数时，具体用于：

在所述内核空间中加载所述内核模块的过程中，通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数。

在一种实现方式中，内核空间中的任一资源文件表示为参考资源文件；处理单元1002，用于通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数时，具体用于：

通过所述内核模块中的所述动态检测内核函数框架，对所述参考资源文件的内核调用路径进行调用层次分析，得到所述内核调用路径上的一个或多个候选函数；所述参考资源文件的内核调用路径指示访问所述参考资源文件所需经历的调用路径；

从所述一个或多个候选函数中筛选出能够针对所述参考资源文件执行文件操作的关键函数；

截取所述关键函数作为第二内核函数。

在一种实现方式中，内核空间中包括文件系统层，所述文件系统层中包括第一文件子系统层和第二文件子系统层；所述第二文件子系统层中包括至少一个文件系统，所述文件系统中包括资源文件及与资源文件相关的处理逻辑；所述第一文件子系统层为所述第二文件子系统层中的每个文件系统提供调用接口；

其中，从所述内核空间中截取的第二内核函数位于访问文件系统时针对所述第一文件子系统层的调用路径上，或者，位于访问文件系统时针对所述第二文件子系统层的调用路径上。

在一种实现方式中，内核空间中还包括内核机制层；所述内核机制层中包括至少一个子系统，一个子系统与所述文件系统层中的一个文件系统对应；处理单元1002，还用于：

若所述文件系统层中被容器隔离处理后的所述第一内核函数的执行需要所述内核机制层的配合，则从所述内核机制层中确定所述第一内核函数所访问的文件系统对应的子系统；

对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统；所述系统逻辑调整由所述内核空间中的内核模块执行。

在一种实现方式中，处理单元1002，还用于对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统时，具体用于：

在所述第一内核函数所访问的文件系统对应的子系统中建立文件标识集合；所述文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识。

在一种实现方式中，内核模块中包括容器隔离功能对应的模块参数；所述容器隔离功能被启动时所述内核模块执行所述函数截取处理，所述容器隔离处理和所述系统逻辑调整；

当所述容器隔离功能对应的模块参数被赋予第一参数值时，所述内核模块中的所述容器隔离功能被启动；

当所述容器隔离功能对应的模块参数被赋予第二参数值时，所述内核模块中的所述容器隔离功能被关闭。

根据本申请的一个实施例，图10所示的容器处理装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成，或者其中的某个（些）单元还可以再拆分为功能上更小的多个单元来构成，这可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的，在实际应用中，一个单元的功能也可以由多个单元来实现，或者多个单元的功能由一个单元实现。在本申请的其它实施例中，该容器处理装置也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。根据本申请的另一个实施例，可以通过在包括中央处理单元（CPU）、随机存取存储介质（Random Access Memory，RAM）、只读存储介质（Read-Only Memory，ROM）等处理元件和存储元件的例如计算机的通用计算设备上运行能够执行如图5或图6所示的相应方法所涉及的各步骤的计算机程序（包括程序代码），来构造如图10中所示的容器处理装置，以及来实现本申请实施例的容器处理方法。计算机程序可以记载于例如计算机可读记录介质上，并通过计算机可读记录介质装载于上述计算设备中，并在其中运行。

在本申请实施例中，支持对操作系统的内核空间中关键的第二内核函数进行逻辑调整，具体是增加容器隔离的语义，使得增加容器隔离的语义所得的第一内核函数（即对第二内核函数进行逻辑调整所得的内核函数）不仅能够用于指示针对内核空间中的资源文件执行文件操作时的处理逻辑，而且还用于指示操作系统的用户空间中的系统容器的文件视图（即限制系统容器的文件视图）。这样，在获取到用户空间中任一系统容器发送的文件操作请求（该文件操作请求用于请求在内核空间中针对资源文件执行文件操作）时，可以响应于该文件操作请求调用逻辑调整后的第一内核函数，并根据该第一内核函数所指示的系统容器的文件视图，有选择地从内核空间中筛选出发起本次文件操作请求的该任一系统容器对应的资源文件；相比于相关技术中调用逻辑调整前的第二内核函数选择内核空间中的全部资源文件而言，能够区分来自于不同系统容器的文件操作请求，针对不同的系统容器仅筛选相应系统容器相关的资源文件，有效限制不同系统容器的文件视图，达到较为精准的容器隔离。进一步的，在筛选到当前发起文件操作请求的该任一系统容器对应的资源文件后，仅对该任一系统容器对应的资源文件进行文件操作；相比于相关技术中未进行容器隔离时对全部资源文件进行文件操作而言，在确保该任一系统容器对应的资源文件得到文件操作的情况下，不影响用户空间中其他系统容器的运行状态，且减少文件操作所耗费的资源量，提高文件操作效率。此外，本申请实施例基于内核模块，利用内核模块中的模块功能的模块参数，能够实现动态装载和卸载模块功能，方便控制模块功能的启停，具有良好的可管理性。

图11示出了本申请一个示例性实施例提供的一种计算机设备的结构示意图。请参见图11，该计算机设备包括处理器1101、通信接口1102以及计算机可读存储介质1103。其中，处理器1101、通信接口1102以及计算机可读存储介质1103可通过总线或者其它方式连接。其中，通信接口1102用于接收和发送数据。计算机可读存储介质1103可以存储在计算机设备的存储器中，计算机可读存储介质1103用于存储计算机程序，计算机程序包括程序指令，处理器1101用于执行计算机可读存储介质1103存储的程序指令。处理器1101（或称CPU（Central Processing Unit，中央处理器））是计算机设备的计算核心以及控制核心，其适于实现一条或多条指令，具体适于加载并执行一条或多条指令从而实现相应方法流程或相应功能。

本申请实施例还提供了一种计算机可读存储介质（Memory），计算机可读存储介质是计算机设备中的记忆设备，用于存放程序和数据。可以理解的是，此处的计算机可读存储介质既可以包括计算机设备中的内置存储介质，当然也可以包括计算机设备所支持的扩展存储介质。计算机可读存储介质提供存储空间，该存储空间存储了计算机设备的处理系统。并且，在该存储空间中还存放了适于被处理器1101加载并执行的一条或多条的指令，这些指令可以是一个或多个的计算机程序（包括程序代码）。需要说明的是，此处的计算机可读存储介质可以是高速RAM存储器，也可以是非不稳定的存储器（non-volatile memory），例如至少一个磁盘存储器；可选的，还可以是至少一个位于远离前述处理器的计算机可读存储介质。

在一个实施例中，该计算机可读存储介质中存储有一条或多条指令；由处理器1101加载并执行计算机可读存储介质中存放的一条或多条指令，以实现上述容器处理方法实施例中的相应步骤；具体实现中，该计算机设备中搭载有操作系统，操作系统中包括用户空间和内核空间；内核空间中包含多个系统容器，多个系统容器中的第一系统容器允许访问第二系统容器的资源文件，第一系统容器和第二系统容器不同；计算机可读存储介质中的一条或多条指令由处理器1101加载并执行如下步骤：

获取用户空间中任一系统容器发送的文件操作请求，文件操作请求用于请求在内核空间中针对资源文件执行文件操作；

响应于文件操作请求调用内核空间中的第一内核函数；第一内核函数用于指示系统容器的文件视图以及针对文件视图内的资源文件执行文件操作时的处理逻辑；

根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件；

根据第一内核函数所指示的处理逻辑，对任一系统容器对应的资源文件进行文件操作。

在一种实现方式中，文件操作请求中携带任一系统容器的容器标识；第一内核函数所指示的系统容器的文件视图包括：系统容器对内核空间中与相应系统容器的容器标识相匹配的资源文件具有视图权限；计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行根据第一内核函数所指示系统容器的文件视图，在内核空间中筛选出任一系统容器对应的资源文件时，具体执行如下步骤：

获取文件标识集合；文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识；

根据任一系统容器的容器标识，从文件标识集合中筛选出与任一系统容器的容器标识相匹配的资源文件的文件标识；

基于与任一系统容器的容器标识相匹配的资源文件的文件标识，从所述内核空间中扫描到与所述任一系统容器的容器标识相匹配的资源文件；与所述任一系统容器的容器标识相匹配的资源文件为所述任一系统容器对应的资源文件。

在一种实现方式中，第一内核函数所指示的处理逻辑包括向系统容器返回资源文件；计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行根据所述第一内核函数所指示的处理逻辑，对所述任一系统容器对应的资源文件进行文件操作时，具体执行如下步骤：

根据所述第一内核函数所指示的处理逻辑，将所述任一系统容器对应的资源文件添加至文件缓存空间；

将所述文件缓存空间中的资源文件返回至所述任一系统容器。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1101加载并还执行如下步骤：

在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数；所述第二内核函数是指在内核调用路径上能够针对资源文件执行文件操作的关键函数；

按照文件视图调整策略对所述第二内核函数进行容器隔离处理，得到第一内核函数；

其中，所述第一内核函数能够限制不同系统容器在所述内核空间中的文件视图。

在一种实现方式中，函数截取处理和所述容器隔离处理是由内核模块执行，所述内核模块部署于所述操作系统中的所述内核空间中，且所述内核模块中包括动态检测内核函数框架；

计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数时，具体执行如下步骤：

在所述内核空间中加载所述内核模块的过程中，通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数。

在一种实现方式中，内核空间中的任一资源文件表示为参考资源文件；计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数时，具体执行如下步骤：

通过所述内核模块中的所述动态检测内核函数框架，对所述参考资源文件的内核调用路径进行调用层次分析，得到所述内核调用路径上的一个或多个候选函数；所述参考资源文件的内核调用路径指示访问所述参考资源文件所需经历的调用路径；

从所述一个或多个候选函数中筛选出能够针对所述参考资源文件执行文件操作的关键函数；

截取所述关键函数作为第二内核函数。

在一种实现方式中，内核空间中包括文件系统层，所述文件系统层中包括第一文件子系统层和第二文件子系统层；所述第二文件子系统层中包括至少一个文件系统，所述文件系统中包括资源文件及与资源文件相关的处理逻辑；所述第一文件子系统层为所述第二文件子系统层中的每个文件系统提供调用接口；

其中，从所述内核空间中截取的第二内核函数位于访问文件系统时针对所述第一文件子系统层的调用路径上，或者，位于访问文件系统时针对所述第二文件子系统层的调用路径上。

在一种实现方式中，内核空间中还包括内核机制层；所述内核机制层中包括至少一个子系统，一个子系统与所述文件系统层中的一个文件系统对应；计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行如下步骤：

若所述文件系统层中被容器隔离处理后的所述第一内核函数的执行需要所述内核机制层的配合，则从所述内核机制层中确定所述第一内核函数所访问的文件系统对应的子系统；

对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统；所述系统逻辑调整由所述内核空间中的内核模块执行。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统时，具体执行如下步骤：

在所述第一内核函数所访问的文件系统对应的子系统中建立文件标识集合；所述文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识。

在一种实现方式中，内核模块中包括容器隔离功能对应的模块参数；所述容器隔离功能被启动时所述内核模块执行所述函数截取处理，所述容器隔离处理和所述系统逻辑调整；

当所述容器隔离功能对应的模块参数被赋予第一参数值时，所述内核模块中的所述容器隔离功能被启动；

当所述容器隔离功能对应的模块参数被赋予第二参数值时，所述内核模块中的所述容器隔离功能被关闭。

在本申请实施例中，支持对操作系统的内核空间中关键的第二内核函数进行逻辑调整，具体是增加容器隔离的语义，使得增加容器隔离的语义所得的第一内核函数（即对第二内核函数进行逻辑调整所得的内核函数）不仅能够用于指示针对内核空间中的资源文件执行文件操作时的处理逻辑，而且还用于指示操作系统的用户空间中的系统容器的文件视图（即限制系统容器的文件视图）。这样，在获取到用户空间中任一系统容器发送的文件操作请求（该文件操作请求用于请求在内核空间中针对资源文件执行文件操作）时，可以响应于该文件操作请求调用逻辑调整后的第一内核函数，并根据该第一内核函数所指示的系统容器的文件视图，有选择地从内核空间中筛选出发起本次文件操作请求的该任一系统容器对应的资源文件；相比于相关技术中调用逻辑调整前的第二内核函数选择内核空间中的全部资源文件而言，能够区分来自于不同系统容器的文件操作请求，针对不同的系统容器仅筛选相应系统容器相关的资源文件，有效限制不同系统容器的文件视图，达到较为精准的容器隔离。进一步的，在筛选到当前发起文件操作请求的该任一系统容器对应的资源文件后，仅对该任一系统容器对应的资源文件进行文件操作；相比于相关技术中未进行容器隔离时对全部资源文件进行文件操作而言，在确保该任一系统容器对应的资源文件得到文件操作的情况下，不影响用户空间中其他系统容器的运行状态，且减少文件操作所耗费的资源量，提高文件操作效率。此外，本申请实施例基于内核模块，利用内核模块中的模块功能的模块参数，能够实现动态装载和卸载模块功能，方便控制模块功能的启停，具有良好的可管理性。

本申请提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述容器处理方法。

本领域普通技术对象可以意识到，结合本申请中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术对象可以对每个特定的应用，使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程设备。计算机指令可以存储在计算机可读存储介质中，或者通过计算机可读存储介质进行传输。计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如，同轴电缆、光纤、数字线（Digital Subscriber Line，DSL））或无线（例如，红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据处理设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD（Digital Versatile Disc，数字视频光盘）)、或者半导体介质（例如，固态硬盘(Solid State Disk，SSD)）等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术对象在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (14)

1.一种容器处理方法，其特征在于，应用于操作系统，所述操作系统中包括用户空间和内核空间；所述用户空间中包括多个系统容器，多个所述系统容器中的第一系统容器允许访问第二系统容器的资源文件，所述第一系统容器和所述第二系统容器不同；所述方法包括：

获取所述用户空间中任一系统容器发送的文件操作请求，所述文件操作请求用于请求在所述内核空间中针对资源文件执行文件操作；

响应于所述文件操作请求调用所述内核空间中的第一内核函数；所述第一内核函数用于指示系统容器的文件视图以及针对资源文件执行文件操作时的处理逻辑；

根据所述第一内核函数所指示系统容器的文件视图，在所述内核空间中筛选出所述任一系统容器对应的资源文件；

根据所述第一内核函数所指示的处理逻辑，对所述任一系统容器对应的资源文件进行文件操作。

2.如权利要求1所述的方法，其特征在于，所述文件操作请求中携带所述任一系统容器的容器标识；所述第一内核函数所指示的系统容器的文件视图包括：系统容器对所述内核空间中与相应系统容器的容器标识相匹配的资源文件具有视图权限；所述根据所述第一内核函数所指示系统容器的文件视图，在所述内核空间中筛选出所述任一系统容器对应的资源文件，包括：

获取文件标识集合；所述文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识；

根据所述任一系统容器的容器标识，从所述文件标识集合中筛选出与所述任一系统容器的容器标识相匹配的资源文件的文件标识；

基于与所述任一系统容器的容器标识相匹配的资源文件的文件标识，从所述内核空间中扫描到与所述任一系统容器的容器标识相匹配的资源文件；与所述任一系统容器的容器标识相匹配的资源文件为所述任一系统容器对应的资源文件。

3.如权利要求1所述的方法，其特征在于，所述第一内核函数所指示的处理逻辑包括向系统容器返回资源文件；所述根据所述第一内核函数所指示的处理逻辑，对所述任一系统容器对应的资源文件进行文件操作，包括：

根据所述第一内核函数所指示的处理逻辑，将所述任一系统容器对应的资源文件添加至文件缓存空间；

将所述文件缓存空间中的资源文件返回至所述任一系统容器。

4.如权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数；所述第二内核函数是指在内核调用路径上能够针对资源文件执行文件操作的关键函数；

按照文件视图调整策略对所述第二内核函数进行容器隔离处理，得到第一内核函数；

其中，所述第一内核函数能够限制不同系统容器在所述内核空间中的文件视图。

5.如权利要求4所述的方法，其特征在于，所述函数截取处理和所述容器隔离处理是由内核模块执行，所述内核模块部署于所述操作系统中的所述内核空间中，且所述内核模块中包括动态检测内核函数框架；

所述在所述内核空间中执行函数截取处理，以从所述内核空间中截取得到第二内核函数，包括：

在所述内核空间中加载所述内核模块的过程中，通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数。

6.如权利要求5所述的方法，其特征在于，所述内核空间中的任一资源文件表示为参考资源文件；所述通过所述内核模块中的所述动态检测内核函数框架，从所述内核空间中截取第二内核函数，包括：

通过所述内核模块中的所述动态检测内核函数框架，对所述参考资源文件的内核调用路径进行调用层次分析，得到所述内核调用路径上的一个或多个候选函数；所述参考资源文件的内核调用路径指示访问所述参考资源文件所需经历的调用路径；

从所述一个或多个候选函数中筛选出能够针对所述参考资源文件执行文件操作的关键函数；

截取所述关键函数作为第二内核函数。

7.如权利要求4所述的方法，其特征在于，所述内核空间中包括文件系统层，所述文件系统层中包括第一文件子系统层和第二文件子系统层；所述第二文件子系统层中包括至少一个文件系统，所述文件系统中包括资源文件及与资源文件相关的处理逻辑；所述第一文件子系统层为所述第二文件子系统层中的每个文件系统提供调用接口；

其中，从所述内核空间中截取的第二内核函数位于访问文件系统时针对所述第一文件子系统层的调用路径上，或者，位于访问文件系统时针对所述第二文件子系统层的调用路径上。

8.如权利要求7所述的方法，其特征在于，所述内核空间中还包括内核机制层；所述内核机制层中包括至少一个子系统，一个子系统与所述文件系统层中的一个文件系统对应；所述方法还包括：

若所述文件系统层中被容器隔离处理后的所述第一内核函数的执行需要所述内核机制层的配合，则从所述内核机制层中确定所述第一内核函数所访问的文件系统对应的子系统；

对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统；所述系统逻辑调整由所述内核空间中的内核模块执行。

9.如权利要求8所述的方法，其特征在于，所述对所述第一内核函数所访问的文件系统对应的子系统进行系统逻辑调整，得到调整后的子系统，包括：

在所述第一内核函数所访问的文件系统对应的子系统中建立文件标识集合；所述文件标识集合中关联存储容器标识和与相应容器标识相匹配的资源文件的文件标识。

10.如权利要求7所述的方法，其特征在于，所述内核模块中包括容器隔离功能对应的模块参数；所述容器隔离功能被启动时所述内核模块执行所述函数截取处理，所述容器隔离处理和系统逻辑调整；

当所述容器隔离功能对应的模块参数被赋予第一参数值时，所述内核模块中的所述容器隔离功能被启动；

当所述容器隔离功能对应的模块参数被赋予第二参数值时，所述内核模块中的所述容器隔离功能被关闭。

11.一种容器处理装置，其特征在于，所述装置搭载于操作系统，所述操作系统中包括用户空间和内核空间；所述内核空间中包含多个系统容器，多个所述系统容器中的第一系统容器允许访问第二系统容器的资源文件，所述第一系统容器和所述第二系统容器不同，所述装置包括：

获取单元，用于获取所述用户空间中任一系统容器发送的文件操作请求，所述文件操作请求用于请求在所述内核空间中针对资源文件执行文件操作；

处理单元，用于响应于所述文件操作请求调用所述内核空间中的第一内核函数；所述第一内核函数用于指示系统容器的文件视图以及针对文件视图内的资源文件执行文件操作时的处理逻辑；

所述处理单元，还用于根据所述第一内核函数所指示系统容器的文件视图，在所述内核空间中筛选出所述任一系统容器对应的资源文件；

所述处理单元，还用于根据所述第一内核函数所指示的处理逻辑，对所述任一系统容器对应的资源文件进行文件操作。

12.一种计算机设备，其特征在于，包括：

处理器，适于执行计算机程序；

计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被所述处理器执行时，实现如权利要求1-10任一项所述的容器处理方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于由处理器加载并执行如权利要求1-10任一项所述的容器处理方法。

14.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机指令，所述计算机指令被处理器执行时实现如权利要求1-10任一项所述的容器处理方法。