Patent Application
20220391223
Aspects of the present disclosure relate to container-orchestration systems, and more particularly, to adding expressiveness to plugin extensions using integration with operators.
A container-orchestration system may automate many of the manual processes involved in deploying, managing, and scaling containerized applications. For example, a container-orchestration system for developing and running containerized applications may allow applications and the data centers that support them to expand from just a few machines and applications to thousands of machines that serve millions of clients. Container-orchestration systems may provide an image-based deployment module for creating containers and may store one or more image files for creating container instances. Many application instances can be running in containers on a single host without visibility into each other's processes, files, network, and so on. Each container may provide a single function (often called a “service”) or component of an application, such as a web server or a database. These services may be connected to various resources and managed by a system operator.
The described embodiments and the advantages thereof may best be understood by reference to the following description taken in conjunction with the accompanying drawings. These drawings in no way limit any changes in form and detail that may be made to the described embodiments without departing from the spirit and scope of the described embodiments.
Custom services, such as a containerized application for example, are deployed within a node or group of nodes (hereinafter, “cluster”) of a container-orchestration system (e.g., Redhat™ OpenShift™ module on a Kubernetes® platform) may depend on other services and their respective resources deployed within and outside the group. For example, a web service may persist its data into a resource, such as a database. The services may be deployed and connected to other services and resources by a cluster's system operator through a dependency configuration. These services and resources may be local to the operator, meaning already managed by the operator deploying the service, or may not be local and is a third-party resource managed by another operator. Some of these third-party resources may correspond to plugin extensions that add additional functionality to a service that may not be provided by resources that are local to the operator.
In a conventional container-orchestration system, operators may manage these third-party resources by defining custom resource definitions that describe the third-party resources and allowing for the creating, editing, and deletion of custom resources. The expressiveness of these custom resource operations (e.g., the creating, editing, and deleting of custom resources) is not user-friendly for advanced operations that include cluster queries. For example, in a conventional container-orchestration system there is no easy way to create a custom resource based on hardware features associated with a service. In the conventional-orchestration system, the plugin extension management mechanism is not connected to operators directly, leaving no native way to discover the existence of plugin extensions and bundle the plugin extensions into a container-orchestration system product.
Aspects of the disclosure address the above-noted and other deficiencies by adding expressiveness to plugin extensions using integration with operators. In embodiments, an operator developer may write a set of commands that corresponds to a plugin extension to be utilized by one or more services. The set of commands for the plugin extension may be added to an operator image that includes metadata identifying the plugin extension included in the operator image, adding expressiveness to the plugin extension. For example, the metadata may identify the plugin extension as a plugin extension that creates a performance profile for the cluster based on the hardware of the cluster. The operator image including the plugin extension and the metadata may be deployed in a repository with other operator images and subsequently used by services of the container-orchestration system.
When a user wishes to determine which plugin extensions are available to use, a client device of the user may transmit a query for available plugin extensions to the container-orchestration system. Upon receiving the query, processing logic of a processing device of a container-orchestration system may transmit a request to the repository for operator images that include plugin extensions. The processing logic may receive, from the repository, identifications of the operator images including the plugin extensions and the corresponding metadata for each of the operator images. The processing logic may be able to use the corresponding metadata to identify the types of plugin extensions that are included in each of the operator images. The processing logic may transmit a listing of the plugin extensions that are available to the client device.
By adding expressiveness to plugin extensions in a container-orchestration system, a user may be able to perform more advanced operations without having to generate their own set of commands for a plugin extension. The ability to query a container-orchestration system for available plugin extensions may provide a user access to various plugin extensions that have already been written by operator developers, reducing the potential for errors in the set of commands and improving the performance of the container-orchestration system.
As shown in
The host systems 110a, b, repository 140, and client device 150 may be a server, a mainframe, a workstation, a personal computer (PC), a mobile phone, a palm-sized computing device, etc. In embodiments, host systems 110a, b, repository 140, and/or client device 150 may be separate computing devices. In some embodiments, host systems 110a, b, repository 140, and/or client device 150 may be implemented by a single computing device. For clarity, some components of repository 140, host system 110b, and client device 150 are not shown. Although microservice architecture 100 is illustrated as having two host systems, embodiments of the disclosure may utilize any number of host systems.
Host systems 110a, b may additionally include a host operating system (OS) 120. Host OS 120 manages the hardware resources of the computer system and provides functions such as inter-process communication, scheduling, memory management, and so forth.
The host systems 110a, b, repository 140, and client device 150 are coupled to each other (e.g., may be operatively coupled, communicatively coupled, may communicate data/messages with each other) via network 105. Network 105 may be a public network (e.g., the internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. In one embodiment, network 105 may include a wired or a wireless infrastructure, which may be provided by one or more wireless communications systems, such as a WiFi™ hotspot connected with the network 105 and/or a wireless carrier system that can be implemented using various data processing equipment, communication towers (e.g., cell towers), etc. The network 105 may carry communications (e.g., data, message, packets, frames, etc.) between the various components of host systems 110a, b, repository 140, and/or client device 150.
In embodiments, processing device 160 may execute an operator 162. As previously described, the operator 162 may make use of custom resources and manage applications and their components. The operator 162 may receive a query for available plugin extensions from client device 150. Upon receiving the query, the operator 162 may transmit a request to repository 140 for operator images that include plugin extensions. The operator 162 may receive the operator images including plugin extensions and metadata identifying the plugin extensions from the repository 140. The operator 162 may use the metadata to identify the types of plugin extensions included in the operator images. The operator 162 may further transmit a listing of the plugin extensions that are available to the client device 150. In embodiments, the operator 162 may be an index image that includes corresponding pointers to operator images stored at the repository 140. Further details regarding operator 162 will be discussed at
Repository 140 may include operator image 202a and operator image 202b that are stored in memory or at a storage device that is accessible by repository 140. Operator image 202a may include plugin extension 204a that corresponds to a set of commands to execute one or more operations and metadata 206a that identifies the plugin extension 204a. For example, plugin extension 204a may include a set of commands that creates a performance profile for a cluster based on the computing hardware of the cluster and metadata 206a may identify that plugin extension 204a creates a hardware-based performance profile for the cluster. Similarly, operator image 202b may include plugin extension 204b that includes a set of commands to execute one or more operations and metadata 206b that identifies the plugin extension 204b. In embodiments, operator image 202a and operator image 202b may be container images. In some embodiments, plugin extension 204a and/or plugin extension 204b may be binary plugins that are embedded into build script.
As previously described, when a user wishes to determine what plugin extensions are available to use, the client device 150 of the user may transmit a query requesting the available plugin extensions that can be used. Upon receiving the query, the operator 162 may transmit a request to the repository 140 for operator images that include plugin extensions that may be used by the client device 150. The operator 162 may then receive identifications of operator images stored at repository 140 that include plugin extensions, such as operator image 202a and operator image 202b. The operator 162 may also receive metadata 206a and metadata 206b that identify the types of plugin extensions (e.g., provide expressiveness) that are included in operator image 202a and operator image 202b, respectively. For example, metadata 206a may identify that the plugin extension 204a creates a performance profile based on hardware of a cluster, as previously described.
Upon receiving the identifications from the repository 140, the operator 162 may generate a listing of available plugin extensions and transmit the listing of available plugin extensions to the client device 150. In embodiments, the operator 162 may generate the listing of available plugin extensions using the metadata included in the operator images to identify the types of plugin extensions. For example, the operator 162 may use metadata 206a to determine that plugin extension 204a creates a performance profile based on the hardware of a cluster and generate a list of available plugin extensions that indicates one of the plugin extensions available (e.g., plugin extension 204a) creates a performance profile based on cluster hardware.
In
Upon receiving the selections, the client device 150 may transmit a plugin request to the operator 162 that indicates the one or more plugin extensions to be utilized by the client device 150. For example, the plugin request may indicate that the client device 150 wishes to utilize plugin extension 204a included in operator image 202a. Upon receiving the request, the operator 162 may transmit a subsequent request for the binary plugin to the repository 140. The subsequent request may identify the operator image(s) associated with the plugin extensions that have been requested by the client device 150. For example, the subsequent request may identify operator image 202a, which includes plugin extension 204a that was identified by the plugin request transmitted by the client device 150. As previously described, in some embodiments the plugin extension(s) may be binary plugins.
Once the subsequent request has been transmitted to the repository 140, the operator 162 may receive the operator image(s) associated with the requested plugin extension(s). For example, the operator 162 may receive operator image 202a from the repository 140. The operator 162 may provide the operator image(s) to the client device 150 to enable the client device 150 to utilize the requested plugin extensions. For example, the operator 162 may provide operator image 202a to client device 150 to enable client device 150 to utilize plugin extension 204a. In some embodiments, providing the operator image to the client device 150 may cause the plugin extension to be installed locally on the client device 150. In embodiments, the plugin extension may be made available for use by the client device 150 when the client device 150 does not have internet access.
With reference to
Method 400 begins at block 410, where the processing logic receives a set of commands for a plugin extension and metadata identifying the plugin extension. As previously described, an operator developer may write a set of commands that corresponds to a plugin extension to be utilized by one or more services. The operator developer may also provide metadata that provides information associated with the plugin extension. For example, the metadata may identify the plugin extension as a plugin extension that creates a performance profile for the cluster based on the hardware of the cluster.
At block 420, the processing logic adds the set of commands for the plugin extension to an operator image that includes the metadata identifying the plugin extension included in the operator image.
At block 430, the processing logic deploys the operator image including the plugin extension and the metadata in a repository with other operator images and that may be subsequently used by services of the container-orchestration system. In embodiments, the processing logic may deploy the operator image in a repository by storing the operator image in a memory or storage device that is accessible by the repository.
With reference to
Method 500 begins at block 510, where the processing logic receives a query for available plugin extensions from a client device.
At block 520, the processing logic transmits a request for operator images including plugin extensions to a repository that includes multiple operator images.
At block 530, the processing logic receives identifications of the operator images including the plugin extensions and corresponding metadata identifying the plugin extensions from the repository.
At block 540, the processing logic transmits a listing of the plugin extensions to the client device.
The example computing device 600 may include a processing device (e.g., a general purpose processor, a PLD, etc.) 602, a main memory 604 (e.g., synchronous dynamic random access memory (DRAM), read-only memory (ROM)), a static memory 606 (e.g., flash memory and a data storage device 618), which may communicate with each other via a bus 630.
Processing device 602 may be provided by one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. In an illustrative example, processing device 602 may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Processing device 602 may also comprise one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 602 may be configured to execute the operations described herein, in accordance with one or more aspects of the present disclosure, for performing the operations and steps discussed herein.
Computing device 600 may further include a network interface device 608 which may communicate with a network 620. The computing device 600 also may include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse) and an acoustic signal generation device 616 (e.g., a speaker). In one embodiment, video display unit 610, alphanumeric input device 612, and cursor control device 614 may be combined into a single component or device (e.g., an LCD touch screen).
Data storage device 618 may include a computer-readable storage medium 628 on which may be stored one or more sets of instructions 625 that may include instructions for an operator, e.g., operator 162 for carrying out the operations described herein, in accordance with one or more aspects of the present disclosure. Instructions 625 may also reside, completely or at least partially, within main memory 604 and/or within processing device 602 during execution thereof by computing device 600, main memory 604 and processing device 602 also constituting computer-readable media. The instructions 625 may further be transmitted or received over a network 620 via network interface device 608.
While computer-readable storage medium 628 is shown in an illustrative example to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform the methods described herein. The term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.
Unless specifically stated otherwise, terms such as “receiving,” “transmitting,” “adding,” “deploying,” or the like, refer to actions and processes performed or implemented by computing devices that manipulates and transforms data represented as physical (electronic) quantities within the computing device's registers and memories into other data similarly represented as physical quantities within the computing device memories or registers or other such information storage, transmission or display devices. Also, the terms “first,” “second,” “third,” “fourth,” etc., as used herein are meant as labels to distinguish among different elements and may not necessarily have an ordinal meaning according to their numerical designation.
Examples described herein also relate to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computing device selectively programmed by a computer program stored in the computing device. Such a computer program may be stored in a computer-readable non-transitory storage medium.
The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used in accordance with the teachings described herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear as set forth in the description above.
The above description is intended to be illustrative, and not restrictive. Although the present disclosure has been described with references to specific illustrative examples, it will be recognized that the present disclosure is not limited to the examples described. The scope of the disclosure should be determined with reference to the following claims, along with the full scope of equivalents to which the claims are entitled.
As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “includes”, and/or “including”, when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Therefore, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.
It should also be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
Although the method operations were described in a specific order, it should be understood that other operations may be performed in between described operations, described operations may be adjusted so that they occur at slightly different times or the described operations may be distributed in a system which allows the occurrence of the processing operations at various intervals associated with the processing.
Various units, circuits, or other components may be described or claimed as “configured to” or “configurable to” perform a task or tasks. In such contexts, the phrase “configured to” or “configurable to” is used to connote structure by indicating that the units/circuits/components include structure (e.g., circuitry) that performs the task or tasks during operation. As such, the unit/circuit/component can be said to be configured to perform the task, or configurable to perform the task, even when the specified unit/circuit/component is not currently operational (e.g., is not on). The units/circuits/components used with the “configured to” or “configurable to” language include hardware—for example, circuits, memory storing program instructions executable to implement the operation, etc. Reciting that a unit/circuit/component is “configured to” perform one or more tasks, or is “configurable to” perform one or more tasks, is expressly intended not to invoke 35 U.S.C. 112, sixth paragraph, for that unit/circuit/component. Additionally, “configured to” or “configurable to” can include generic structure (e.g., generic circuitry) that is manipulated by software and/or firmware (e.g., an FPGA or a general-purpose processor executing software) to operate in manner that is capable of performing the task(s) at issue. “Configured to” may also include adapting a manufacturing process (e.g., a semiconductor fabrication facility) to fabricate devices (e.g., integrated circuits) that are adapted to implement or perform one or more tasks. “Configurable to” is expressly intended not to apply to blank media, an unprogrammed processor or unprogrammed generic computer, or an unprogrammed programmable logic device, programmable gate array, or other unprogrammed device, unless accompanied by programmed media that confers the ability to the unprogrammed device to be configured to perform the disclosed function(s).
The foregoing description, for the purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the embodiments and its practical applications, to thereby enable others skilled in the art to best utilize the embodiments and various modifications as may be suited to the particular use contemplated. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
