CN113360242A - 通过在标准运行时中横向重用能力的框架不可知的敏捷容器启动 - Google Patents
通过在标准运行时中横向重用能力的框架不可知的敏捷容器启动 Download PDFInfo
- Publication number
- CN113360242A CN113360242A CN202011535887.6A CN202011535887A CN113360242A CN 113360242 A CN113360242 A CN 113360242A CN 202011535887 A CN202011535887 A CN 202011535887A CN 113360242 A CN113360242 A CN 113360242A
- Authority
- CN
- China
- Prior art keywords
- capabilities
- software container
- request
- threshold
- container
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44568—Immediately runnable code
- G06F9/44578—Preparing or optimising for loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
系统、设备和方法可以提供一种技术,该技术:在发出创建容器的请求之前创建软件容器的一个或多个能力,其中一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联;在创建一个或多个能力后,拦截创建软件容器的请求;以及将一个或多个能力与软件容器进行关联。
Description
相关申请的交叉引用
本申请要求2020年3月4日提交的美国临时专利申请号62/984,829的优先权权益。
技术领域
实施例总体上涉及计算系统。更具体地,实施例涉及通过在标准运行时中横向重用能力来实现框架不可知的敏捷容器启动的计算系统。
背景技术
容器模型正在整个云生态系统中获得快速采用,并且可能是平台独立、资源高效且高度可扩展的快速应用部署的基础。进一步地,技术和业务需求可能使容器成为“按需”部署应用的主要手段,尤其是在依赖于高度动态和轻量级编排的较新的快速增长的业务模型中。容器已成为使用虚拟硬件机(VM)的一种越来越流行的替代品,因为它能够实现应用、微服务的更密集、更具响应性和按需执行以及实现用于按需计算的事件触发的、小型、运行到完成单元的功能即服务(FaaS)。
附图说明
通过阅读以下说明书和所附权利要求并通过参考以下附图,实施例的各种优势对本领域技术人员将变得显而易见,其中:
图1是常规的容器管理架构的示例的框图;
图2是根据实施例的管理容器能力的方法的示例的流程图;
图3是根据实施例的容器管理架构的示例的框图;
图4是根据实施例的横向能力重用的示例的框图;
图5是根据实施例的软件堆栈的示例的框图;
图6是根据实施例的网络命名空间创建的示例的流程图;
图7是根据实施例的能力管理器的示例的框图;
图8A和图8B是根据实施例的操作性能增强的计算系统的方法的示例的流程图;
图9是一组常规结果与根据实施例的结果的示例的比较图;
图10是根据实施例的数据结构的示例的框图;
图11是根据实施例的跨框架横向重用的示例的框图;
图12是根据实施例的转换和重用解决方案的递归或迭代应用的示例的框图;
图13是根据实施例的性能增强的计算系统的示例的框图;
图14是根据实施例的半导体设备的示例的图示;
图15是根据实施例的处理器的示例的框图;以及
图16是根据实施例的基于多处理器的计算系统的示例的框图。
具体实施方式
容器冷启动性能瓶颈是云服务提供商面临的重要问题。并发容器启动可能是不可避免的,尤其是在FaaS模型中。研究表明,在并发情况下,冷启动等待时间会增加。
云服务提供商或开发人员可能已经采用了一些替代方法来克服冷启动问题。它们是:预加热容器——从特定的运行时启动的通用预初始化容器,使得针对同一运行时和依赖项的任何操作都可以快速进行;加热容器——被保存在存储器中并在存储器中可运行的用于动作的先前使用的容器,使得同一动作的后续实例可以使用它们——既节省了启动新容器的时间,又节省了拉入要执行的代码的时间;定期加热容器——开发人员经常将此技术用作黑客手段——通过人为地要求容器做虚拟工作来使容器保持加热。
特定于环境的预加热容器不能广泛地重用。因此,很难证明浪费大量存储器来使其保持常备是合理的。但是,如果只保存少量,那么需求的突然飙升无论如何将迫使冷启动。加热容器消耗更多的存储器/存储,并且可能出现问题,除非预期特定活动足够频繁地发生。定期加热容器具有与加热容器相同的缺点。
常规可能发生的情况在图1的架构20中示出。当容器需要启动时,它创建其所需的数个能力中的每一个(X1……Xn)。一旦构建了容器,程序就在容器内部执行,然后在程序完成时启动拆除容器。现在将销毁所有创建的能力,然后销毁容器。如果比方说一些能力(诸如XK+1、……、Xn)创建起来在计算上很昂贵,即使它们不需要太多的存储器容量,则此流程也很昂贵。
诸如容器的网络命名空间之类的一些能力在计算上是昂贵的,但是并非存储器容量密集的。在如图2的过程流程22中所描绘的实施例中,这些计算上昂贵但并非存储器容量密集的能力是在外壳容器中预创建的(24),并由能力特定的管理器管理(26)。在编排/准备流程中最低级别处的创建服务的端口地址处拦截容器创建流程(28)。在此时,容器配置被重写(30),并提供给标准创建引擎。重写的配置使引擎(例如,Docker引擎、CRI/容器运行时接口)通过附接到外壳容器来获取预创建的能力(32)(而不是按需创建能力)。重写引擎(例如,转换器)是云/容器框架不可知的,并且与事实上的标准(“containerd(容器化)”和“runc(运行时)”)兼容,因为重写引擎利用了作为这些事实上的标准引擎(容器化、运行时等)基础的按指示构建范式。
在完成在创建的容器内运行的程序时,即,在退出时间(33),将所获取的每个能力(32)被从容器释放(34)到能力管理器,该能力管理器可以回收由此释放的所获取的能力,将其重新初始化,或根据可编程策略以某一其他方式管理其生命周期。本文提供的结果表明,当将本文描述的技术应用于网络命名空间创建时,其可在容器启动上实现近25倍的改进,并使容器启动具有可预测的低等待时间;同时还证明它无缝集成到标准容器运行时环境中,并且可以在不同的编排堆栈上使用。与网络命名空间一样,可以类似地管理其他能力:例如,可以针对主处理器(例如,中央处理单元/CPU)的硬件(HW)和/或平台特征自定义或优化外壳容器,而无需复杂化应用软件的更高层级。此类方法可以透明地受益于定制。
图2展示了可以预创建计算上昂贵的能力并将其提供给容器创建流程,而不是按需创建每个能力。为此,该技术拦截创建流程,并重写其能力创建,使得可以获取预创建的能力,而不是按需创建。同样,在销毁容器时,销毁流程被拦截以处理这些能力;如果合适,可以池化此类能力并根据需要重新初始化以供未来重用。
现在转到图3,代替高速缓存所有的资源(其在存储器和/或存储方面可能是相对昂贵的),本文描述的技术包括架构40,该架构40通过在创建时重写其配置来重新剪裁容器的创建。一些能力可能无法池化(例如,出于安全原因)。对于此类能力,此方法可通过提前预创建来减少在需求高峰下的等待时间和锁定争用。确实,对于最昂贵的能力之一(即,容器的网络设置),可以在重用网络命名空间并通过对池化的命名空间的随机创建和销毁进行混合的同时处理安全性,但无法预测连续用户、容器之间的对应关系且无法预测容器的使用情况。
因此,图3示出了示例,其中已知原始集合{X1、……、Xn}中的能力XK+1……Xn的子集创建起来很昂贵,但是在存储器中保持常备却并不昂贵。这些能力基于策略和配置自动化支持(47)(例如,策略数据)被重写(41)、被提供(43)并通过“横向”布置被返回(45)。
图4更详细地示出了横向布置42。更具体地,示出了获取-释放行为。左边是创建流程而右边是容器的销毁流程。
图5示出了通过使用自举(bootstrapping)模块将转换器44插入到编排堆栈的层次结构中。在此,说明这些组件适配的高级别架构。容器运行时模块(容器化、运行时)是用于创建、销毁和促进容器的运行的标准模块和可插拔模块的最低级别、高度模块化和可扩展的组件。它们是跨多个云容器和FaaS框架的通用基础结构(为简单起见,仅示出了两个)。Runc(容器运行时)——OCI(开放容器计划)参考实现――执行容器。容器化负责(1)镜像推拉、(2)管理存储、(3)通过使用正确的参数调用Runc来执行容器、(4)管理接口的网络原语、(5)管理网络命名空间、加入现有命名空间等。容器化利用了OCI(开放容器计划)运行时规范、镜像格式规范、当然还有runc。由于已被广泛使用,因此容器化是实现OCI的行业标准。
如图5所示,增强位于容器引擎级别,并且对于FaaS架构/框架和容器引擎本身是完全不可知的。通过将增强引入为转换器44,所要求的改变被保持为最小(例如,防止对公共运行时层的其他用户的干扰)。但是,该解决方案仍普及整个框架。类似地,因为转换不创建进入公共低级别部分的单独方式,因此转换器44的方法不产生未来的可移植性和/或向后兼容性的挑战;也不需要用于横向插入和重新获取能力的单独引擎。为了适应不同的层次结构,转换器44仅需要最小的更改,因此完全无需从FaaS框架中消除并发容器启动瓶颈。
转换器44因此可以在将来用于其他目的。它可以作为将其他预创建的能力(硬件或软件)嵌入到外壳容器中的挂钩点,然后将其传递给Docker引擎或CRI。例如,转换器44可用于代表在其要求下执行容器创建的主体(例如,以框架透明方式)附加资源证明或安全凭证,而不是针对在顶级别处的每个不同框架执行不同的附接。
使用转换器44来在昂贵创建资源的横向高速缓存上维持透明性是本文描述的技术的有利方面。转换器44具有双重目的:(1)保持实际执行环境(例如,运行时组件层)不考虑此类回收;以及(2)以模块化、可自动化和策略控制的方式定制多个能力的预创建、池化、初始化、去初始化、回收和关闭。尽管在本公开中,可就高速缓存和回收网络命名空间来描述对转换器44的使用,但是该概念和架构允许在许多重用实例上分摊任何能力创建的成本。作为示例,在使用ENVOY代理的服务网格架构中,还可以预执行外壳容器与本地服务对等方之间的mTLS(相互传输层安全性)连接,以保护多租户平台上免遭可能的MITM(中间人)威胁。此类方法有效地允许容易地回收主机本地访问的加密通道,并且仅在附接到不同的容器或附加到不同的安全主体下的不同的容器时才要求重新初始化对称密钥或共享秘密(同样,仅在需要时)——同时绕开长期存在的实体之间的计算上昂贵、相互认证。
类似地,对于在同一主机上启动和回收的容器,各种主机特定的硬件专业化可在预创建期间执行并重用:例如,所有此类外壳容器可以共享公共库映射,该公共库映射包含例如,无需从应用级别引擎单独执行(因此,应用可以对主机上的此类硬件专业知识保持不可知并且仍然可以透明地从中受益)的英特尔QAT(QuickAssist技术)或英特尔分析加速器实现的库代码。
图6示出了方法46,该方法46专门描述了与容器化和调用框架无关的、被预设到每个容器的联网能力的细节。细节可能会根据其他能力而不同,但这仅意味着在相同的总体编写流程中,横向回收的能力是不同的——根据对网络命名空间发生的事情的图示,这一方面将变得更加清楚。
在所图示的示例中,转换器48插入Docker客户端50与守护进程52之间,以拦截它们之间的通信。Docker客户端50将配置参数发送到守护进程52——但是现在是转换器48接收参数,而转换器48根据要回收的能力来解释参数。对于网络命名空间能力,转换器48标识预创建的命名空间,例如,“N”,其中N满足诸如安全性、子域、主机桥等之类的要求。
接下来,转换器48合成新的配置并将新的配置发送到守护进程52:对于这种情况,(例如,如果N不为空)转换器48修改要附接到N的网络模式参数。如果N为空,则转换器48可以保留原始方向,从而请求(创建)新的网络命名空间。
Docker已内置对此类附接的支持,并且该技术的飞行中拦截和转换方法将以前编写的预设流转移到此内置能力的桥接中。如图6所示,守护进程52创建最终配置,并指示容器化54(注意,在该情况下,容器化进行实际工作)以使用容器的预创建的能力(网络命名空间)。
守护进程52现在将创建最终配置,并指示容器化54以使用容器的预创建的网络命名空间。该解决方案中的另一个优点在于,Docker守护进程52通常在其上侦听的套接字(例如,网络套接字)被更改为与转换器48的输出套接字匹配。注意,在Docker中或位于Docker之上的框架不需要更改。
图7示出能力管理器60(60a-60d,例如,包括逻辑指令、可配置逻辑、固定功能逻辑硬件等,或其任何组合)的架构。在该示例的情况下,要管理的能力是网络命名空间。因此,将简要描述根据实施例的原理的网络命名空间的生命周期管理。与网络命名空间不同的其他较低级别的能力可能具有不同的生命周期管理步骤,因此可能会有可应用的适当不同的附接/分离(代替创建/销毁)的方法。
示出了用于网络命名空间管理器的架构。例如,引导加载程序模块60a具有与转换器模块建立通信并用于预创建网络命名空间的功能;这些预创建的网络命名空间可以是具有与网桥的网络连接的外壳容器的形式,但在这些容器中没有任何其他内容。线程安全队列管理器60b拥有未分配的网络命名空间,并在转换器请求未分配的命名空间时将其交给转换器。映射器模块60c维护关于已经向哪个使用中的容器分配了哪个网络命名空间的信息,使得在容器到期时间(即,当容器退出时),可以重新收集网络命名空间。事件监测器模块60d跟踪容器到期、提取每个到期容器的标识符、(例如,使用映射器)将到期容器的标识符映射到网络命名空间,并将网络命名空间提供给队列管理器以进行回收和准备重新分配给来自转换器的未来请求。
其他能力的管理将遵循大致相似的角色和流程:一些将能力管理器60引导到编排流程中,一些跟踪可用能力,一些跟踪容器与分配的能力之间的关联,以及一些保持跟踪哪些受分配者即将到期,以便可以收集该能力。
图8A示出了操作性能增强的计算系统的方法70。方法70可在一个或多个模块中被实现为一组逻辑指令,这组逻辑指令被存储在诸如随机存取存储器(RAM)、只读存储器(ROM)、可编程ROM(PROM)、固件、闪存等之类的机器或计算机可读存储介质中,被存储在诸如例如可编程逻辑阵列(PLA)、现场可编程门阵列(FPGA)、复杂可编程逻辑器件(CPLD)之类的可配置逻辑中,被存储在使用诸如例如专用集成电路(ASIC)、互补金属氧化物半导体(CMOS)的电路技术或晶体管-晶体管逻辑(TTL)技术之类的固定功能逻辑硬件或其任何组合中。
例如,可以用一种或多种编程语言的任何组合来编写用于实施在方法70中所示的操作的计算机程序代码,这些编程语言包括诸如JAVA、SMALLTALK、C++等的面向对象的编程语言以及诸如“C”编程语言或类似编程语言的常规的过程编程语言。另外,逻辑指令可包括汇编程序指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如,主机处理器、中央处理单元/CPU、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。
所图示的处理框72提供了在发出创建容器的请求(例如,按需请求)之前创建软件容器的一个或多个能力,其中一个或多个能力与超过第一阈值(例如,按时间、周期、处理器利用率百分比等,或其任意组合度量的计算阈值)的计算开销和不超过第二阈值(例如,以字节、页、高速缓存线等,或其任意组合度量的存储器阈值)的存储器开销相关联。在实施例中,基于策略数据来自动预创建能力。能力本质上可以是层级式的(例如,随着低级别能力的创建/销毁,也在层次结构中创建/销毁较高级别能力)。框74可以在创建所述一个或多个能力后,拦截创建所述软件容器的请求。另外,框76将一个或多个能力与软件容器相关联。
在一个示例中,创建能力的过程(例如,框72)包括在发出创建软件容器的请求之前将一个或多个能力添加到能力池中。类似地,将能力与软件容器相关联(例如,框76)的过程可包括从池中移除一个或多个能力。所图示的处理框78还提供生成经修改的配置指示以执行一个或多个能力的关联,其中框80向容器构建引擎提供如上所述的经修改的配置指示。因此,所图示的方法70至少就容器启动发生得更快来说增强了性能。
图8B示出了操作性能增强的计算系统的另一方法90。方法90可在一个或多个模块中被实现为一组逻辑指令,这组逻辑指令被存储在诸如RAM、ROM、PROM、固件、闪存等之类的机器或计算机可读存储介质中,存储在诸如例如PLA、FPGA、CPLD之类的可配置逻辑中,存储在使用诸如例如ASIC、CMOS或TTL技术的电路技术的固定功能逻辑硬件或其任何组合中。
所图示的处理框92提供拦截销毁软件容器的请求(例如,按需请求),其中框94将一个或多个能力与软件容器解除关联。另外,框96可以将所述一个或多个能力添加到能力池中。因此,所图示的方法90至少就能力池降低能力创建的频率来说进一步增强了性能。
在实施例中,返回的能力可以被销毁或关闭(例如,而不是被添加到能力池中),如果策略确定如此的话。因此,存在可以组合也可以不组合的两个不同的好处:一个好处在于预创建了一个在计算上昂贵的能力,使得可以减少等待时间并提高性能;另一个好处在于在上一次使用与下一次使用之间循环利用能力,以节省开销。在许多情况下,两个好处都可以实现,但是在一些(罕见)情况下,第二个好处可能无法实现,要么是因为提高安全性是目标,要么是能力的性质是使得池化能力不是直接的(例如,一些超时值与能力相关联)。
图9示出了顶部图98(例如,常规结果、基准),其中在英特尔XEON Platinum(至强白金)8268CPU服务器上使用Docker容器的情况下经历了并发的冷启动性能瓶颈。相比之下,底部图100示出了应用本文所描述的技术之后并发容器创建的性能。与基准相比,容器的启动时间最多可减少25倍(即,与基线相比下降了96%)——通过绕过计算上昂贵的步骤(在该情况下,是为容器设置网络命名空间)。
解决方案可推广到其他类型的计算密集型步骤,这些步骤是存储器或存储密集的,例如,建立证明凭证、加密密钥材料、获取对共享数据和元数据存储的保留,等等。因此,就应用重新工程设计要求而言,创建横向回收机制并将其集成到容器化堆栈中正确层的总体方法非常强大,但是是轻量级的(因为技术的原理不适用于应用架构或应用的编排框架,而是适用于它们的执行媒介架构的创建和退出流程)。
确实,开源代码重构计划(例如Mobyproject,mobyproject.org)可能无法提供编程方式来定制具有预创建能力的容器,因此,该技术通过插入和更改方向——从“创建一些内容”到“附接到预创建的内容”――来获得改进的结果。该技术通过以下方式立即使开发人员和云服务提供商受益。对于云服务提供商,该技术减少加热/预加热容器中的资源闲置(主要是存储器和存储),以及当突发模式请求到达超过加热/预加热容量时冷启动中相对较大的惩罚。对于开发人员而言,该技术可提供更好的大规模性能,并使确定性更高的响应时间成为可能。
然而,益处超出了性能。例如,该技术简化了向容器模块中引入新优化的过程,使得制造商可以通过预构建优化,然后通过指示低级别软件附接到预构建的优化上来“融合”优化,从而提供新优化(例如,预制的遥测库等)。因此,该技术推广了暂停容器的KUBERNETES概念(“K8”,例如,容器编排),以有益地预创建、池化和重用多种软件或硬件基础结构,并且进一步以透明且无摩擦的方式跨不同的框架(不仅是K8)这样做。
所提出的解决方案的主要优点在于:它对FaaS框架和容器引擎是完全不可知的,并且不需要在FaaS框架和容器引擎中进行代码更改;它可以轻松地用于多个FaaS框架和容器引擎;并且它为即时计算操作的基于容器的执行提供了显著的性能和可预测性优势(例如,消除了大多数启动等待时间)。
现在转到图10,描述了策略和配置自动化支持102。本文描述的技术解决的另一个问题是以允许开发人员和解决方案部署人员以可扩展的方式应用横向重用方法而不必重新工程设计编排堆栈的方式来支持策略和配置。如下所述,创建和退出路径的拦截和重新定向对现有编排框架保持透明。此外,重用XK+1……XN中的每一个能力都不需要每次都重写转换器,如下所述。
图10示出了策略和配置存储,以及被标识为策略和配置自动化支持47(ξ,例如,策略数据)的逻辑和数据元素。对于每个XJ,可以提前在ξ中创建配置和策略条目,以标识(1)预创建XJ的方法,(2)行使该库方法的能力管理器,(3)控制能力管理的各个参数(例如,在重新预创建之前,副本如何预创建、能力的最大持续时间或重用周期等),以及(4)预创建、初始化或取消初始化该能力时出现问题时应调用哪种错误/异常处理方法。因此,不是单独到达每个系统,策略和配置可以是软件定义的,并且因此通过编排堆栈的静态API(应用编程接口)实现自动化和有效性。
图11以两部分示出了跨框架的横向重用104示例。到目前为止的描述参考了图11的部分A,其中如果有多个框架,则横向重用发明分别应用于每个框架。如下面在图11的B部分中所示,不必是这种情况。在底部(B),能力可以跨框架池化和重用。为此,能力管理器功能分为两个部分:跨框架的公共部分,以及框架特定的部分。同样,如B部分的右侧所示,重新捕获的能力的任何适用的取消初始化(在容器退出时)分两个阶段进行:框架特定阶段;然后是框架中性阶段。一旦进行了适当的清除,就可以跨框架池化和重用能力。但是注意,此类跨框架的使用是可能的,但实际上并不总是可行的:例如,如果能力由能力之间的共享秘密组成,第一阈值是计算阈值,第二阈值是存储器阈值和框架特定的实体,则取消初始化以重用该秘密也可能破坏该共享秘密,这意味着当需要重新建立新秘密时,仍需要执行大部分要保存的工作。因此,尽管可获得该益处,但是此类解决方案的里程可能根据能力的性质而不同。
图12示出了转换和重用技术106的递归或迭代应用。在所图示的示例中,顶部(部分A)具有复合的能力C,该复合的能力恰好包括一个或多个组成部分或嵌套的能力,例如能力D。复合的能力的一个示例可以是共享库,该共享库具有对CPU(中央处理单元)的定制和由定制的库执行的针对特殊功能硬件的第二定制。迄今为止,如上所述,横向重用原理将适用于作为不可分割单元的复合的能力C。但是,如下面的B部分所示,本文描述的技术递归地(或迭代地)应用,使得C本身可以在容器级别被预创建、池化和横向重用,但是其组成部分能力D可以通过拦截C的创建和取消初始化流程及时获得。
图13示出了包括可执行程序指令170的计算系统150的流程图,该指令在由主机处理器152、图形处理器160或输入/输出模块(IO)158中的一个或多个执行时使得计算系统执行已经讨论过的方法70(图8A)和/或方法90(图8B)的一个或多个方面。系统150被视为至少就使得容器的启动速度比常规计算系统快来说增强了性能。在实施例中,从系统存储器156和/或大容量存储168中检取指令170。另外,图形处理器160、主机处理器152和/或IO模块158被合并到芯片上系统(SoC)162中,该芯片上系统(SoC)162也耦合到显示器164和/或网络控制器166(无线、有线)。
图14示出了半导体封装设备172。所图示的设备172包括一个或多个衬底174(例如,硅、蓝宝石、砷化镓)和耦合至(多个)衬底174的逻辑176(例如,晶体管阵列和其他集成电路/IC组件)。逻辑176可至少部分地被实现在可配置逻辑或固定功能逻辑硬件中。在一个示例中,逻辑176实现方法70(图8A)和/或方法90(图8B)的一个或多个方面。
在一个示例中,逻辑176包括定位(例如,嵌入)在(多个)衬底174内的晶体管沟道区。因此,逻辑176与(多个)衬底174之间的接口可以不是突变结。逻辑176还可被认为包括在(多个)衬底174的初始晶片上生长的外延层。
图15图示出根据一个实施例的处理器核200。处理器核200可以是用于任何类型的处理器的核,这些处理器诸如微处理器、嵌入式处理器、数字信号处理器(DSP)、网络处理器、或用于执行代码的其他设备。虽然图15中仅图示了一个处理器核200,但处理元件可替代地包括多于一个图15中所图示的处理器核200。处理器核200可以是单线程核,或对于至少一个实施例,处理器核200可以是多线程的,因为其每个核可包括多于一个的硬件线程上下文(或“逻辑处理器”)。
图15还图示出耦合至处理器核200的存储器270。存储器270可以是本领域技术人员已知的或以其他方式对本领域技术人员可用的各种各样的存储器(包括存储器层级结构的各个层)中的任何一种。存储器270可包括要由处理器核200执行的一条或多条代码213指令,其中代码213可实现已讨论的方法70(图8A)和/或方法90(图8B)的一个或多个方面。处理器核200遵循由代码213指示的指令的程序序列。每条指令可进入前端部分210并由一个或多个解码器220处理。解码器220可生成微操作(诸如采用预定义格式的固定宽度的微操作)作为其输出,或者可生成反映原始代码指令的其他指令、微指令或控制信号。所图示的前端部分210还包括寄存器重命名逻辑225和调度逻辑230,该调度逻辑230一般分配资源并将与供执行的转换指令相对应的操作进行排队。
处理器核200被示出为包括具有一组执行单元255-1至255-N的执行逻辑250。一些实施例可以包括专用于特定功能或功能组的大量执行单元。其他实施例可包括仅一个执行单元或可以执行特别功能的一个执行单元。所图示的执行逻辑250执行由代码指令指定的操作。
在完成执行由代码指令指定的操作之后,后端逻辑260对代码213的指令进行引退。在一个实施例中,处理器核200允许乱序执行但是要求指令的有序引退。引退逻辑265可采取如本领域技术人员已知的各种形式(例如,重排序缓冲器等等)。以此方式,至少根据由解码器生成的输出、由寄存器重命名逻辑225利用的硬件寄存器和表、以及由执行逻辑250修改的任何寄存器(未示出),处理器核200在代码213的执行期间被变换。
虽然未在图15中图示,但处理元件可包括与处理器核200一起在芯片上的其他元件。例如,处理元件可包括与处理器核200一起的存储器控制逻辑。处理元件可包括I/O控制逻辑和/或可包括与存储器控制逻辑一起被集成的I/O控制逻辑。处理元件还可包括一个或多个高速缓存。
现在参考图16,所示出的是根据实施例的计算系统1000实施例的框图。图16中所示出的是多处理器系统1000,其包括第一处理元件1070和第二处理元件1080。尽管示出了两个处理元件1070和1080,但是要理解,系统1000的实施例还可包括仅一个此类处理元件。
系统1000被图示为点对点互连系统,其中第一处理元件1070和第二处理元件1080经由点对点互连1050耦合。应当理解,图16中所图示的互连中的任何或全部可被实现为多分支总线而不是点对点互连。
如图16中所示,处理元件1070和1080中的每个处理元件可以是包括第一和第二处理器核(即,处理器核1074a和1074b以及处理器核1084a和1084b)的多核处理器。此类核1074a、1074b、1084a、1084b可被配置成用于以与上文结合图15所讨论的方式类似的方式来执行指令代码。
每个处理元件1070、1080可包括至少一个共享高速缓存1896a、1896b。共享高速缓存1896a、1896b可存储分别由处理器的一个或多个组件(诸如核1074a、1074b以及1084a、1084b)利用的数据(例如,指令)。例如,共享高速缓存1896a、1896b可本地地对存储器1032、1034中所存储的数据进行高速缓存以供处理器的组件的更快速访问。在一个或多个实施例中,共享高速缓存1896a、1896b可包括一个或多个中间级别高速缓存(诸如第2级(L2)、第3级(L3)、第4级(L4)、或其他级别的高速缓存)、末级高速缓存(LLC)和/或其组合。
虽然被示出为具有仅两个处理元件1070、1080,但要理解,实施例的范围并不限于此。在其他实施例中,在给定的处理器中可存在一个或多个附加处理元件。替代地,处理元件1070、1080中的一者或多者可以是除处理器之外的元件,诸如加速器或现场可编程门阵列。例如,(多个)附加处理元件可包括与第一处理器1070相同的(多个)附加处理器、与第一处理器1070异构或不对称的(多个)附加处理器、加速器(诸如例如,图形加速器或数字信号处理(DSP)单元)、现场可编程门阵列、或任何其他处理元件。在包括架构、微架构、热、功耗特性等等一系列品质度量方面,处理元件1070、1080之间可存在各种差异。这些差异自身可有效地表现为处理元件1070、1080之中的不对称性和异构性。对于至少一个实施例,各处理元件1070、1080可驻留在同一管芯封装中。
第一处理元件1070可进一步包括存储器控制器逻辑(MC)1072以及点对点(P-P)接口1076和1078。类似地,第二处理元件1080可包括MC 1082以及P-P接口1086和1088。如图16中所示,MC 1072和1082将处理器耦合至相应的存储器,即存储器1032和存储器1034,这些存储器可以是本地附接到相应处理器的主存储器的部分。尽管MC 1072和MC 1082被图示为被集成到处理元件1070、1080中,但对于替代实施例,MC逻辑可以是处理元件1070、1080外部的分立逻辑,而不是被集成于其中。
第一处理元件1070和第二处理元件1080可分别经由P-P互连1076、1086耦合至I/O子系统1090。如图16中所示,I/O子系统1090包括P-P接口1094和1098。此外,I/O子系统1090包括将I/O子系统1090与高性能图形引擎1038耦合的接口1092。在一个实施例中,可使用总线1049将图形引擎1038耦合至I/O子系统1090。替代地,点对点互连可耦合这些组件。
进而,I/O子系统1090可经由接口1096耦合至第一总线1016。在一个实施例中,第一总线1016可以是外围组件互连(PCI)总线,或诸如PCI快速(PCI Express)总线或另一第三代I/O互连总线之类的总线,但是实施例的范围不限于此。
如图16中所示,各种I/O设备1014(例如,生物计量扫描仪、扬声器、相机、传感器)可与总线桥1018一起耦合至第一总线1016,该总线桥1018可将第一总线1016耦合至第二总线1020。在一个实施例中,第二总线1020可以是低引脚计数(LPC)总线。各种设备可耦合到第二总线1020,这些设备包括例如键盘/鼠标1012、(多个)通信设备1026、以及数据存储单元1019(诸如在一个实施例中可包括代码1030的盘驱动器或其他大容量存储设备)。所图示的代码1030可实现已讨论的方法70(图8A)和/或方法90(图8B)的一个或多个方面。进一步地,音频I/O 1024可耦合至第二总线1020,并且电池1010可向计算系统1000供给功率。
注意,构想了其他实施例。例如,系统可实现多分支总线或者另一此类通信拓扑,而不是图16的点对点架构。而且,可替代地使用比图16中所示的更多或更少的集成芯片来对图16的元件进行分区。
附加说明和示例:
示例1包括计算系统,该计算系统包括:网络控制器;耦合到该网络控制器的处理器;以及耦合到该处理器的存储器,该存储器包括一组可执行程序指令,当该指令由处理器执行时,使得计算系统:在发出创建容器的请求之前创建软件容器的一个或多个能力,其中一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联;在创建一个或多个能力后,拦截创建软件容器的请求;以及将一个或多个能力与软件容器进行关联。
示例2包括示例1的计算系统,其中,指令在被执行时,进一步使得计算系统在发出创建软件容器的请求之前将一个或多个能力添加到能力池中,以及在将一个或多个能力与软件容器进行关联后,从池中移除一个或多个能力。
示例3包括示例1的计算系统,其中,指令在被执行时,进一步使得计算系统:拦截销毁软件容器的请求,其中,创建软件容器的请求和销毁软件容器的请求是按需请求;将一个或多个能力与软件容器解除关联;以及将一个或多个能力添加到能力池中。
示例4包括示例1的计算系统,其中,一个或多个能力是层级式的。
示例5包括示例1的计算系统,其中,一个或多个能力包括网络命名空间能力,第一阈值是计算阈值,第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
示例6包括示例1至5中任一项的计算系统,其中,耦合到一个或多个衬底的逻辑用于基于策略数据来自动定制用于管理一个或多个能力的生命周期的转换器。
示例7包括一种半导体设备,该半导体设备包括:一个或多个衬底、以及耦合至该一个或多个衬底的逻辑,其中该逻辑至少部分地在可配置逻辑或固定功能硬件逻辑中的一者或多者中实现,耦合至一个或多个衬底的逻辑用于:在发出创建容器的请求之前创建软件容器的一个或多个能力,其中一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联;在创建一个或多个能力后,拦截创建软件容器的请求;以及将一个或多个能力与软件容器进行关联。
示例8包括示例7的设备,其中,耦合至一个或多个衬底的逻辑用于:在发出创建软件容器的请求之前将一个或多个能力添加到能力池中;以及在将一个或多个能力与软件容器进行关联后,从池中移除一个或多个能力。
示例9包括示例7的设备,其中,耦合至一个或多个衬底的逻辑用于:拦截销毁软件容器的请求,其中,创建软件容器的请求和销毁软件容器的请求是按需请求;将一个或多个能力与软件容器解除关联;以及将一个或多个能力添加到能力池中。
示例10包括示例7的设备,其中,一个或多个能力是层级式的。
示例11包括示例7的设备,其中,一个或多个能力包括网络命名空间能力,第一阈值是计算阈值,第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
示例12包括示例7至11中任一项的设备,其中,耦合到一个或多个衬底的逻辑用于基于策略数据来自动定制用于管理一个或多个能力的生命周期的转换器。
示例13包括如示例7至11中任一项的设备,其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。
示例14包括至少一种计算机可读存储介质,包括一组可执行程序指令,这些指令在由计算系统执行时,使得该计算系统用于:在发出创建容器的请求之前创建软件容器的一个或多个能力,其中一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联;在创建一个或多个能力后,拦截创建软件容器的请求;以及将一个或多个能力与软件容器进行关联。
示例15包括示例14的至少一种计算机可读存储介质,其中,指令在被执行时进一步使得计算系统在发出创建软件容器的请求之前将一个或多个能力添加到能力池中,以及在将一个或多个能力与软件容器进行关联后,从池中移除一个或多个能力。
示例16包括示例14的至少一种计算机可读存储介质,其中,指令在被执行时,进一步使得计算系统:拦截销毁软件容器的请求,其中,创建软件容器的请求和销毁软件容器的请求是按需请求;将一个或多个能力与软件容器解除关联;以及将一个或多个能力添加到能力池中。
示例17包括示例14的至少一种计算机可读存储介质,其中,一个或多个能力是层级式的。
示例18包括示例14的至少一种计算机可读存储介质,其中,一个或多个能力包括网络命名空间能力,第一阈值是计算阈值,第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
示例12包括示例14至18中任一项的至少一种计算机可读存储介质,其中指令在被执行时,进一步使得计算系统用于基于策略数据来自动定制用于管理一个或多个能力的生命周期的转换器。
示例20包括一种操作性能增强的计算系统的方法,该方法包括:在发出创建容器的请求之前创建软件容器的一个或多个能力,其中一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联;在创建一个或多个能力后,拦截创建软件容器的请求;以及将一个或多个能力与软件容器进行关联。
示例21包括示例20的方法,进一步包括:在发出创建软件容器的请求之前将一个或多个能力添加到能力池中;以及在将一个或多个能力与软件容器进行关联后,从池中移除一个或多个能力。
示例22包括示例20的方法,进一步包括:拦截销毁软件容器的请求,其中,创建软件容器的请求和销毁软件容器的请求是按需请求;将一个或多个能力与软件容器解除关联;以及将一个或多个能力添加到能力池中。
示例23包括示例20的方法,其中,一个或多个能力是层级式的。
示例24包括示例20的方法,其中,一个或多个能力包括网络命名空间能力,第一阈值是计算阈值,第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
示例25包括示例20至24中任一项的方法,进一步包括基于策略数据来自动定制用于管理一个或多个能力的生命周期的转换器。
示例26包括用于执行如示例20至25中任一项所述的方法的装置。
因此,本文所描述的技术拦截并重写创建流程。技术进一步使额外的方法能够拦截销毁流程。拦截和重写提供了一种框架不可知的可扩展的机制,以预创建和可选地池化可能在计算上昂贵的能力,以便按需锻造。技术进一步管理预创建和/或池化的能力,这些能力可能根据所管理能力的类型而不同。例如,安全敏感的重新初始化或随机化可以由能力管理器执行。因此,技术可能比被动对象高速缓存和回收更通用。
组件的模块化组装使该技术可扩展,而不会使与大众的、事实上标准化的容器和运行时环境的集成复杂化。此外,技术使用重写的方法,该重写的办法使其能够跨使用公共容器和运行时环境的多个云编排框架(例如,而不是特定于编排框架)而插入到公共点中。
技术还为新的硬件练习者(例如,驱动程序、实用程序库、优化的代码)提供了一条“易滑移”路径,将其视为可以在启动时使用而不是必须创建的通用共享库,这对于诸如FaaS之类的等待时间关键事件驱动的服务来说是高度关注的问题。当适用时,池化概念除了回避了创建等待时间之外,进一步分摊了开销。
实施例适用于与所有类型的半导体集成电路(“IC”)芯片一起使用。这些IC芯片的示例包括但不限于处理器、控制器、芯片组组件、可编程逻辑阵列(PLA)、存储器芯片、网络芯片、芯片上系统(SoC)、SSD/NAND控制器ASIC等等。另外,在一些附图中,信号导线用线表示。一些线可以是不同的以指示更具构成性的信号路径,可具有数字标号以指示构成性信号路径的数目,和/或可在一端或多端具有箭头以指示主要信息流向。然而,这不应以限制性方式来解释。相反,此类增加的细节可与一个或多个示例性实施例结合使用以促进更容易地理解电路。任何所表示的信号线,不管是否具有附加信息,实际上都可包括一个或多个信号,这一个或多个信号可在多个方向上行进,并且可用任何适合类型的信号方案来实现,例如利用差分对来实现的数字或模拟线路、光纤线路、和/或单端线路。
示例尺寸/模型/值/范围可能已经被给出,但是实施例不限于此。随着制造技术(例如,光刻法)随时间变得成熟,预料到能制造出更小尺寸的设备。另外,为了说明和讨论的简单并且为了不使实施例的某些方面模糊,到IC芯片和其他组件的公知的功率/接地连接可在附图内示出也可不示出。此外,各种布置可以框图形式示出以避免模糊各实施例,并且这也鉴于关于此类框图布置的实现的具体细节高度依赖于实现实施例的平台这一事实,即这些具体细节应当落在本领域内技术人员的学识范围内。在阐述具体细节(例如电路)以描述示例实施例的情况下,对本领域内技术人员应显而易见的是,没有这些具体细节或对这些具体细节作出变型也可实践各实施例。描述因此被视为是说明性的而不是限制性的。
术语“耦合的”在本文中可被用于表示所讨论的组件之间的任何类型的直接或间接关系,且可应用于电气的、机械的、流体的、光学的、电磁的、机电的或其他连接。另外,术语“第一”、“第二”等在本文中可仅用于便于讨论,并且不带有特定时间的或按时间顺序的意义,除非另有陈述。
如在本申请和权利要求书中所使用的,由术语“中的一个或多个”联接的项列表可意指所列项的任何组合。例如,短语“A、B或C中的一个或多个”可意指A;B;C;A和B;A和C;B和C;或A、B和C。
本领域技术人员从前面的描述将领会,实施例的广泛技术能以各种形式来实现。因此,尽管已结合其特定示例描述了实施例,但实施例的真实范围不应当限于此,因为在研究附图、说明书和所附权利要求书之后,其他修改对于本领域技术人员将变得显而易见。
Claims (25)
1.一种性能增强的计算系统,包括:
网络控制器;
耦合至所述网络控制器的处理器;以及
耦合至所述处理器的存储器,所述存储器包括可执行程序指令集,所述指令在由所述处理器执行时,使所述处理器用于:
在发出创建容器的请求之前创建软件容器的一个或多个能力,其中所述一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联,
在创建所述一个或多个能力后,拦截创建所述软件容器的请求,以及
将所述一个或多个能力与所述软件容器进行关联。
2.如权利要求1所述的计算系统,其中,所述指令在被执行时进一步使所述计算系统用于:
在发出创建所述软件容器的请求之前将所述一个或多个能力添加到能力池中,以及
在将所述一个或多个能力与所述软件容器进行关联后,从池中移除所述一个或多个能力。
3.如权利要求1所述的计算系统,其中,所述指令在被执行时进一步使所述计算系统用于:
拦截销毁所述软件容器的请求,其中,创建所述软件容器的请求和销毁所述软件容器的请求是按需请求,
将所述一个或多个能力与所述软件容器解除关联,以及
将所述一个或多个能力添加到能力池中。
4.如权利要求1所述的计算系统,其中,所述一个或多个能力是层级式的。
5.如权利要求1所述的计算系统,其中,所述一个或多个能力包括网络命名空间能力,所述第一阈值是计算阈值,所述第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
6.如权利要求1至5中任一项所述的计算系统,其中,所述指令在被执行时,进一步使得所述处理器用于基于策略数据来自动定制用于管理所述一个或多个能力的生命周期的转换器。
7.一种半导体设备,包括:
一个或多个衬底;以及
逻辑,所述逻辑耦合至所述一个或多个衬底,其中,所述逻辑至少部分地在可配置逻辑或固定功能硬件逻辑中的一者或多者中实现,耦合至所述一个或多个衬底的所述逻辑用于:
在发出创建容器的请求之前创建软件容器的一个或多个能力,其中所述一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联,
在创建所述一个或多个能力后,拦截创建所述软件容器的请求,以及
将所述一个或多个能力与所述软件容器进行关联。
8.如权利要求7所述的设备,其中,耦合至所述一个或多个衬底的所述逻辑用于:
在发出创建所述软件容器的请求之前将所述一个或多个能力添加到能力池中,以及
在将所述一个或多个能力与所述软件容器进行关联后,从池中移除所述一个或多个能力。
9.如权利要求7所述的设备,其中,耦合至所述一个或多个衬底的所述逻辑用于:
拦截销毁所述软件容器的请求,其中,创建所述软件容器的请求和销毁所述软件容器的请求是按需请求,
将所述一个或多个能力与所述软件容器解除关联,以及
将所述一个或多个能力添加到能力池中。
10.如权利要求7所述的设备,其中,所述一个或多个能力是层级式的。
11.如权利要求7所述的设备,其中,所述一个或多个能力包括网络命名空间能力,所述第一阈值是计算阈值,所述第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
12.如权利要求7至11中任一项所述的设备,其中,耦合到一个或多个衬底的逻辑用于基于策略数据来自动定制用于管理一个或多个能力的生命周期的转换器。
13.如权利要求7至11中任一项所述的设备,其中,耦合至所述一个或多个衬底的所述逻辑包括位于所述一个或多个衬底内的晶体管沟道区。
14.一种操作性能增强的计算系统的方法,包括:
在发出创建容器的请求之前创建软件容器的一个或多个能力,其中所述一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联;
在创建所述一个或多个能力后,拦截创建所述软件容器的请求;以及
将所述一个或多个能力与所述软件容器进行关联。
15.如权利要求14所述的方法,进一步包括:
在发出创建所述软件容器的请求之前将所述一个或多个能力添加到能力池中;以及
将所述一个或多个能力与所述软件容器进行关联后,从池中移除所述一个或多个能力。
16.如权利要求14所述的方法,进一步包括:
拦截销毁所述软件容器的请求,其中,创建所述软件容器的请求和销毁所述软件容器的请求是按需请求;
将所述一个或多个能力与所述软件容器解除关联;以及
将所述一个或多个能力添加到能力池中。
17.如权利要求14所述的方法,其中,所述一个或多个能力是层级式的。
18.如权利要求14所述的方法,其中,所述一个或多个能力包括网络命名空间能力,所述第一阈值是计算阈值,所述第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
19.如权利要求14至18中任一项所述的方法,进一步包括基于策略数据来自动定制用于管理所述一个或多个能力的生命周期的转换器。
20.一种半导体设备,包括:
用于在发出创建容器的请求之前创建软件容器的一个或多个能力的装置,其中所述一个或多个能力与超过第一阈值的计算开销和不超过第二阈值的存储器开销相关联;
用于在创建所述一个或多个能力后拦截创建所述软件容器的请求的装置;以及
用于将所述一个或多个能力与所述软件容器进行关联的装置。
21.如权利要求20所述的半导体设备,进一步包括:
用于在发出创建所述软件容器的请求之前将所述一个或多个能力添加到能力池中的装置;以及
用于在将所述一个或多个能力与所述软件容器进行关联后从池中移除所述一个或多个能力的装置。
22.如权利要求20所述的半导体设备,进一步包括:
用于拦截销毁所述软件容器的请求的装置,其中,创建所述软件容器的请求和销毁所述软件容器的请求是按需请求;
用于将所述一个或多个能力与所述软件容器解除关联的装置;以及
用于将所述一个或多个能力添加到能力池中的装置。
23.如权利要求20所述的半导体设备,其中,所述一个或多个能力是层级式的。
24.如权利要求20所述的半导体设备,其中,所述一个或多个能力包括网络命名空间能力,所述第一阈值是计算阈值,所述第二阈值是存储器阈值,并且请求在功能即服务架构中被拦截。
25.如权利要求20至24中任一项所述的半导体设备,进一步包括用于基于策略数据来自动定制用于管理所述一个或多个能力的生命周期的转换器的装置。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US202062984829P | 2020-03-04 | 2020-03-04 | |
US62/984,829 | 2020-03-04 | ||
US16/938,070 | 2020-07-24 | ||
US16/938,070 US20200356406A1 (en) | 2020-03-04 | 2020-07-24 | Framework-agnostic agile container launches through lateral reuse of capabilities in standard runtimes |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113360242A true CN113360242A (zh) | 2021-09-07 |
Family
ID=73046436
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011535887.6A Pending CN113360242A (zh) | 2020-03-04 | 2020-12-23 | 通过在标准运行时中横向重用能力的框架不可知的敏捷容器启动 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20200356406A1 (zh) |
EP (1) | EP3876095A1 (zh) |
CN (1) | CN113360242A (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11070621B1 (en) | 2020-07-21 | 2021-07-20 | Cisco Technology, Inc. | Reuse of execution environments while guaranteeing isolation in serverless computing |
US20220035685A1 (en) * | 2020-08-03 | 2022-02-03 | Juniper Networks, Inc. | Device access control for applications of multiple containers |
US11886921B2 (en) | 2021-03-04 | 2024-01-30 | International Business Machines Corporation | Serverless runtime container allocation |
CN115617421B (zh) * | 2022-12-05 | 2023-04-14 | 深圳市欧瑞博科技股份有限公司 | 进程智能调度方法、装置、可读存储介质及嵌入式设备 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110085667A1 (en) * | 2009-10-09 | 2011-04-14 | Adgregate Markets, Inc. | Various methods and apparatuses for securing an application container |
WO2018184698A1 (en) * | 2017-04-07 | 2018-10-11 | NEC Laboratories Europe GmbH | Method and system for supporting creation of virtual machines on a virtualization platform |
WO2018231697A1 (en) * | 2017-06-12 | 2018-12-20 | Daniel Maurice Lerner | Securitization of temporal digital communications with authentication and validation of user and access devices |
US11228615B2 (en) * | 2018-07-31 | 2022-01-18 | Salesforce.Com, Inc. | Transparent enforcement of data policies |
US11175960B2 (en) * | 2018-12-05 | 2021-11-16 | Electronics And Telecommunications Research Institute | Worker-scheduling method in cloud-computing system and apparatus for the same |
US11356367B2 (en) * | 2019-11-22 | 2022-06-07 | Red Hat, Inc. | Secure preloading of serverless function sequences |
-
2020
- 2020-07-24 US US16/938,070 patent/US20200356406A1/en not_active Abandoned
- 2020-12-14 EP EP20213805.3A patent/EP3876095A1/en active Pending
- 2020-12-23 CN CN202011535887.6A patent/CN113360242A/zh active Pending
Also Published As
Publication number | Publication date |
---|---|
US20200356406A1 (en) | 2020-11-12 |
EP3876095A1 (en) | 2021-09-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113360242A (zh) | 通过在标准运行时中横向重用能力的框架不可知的敏捷容器启动 | |
US20210058301A1 (en) | Extension resource groups of provider network services | |
US9323921B2 (en) | Ultra-low cost sandboxing for application appliances | |
AU2004216723B2 (en) | Customized execution environment and operating system capable of supporting same | |
US9038085B2 (en) | System, method and program product for cost-aware selection of stored virtual machine images for subsequent use | |
US20090271498A1 (en) | System and method for layered application server processing | |
EP3979115A1 (en) | Early platform hardening technology for slimmer and faster boot | |
CN103608773A (zh) | 用于多节点应用的部署系统 | |
US9983863B2 (en) | Method to optimize provisioning time with dynamically generated virtual disk contents | |
WO2008080827A1 (en) | Virtual resource templates | |
US8875132B2 (en) | Method and apparatus for implementing virtual proxy to support heterogeneous systems management | |
US20180025152A1 (en) | Securing multi-tenancy in a datacenter using nanoservices | |
US11605033B2 (en) | Quantum computing task translation supporting multiple quantum computing technologies | |
CN113934508A (zh) | 对驻留在kubernetes持久卷上的数据静态加密数据的方法 | |
JP3409308B2 (ja) | クライアント/サーバ・コンピューティング・システム及びサーバ処理方法 | |
Lewis et al. | Support for extensibility and site autonomy in the Legion grid system object model | |
Mbongue et al. | Deploying multi-tenant fpgas within linux-based cloud infrastructure | |
US20110138452A1 (en) | Cross security-domain identity context projection within a computing environment | |
Mehra et al. | Taming memory with disaggregation | |
US8352947B2 (en) | Method to automatically redirect SRB routines to a zIIP eligible enclave | |
US11403154B1 (en) | Systems, methods and apparatuses for running multiple machine learning models on an edge device | |
Lertpongrujikorn et al. | Object as a service (oaas): Enabling object abstraction in serverless clouds | |
US9292702B2 (en) | Dynamic switching of security configurations | |
CN112835865A (zh) | 一种应用热部署系统、方法及装置 | |
CN106843851A (zh) | 基于ActiveMQ异构类加载器反序列化的实现方法及装置 |
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 |