Method, system, and computer program for testing a container orchestration system (generation of a test cluster for testing a container orchestration system)

Abstract

To provide a method, a system, and a computer program product for testing a container orchestration system.SOLUTION: A method includes replicating objects of a production cluster by extracting an object definition from an object and transforming the object definition to create a replicated object definition with an equivalent syntactic form. The replicated object definition requires fewer resources than the object definition. The method also includes applying the replicated objects of the production cluster to a simplified test cluster that replicates a configuration of the production cluster in a scaled down form. Additionally, the method includes testing, with the simplified test cluster, an upgraded version of the container orchestration system.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to container orchestration systems, and more particularly to testing container orchestration systems. [Background technology]

[0002] Complex applications can be broken down into independent parts called "microservices" that collaborate through messaging. Containers are used to deploy an application's microservices in the cloud. Multiple containers can be run together, or "orchestrated," so that each container runs a separate microservice and the combined set of microservices represents a complete application. A container orchestration system can take the form of a cluster management system that manages a clustered group of hosts, in the form of physical or virtual machines, on which the containers run. Summary of the Invention [Problem to be solved by the invention]

[0003] Development clusters are often less complex than the elements that run in production clusters, which means that there may be gaps in the elements that can be tested on the development cluster and safely applied to the production cluster. [Means for solving the problem]

[0004] Various embodiments are directed to a method of testing a container orchestration system. The method includes replicating a plurality of objects of a production cluster by extracting an object definition from an object and transforming the object definition to create a replicated object definition having an equivalent syntactic form. The replicated object definition requires fewer resources than the original object definition. The method also includes applying the replicated objects of the production cluster to a simplified test cluster that replicates the configuration of the production cluster in a scaled-down form. The method further includes testing an upgraded version of the container orchestration system using the simplified test cluster.

[0005] In some embodiments, the method includes detecting new objects in the production cluster, extracting new object definitions from the new objects, transforming the new object definitions to create new replicated object definitions, and applying the replicated objects with the new replicated object definitions to the simplified test cluster. The production cluster can be monitored for new objects. Transforming the object definitions can include modifying the object definitions using a set of rules that depend on the object type. In some embodiments, transforming the object definitions can include scaling back required resources to the minimum required for operation of the one object. The one object can be a deployment object. In these cases, transforming the object definitions can include scaling down the deployment to one replica, modifying a deployment image to a simple simulated operating system and applications with no running code and minimal resources, modifying a deployment image to an alternate image for running selected aspects of a container to check configuration, or simplifying checks. In some embodiments, the alternate image is user-configurable to test selected functional characteristics.

[0006] A further embodiment is directed to a system including a memory and a processor communicatively coupled to the memory, the processor configured to perform the method. A further embodiment is directed to a computer program product including a computer-readable storage medium with program instructions embodied therein, the program instructions being executable by the processor to cause a device to perform the method.

[0007] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. [Brief explanation of the drawings]

[0008] The drawings included in this disclosure are incorporated into and constitute a part of this specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings illustrate typical embodiments only and are not intended to limit the disclosure.

[0009] [Figure 1] FIG. 1 is a block diagram illustrating a container orchestration system according to some embodiments of the present disclosure.

[0010] [Figure 2] FIG. 1 is a flow diagram illustrating a process for generating simplified test clusters according to some embodiments of the present disclosure.

[0011] [Figure 3] FIG. 10 is a flow diagram illustrating a process for including a new object in the form of an exploded object, according to some embodiments of the present disclosure.

[0012] [Figure 4] FIG. 1 is a block diagram illustrating components of an object replication system according to some embodiments of the present disclosure.

[0013] [Figure 5] FIG. 1 is a block diagram illustrating a computer system according to some embodiments of the present disclosure.

[0014] [Figure 6] 1 is a block diagram illustrating a cloud computing environment in accordance with some embodiments of the present disclosure.

[0015] [Figure 7] FIG. 1 is a block diagram illustrating abstraction model layers according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0016] Aspects of the present disclosure relate generally to the field of container orchestration systems, and particularly to testing of container orchestration systems. While the present disclosure is not necessarily limited to such application, various aspects of the present disclosure can be understood through a discussion of various examples using this context.

[0017] Complex applications can be broken down into independent parts called "microservices" that cooperate through messaging, and the combined set of microservices can represent a complete application.

[0018] Containers can be used to deploy application microservices in the cloud. Containers can offer advantages over technologies such as virtual machines because they can be more portable, can be started and stopped more rapidly, and are more compatible with continuous integration and continuous delivery (CI / CD) systems. Multiple containers can be run together, or "orchestrated," with each container running a separate microservice, and the combined set of microservices represents a complete application. For example, Kubernetes® (Kubernetes is a trademark of The Linux Foundation) is an open-source container orchestration system for automating application deployment, scaling, and management.

[0019] As the number of containers grows significantly, a container orchestration system may be necessary, especially in CI / CD systems. Container orchestration systems can provide an automated system for managing, scheduling, networking, and monitoring containers. Container orchestration systems can make it possible to build application services that span multiple containers, schedule containers across clusters, scale those containers, and manage their health over time.

[0020] A container orchestration system can take the form of a cluster management system that can manage a clustered group of hosts, in the form of physical or virtual machines that run containers. The clusters can span hosts across public, private, and hybrid clouds.

[0021] Container orchestration systems can have rapidly changing ecosystems, with frequent updates to add new features and capabilities, often with numerous breaking changes. Within such systems, there are various resource types that can be grouped together to form environments, which can rely on complex connections between resource types. Groups of containers running within a cluster also often depend on other external services, such as databases or logging platforms.

[0022] Once completed, container orchestration system migrations can be nearly impossible to undo. Therefore, testing performed before a container orchestration system is upgraded can be extremely beneficial. If a user is moving a production cluster to a higher version of a container orchestration system, the user can perform a test upgrade on a development cluster. However, if the development cluster breaks, this can have a significant impact on developer productivity. Furthermore, development clusters are often less complex than the elements running in the production cluster, which means that there can be gaps in the elements that can be tested on the development cluster and safely applied to the production cluster.

[0023] Techniques for generating test clusters that can be used to test container orchestration systems are disclosed herein. In some embodiments, multiple objects in a production cluster are replicated by extracting an object definition from each object and transforming the object definition to create replicated object definitions that have equivalent syntactic form but require fewer resources, provide fewer functionality, or require fewer resources and provide fewer functionality. Object replication may be performed when new objects are added to the production cluster.

[0024] The replicated objects can be applied to a simplified test cluster to replicate the configuration of the production cluster in a scaled-down form. The simplified test cluster can be used to test upgrades to the container orchestration system or support systems while keeping up with the production cluster.

[0025] The syntax of the object definition is maintained, but a set of rules can be used to modify the object definition before it is applied to the test cluster so that resource usage is reduced and the actual functionality provided by the overall system is simulated or simplified.

[0026] It should be understood that the aforementioned advantages are exemplary advantages and should not be considered limiting. Embodiments of the present disclosure may include all, some, or none of the aforementioned advantages while remaining within the spirit and scope of the present disclosure.

[0027] Referring now to the drawings, Figure 1 is a block diagram illustrating a container orchestration system 100 according to some embodiments of the present disclosure. Container orchestration system 100 may include a production cluster 110, a test cluster 120, and an object replication system 130. Container orchestration system 100 may take the form of a cluster management system capable of managing a group of clustered hosts in the form of physical or virtual machines running containers, the hosts spanning public, private, and hybrid clouds.

[0028] A cluster in container orchestration system 100 can be a set of node machines for running containerized applications. In some embodiments, these containers are abstracted across the cluster rather than being tied to individual machines. Container definitions can be applied to a cluster along with other resources, such as file systems, and these resources are then run on the set of machines owned by the cluster. A cluster can remove actual machines from the definition of what needs to be run. Production cluster 110 can be one set of machines, and test cluster 120 can be another set of machines.

[0029] In some embodiments, test cluster 120 is provided in the form of a simplified version of production cluster 110, replicating the configuration of production cluster 110 in a scaled-down manner. This allows test cluster 120 to have fewer underlying machines than production cluster 110. Test cluster 120 can be used to test upgrades to container orchestration system 100 or supporting systems. Test cluster 120 can be upgraded to the latest version of container orchestration system 100 to test whether configuration deployment works without error on the updated system 100.

[0030] A container orchestration system can have objects that are persistent entities within a cluster and represent the state of the cluster. Objects can have a current status and a desired state, making the cluster a declarative system that acts to ensure that objects are in the desired state. Objects can describe which containerized applications are running, the resources available to the applications, and policies for the applications. Most objects can include an object definition (also referred to herein as a specification) and an object status. The object definition can be set when the object is created, providing a description of the characteristics the resources are intended to have to define the desired state of the object. The object status can be the current state of the object that is provided and updated by the container orchestration system.

[0031] Microservices can be deployed in containers, and a pod can be defined as a group of one or more containers running on a single worker node.

[0032] A production cluster 110 is shown with example objects 111-113 of different types. In this example, a deployment object 111, a service object 112, and a persistent volume object 113 are shown. Objects can be added to the production cluster 110 as they are specified by a user via an object application programming interface (API). In some embodiments, a service object 112 can map a fixed Internet Protocol (IP) address to a logical group of pods, and a persistent volume object 113 can define a provisioned storage abstraction. A deployment object 111 can be an object representing an application running on the cluster. When a deployment object 111 is created, the object definition can be configured to specify the number of replicas of the application that need to be run. If any replication instance fails and a status change occurs, the container orchestration system 100 can address the difference between the specification and the status and initiate a replacement instance.

[0033] Object replication system 130 is capable of detecting objects added to production cluster 110 and replicating them to test cluster 120. Test cluster 120 is shown to include exemplary replicated objects 121-123, which are replicas of objects 111-113, respectively. These replicated objects include replicated deployment object 121, replicated service object 122, and replicated persistent volume object 123.

[0034] The object replication system 130 can include an object detection component 131 that can detect new objects being added to the production cluster 110 and retrieve the corresponding object definitions. The object replication system 130 can also include an object transformation component 132 that can modify the object definitions. In some embodiments, these modifications can reduce the number of required resources and introduce simpler processing. The object replication system 130 can also include an object application component 133 that can create modified object definitions in the test cluster 120. The replicated objects with the modified definitions can then be applied to the test cluster 120.

[0035] The replicated objects 121-123 transformed by object transformation component 132 may be simpler and require fewer resources than the objects 111-113 in production cluster 110, and may not directly replicate production functionality. Object transformation component 132 may modify the configuration using a set of rules, and the transformation may depend on the type of object. In some embodiments, each modified object 121-123 may be applied to test cluster 120 such that the syntax of the configuration is maintained but resource usage, the actual functionality provided by system 100 overall, or both, is significantly reduced, thereby allowing complexity to be maintained.

[0036] The transformation may depend on the type of object. Deployment objects 111 run actual code and require resources (which can be mocked) to do so, which are discussed in more detail below. Similar to persistent volumes, other resources can also be scaled back to be as small as possible. This allows resources to be near zero when a running container is not running production code, so they may not require any actual space at all.

[0037] Figure 2 is a flow diagram illustrating a process 200 for generating simplified test clusters according to some embodiments of the present disclosure. To illustrate the process 200 without limiting the embodiments, Figure 2 is described within the context of the container orchestration system 100 of Figure 1. Where elements referenced in Figure 2 are the same as elements shown in Figure 1, the same reference numbers are used in both figures.

[0038] In operation 201, production cluster 110 may be monitored for new objects to be added. In operation 202, it may be determined whether a new object was added to production cluster 110 in operation 201. If a new object was not added, process 200 may return to operation 201 and continue monitoring production cluster 110 for new objects.

[0039] If a new object is detected in operation 202, process 200 may proceed to operation 203, where an object definition is extracted for the new object. In operation 204, the extracted object definition may be modified to generate a form that maintains the syntax of the original object definition extracted in operation 203, but requires fewer resources and provides less functional characteristics than the actual one (e.g., includes fewer functions).

[0040] In operation 205, the transformed object definitions may be applied to test cluster 120. By making these changes to the replicated test cluster 120, a simplified test cluster 120 may be generated in operation 206. In some embodiments, the simplified test cluster does not replicate the production system functionality, but replicates the configuration used by container orchestration system 100 in a scaled-down form.

[0041] At any point in the process 200, the test cluster 120 can be upgraded to the latest version of the container orchestration system 100 to test whether configuration deployment works without error on the updated system.

[0042] Figure 3 is a flow diagram illustrating a process 300 for including a new object in the form of a deployment object 111, according to some embodiments of the present disclosure. To illustrate the process 300 without limiting the embodiments, Figure 3 will be described within the context of the container orchestration system 100 of Figure 1. Where elements referenced in Figure 3 are the same as elements shown in Figure 1, the same reference numbers are used in both figures.

[0043] In operation 301, a new deployment object 111 may be added to the production cluster 110. The new deployment object 111 may then be discovered. In operation 302, a deployment object definition may be extracted from the new deployment object 111. The deployment object 111 runs actual code and therefore requires resources. In operation 303, the deployment object definition may be transformed to generate a form that maintains the syntax of the original deployment object definition extracted in operation 302 while requiring fewer resources and providing less functional characteristics than the actual one. In some embodiments, in operation 303, operations 311 through 313 are used to transform the deployment object definition.

[0044] In operation 311, the deployment may be scaled down to minimize resource usage. This may be achieved by scaling back resources to a minimum using various techniques. For example, scaling down may include using one replicated object. Scaling down may also include reducing resource usage to a minimum, such as memory, central processing unit (CPU), etc. For example, minimum usage may be the minimum amount required to start a pod or container.

[0045] In operation 312, the deployment image can be modified to use a simple simulated operating system (OS) and application. There may be a default simulated image that includes a minimal operating system imaged with no running code. For example, a simulated image for a container may include the smallest available OS and an application that is simply a shell script with a very long sleep. There may also be alternative images to exercise selected aspects of the container to check configuration. The alternative images may be configurable by the user to test selected functional characteristics. In some embodiments, there is an option for the user to provide their own simple image, which may have some functionality as desired.

[0046] In operation 313, readiness and liveness checks may also be simplified to account for other changes to the deployment object. In the simplest case, these checks may be eliminated. However, if the simulated image selected in operation 312 has a mechanism for checking readiness and / or liveness, these checks may be included. In operation 304, the transformed deployment object of operation 303 may be applied to test cluster 120.

[0047] As an example, the object definition of a deployment object 111 in a production cluster 110 may be: ------------------------------------------------------------------ kind: Deployment apiVersion: extensions / v1beta1 metadata: name: server1-deployment spec: replicas: 3 template: spec: containers: - name: server1 image: server1:1.7.9 resources: limits: CPU: 250M memory: 512M requests: CPU: 250M memory: 512M ------------------------------------------------------------------

[0048] For identical deployment type objects within a test cluster (eg, duplicate deployment object 121 within test cluster 120), the transformed object definition may be: ------------------------------------------------------------------ kind: Deployment apiVersion: extensions / v1beta1 metadata: name: server1-deployment spec: replicas: 1 template: spec: containers: - name: server1 image: server1_mock:1.7.9 resources: limits: CPU: 25M memory: 51M requests: CPU: 25M memory: 51M

[0049] The rules that apply to the above deployment type object definitions to affect the conversion may be as follows: Reduce replication to 1. If a mock version exists, change the image from the real image to the mock version and add "Mock" to the image name. Reduce memory and CPU to values ​​that the mock image can support.

[0050] Figure 4 is a block diagram illustrating components of an object replication system 130 according to some embodiments of the present disclosure. To illustrate the object replication system 130 without limiting the embodiments, Figure 4 will be described within the context of the container orchestration system 100 of Figure 1. Where elements referenced in Figure 4 are the same as elements shown in Figure 1, the same reference numbers are used in both figures.

[0051] The object replication system 130 may include at least one processor 401, hardware module, or circuitry for performing the functionality of the described components, which may be software units running on the processor. Providing multiple processors operating parallel processing threads may enable parallel processing of some or all of the functionality of the components. The object replication system 130 may also include memory 402. The memory 402 may be configured to provide computer instructions 403 to the at least one processor 401 to perform the functional characteristics of the components.

[0052] The object replication system 130 may include an object detection component 131 for detecting new objects in the production cluster 110 (FIG. 1). The object detection component 131 may include a production cluster monitoring component 411 for monitoring the production cluster 110 for new objects to be added. Additionally, the object detection component 131 may include a new object acquisition component 412.

[0053] The object replication system 130 may include an object transformation component 132 for replicating objects in the production cluster 110 by extracting an object definition from the object and transforming the object definition to create a replicated object definition having an equivalent syntactic form that may require fewer resources, provide less functionality, or both. The object transformation component 132 may include an object definition extraction component 421 for extracting an object definition from the new object, and an object definition transformation component 422 for transforming the object definition to create the replicated object definition. The object definition transformation component 422 may include a rule application component 423 for applying rules to transform different object types, and a configuration component 428 for configuring the rules.

[0054] As an example for a deployment object (e.g., deployment object 111 shown in FIG. 1 ), object definition conversion component 422 can include a deployment object conversion component 424 that includes a scale down component 425 for scaling down the deployment to one replica, minimal resource usage, or both, to start a pod or container. Object definition conversion component 422 can also include an image modification component 426, which in some embodiments can modify the deployment image to a simple simulated operating system and applications with no running code and a minimal set of resources. In further embodiments, image modification component 426 can modify the deployment image to an alternate image that can exercise selected aspects of the container to check the configuration. Object definition conversion component 422 can also include a check simplification component 427 for simplifying checks, such as readiness checks, liveness checks, or both.

[0055] The object replication system 130 may also include an object application component 133 for applying the replicated objects to a simplified test cluster 120 (FIG. 1) that can replicate the configuration of the production cluster 110 in a scaled-down form, and the simplified test cluster 120 can be used to test upgrades to the container orchestration system 100 or support systems.

[0056] In some embodiments, the production cluster 110 can be replicated to the test cluster 120, where the entire configuration to be produced is replicated in the test system. This approach can be used to configure the test cluster 120 if the production cluster 110 is modified. Alternatively, a one-off copy of the entire production configuration can be applied to the test cluster 120. Replicating a production cluster can be difficult because the production cluster can be very large and creating an identical replica can require a significant amount of resources. In these cases, operational pods may not function correctly in the replicated cluster or may interfere with production, for example, in the case of databases.

[0057] In some embodiments, it is possible to create a clone of the production cluster 110 to rapidly test the entire container orchestration infrastructure with new versions or new resources added, without requiring that individual software applications be running or properly set up. This can be achieved by removing objects, which can reduce the time and expense of testing breaking changes and version upgrades and eliminate the risk of disruption to developers.

[0058] Furthermore, this allows users to get the full complexity of the production cluster 110 with little effort and apply changes to production with more confidence. Fake pods can be brought into place of real pods, allowing applications to replicate clusters without introducing side effects, such as making changes to a production database from a test cluster. This allows the creation of interrelated resource definitions and for pods to pass their readiness checks.

[0059] By making these changes to the replicated test cluster 120, it is possible to create a simplified test cluster 120 that does not replicate the production system functionality, but does replicate in a scaled-down form the configuration used by orchestration system 100. In some embodiments, this allows for testing upgrades of container orchestration system 100 and supporting software so that issues in the orchestration configuration can be found before modifying the production cluster 110. For example, issues related to breaking configuration changes when migrating between versions can be found.

[0060] 5 is a block diagram illustrating an exemplary computer system 500 that can be used to implement (e.g., implement using one or more processor circuits of a computer or computer processor) one or more of the methods, tools, components, and any related functionality described herein. In some embodiments, the major components of computer system 500 include one or more processors 502, a memory subsystem 504, a terminal interface 512, a storage interface 516, an input / output device interface 514, and a network interface 518, all of which can be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 503, an input / output bus 508, a bus interface unit 507, and an input / output bus interface unit 510.

[0061] Computer system 500 includes one or more general-purpose programmable central processing units (CPUs) 502A, 502B, and 502N (collectively referred to herein as CPUs 502). In some embodiments, computer system 500 includes multiple processors typical of a larger system, while in other embodiments, computer system 500 may be a single CPU system. Each CPU 502 can execute instructions stored in memory subsystem 504 and may include one or more levels of on-board cache.

[0062] Memory 504 may include random-access semiconductor memory, storage devices, or storage media (volatile or non-volatile) for storing or encoding data and programs. In some embodiments, memory 504 represents the entire virtual memory of computer system 500 and may also include virtual memory of other computer systems coupled to computer system 500 or connected via a network. While memory 504 is conceptually a single, monolithic entity, in other embodiments, memory 504 is a more complex configuration, such as a hierarchy of multiple caches and other memory devices. For example, memory may exist in multiple levels of caches, and these caches may be further divided by function, so that some caches hold instructions and other caches hold non-instruction data used by one or more processors. Memory may be further distributed, each associated with a different CPU or set of CPUs, as known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures.

[0063] Container orchestration system 100 and its components (FIGS. 1 and 4) may be included in memory 504. However, in other embodiments, some or all of these components may reside on different computer systems and may be accessed remotely (e.g., over a network). Computer system 500 may use a virtual addressing mechanism that allows programs on computer system 500 to behave as if they can access only a single large storage entity and not multiple smaller storage entities. Thus, the components of memory 504 are not necessarily all contained entirely on the same storage device at the same time. Furthermore, while these components are shown as separate entities, in other embodiments, some of these components, portions of some of these components, or all of these components may be packaged together.

[0064] In some embodiments, container orchestration system 100 includes instructions that execute on processor 502 or that are interpreted by processor 502 to perform functions described further within this disclosure. In other embodiments, container orchestration system 100 is implemented in hardware via semiconductor devices, chips, logic gates, circuits, circuit cards, or other physical hardware devices, or combinations thereof, instead of or in addition to via a processor-based system. In other embodiments, container orchestration system 100 includes data in addition to instructions.

[0065] 5 as a single bus structure providing a direct communication path between CPU 502, memory subsystem 504, display system 506, bus interface 507, and I / O bus interface 510, in some embodiments memory bus 503 may include multiple distinct buses or communication paths, which may be arranged in any of a variety of configurations, such as point-to-point links in a hierarchical star or mesh configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Furthermore, while I / O bus interface 510 and I / O bus 508 are each shown as single units, in some embodiments computer system 500 may include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Furthermore, while multiple I / O interface units are shown separating I / O bus 508 from the various communication paths extending to the various I / O devices, in other embodiments some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0066] Computer system 500 may include a bus interface unit 507 for handling communications between processor 502, memory 504, display system 506, and input / output bus interface unit 510. I / O bus interface unit 510 may couple to an input / output bus 508 for transferring data to and from various input / output units. I / O bus interface unit 510 communicates with multiple input / output interface units 512, 514, 516, and 518 (also known as input / output processors (IOPs) or input / output adapters (IOAs)) through I / O bus 508. Display system 506 may include a display controller. The display controller may provide visual data, audio data, or both types of data to display device 505. Display system 506 may be coupled to display device 505, such as a standalone display screen, a computer monitor, a television, or a tablet or handheld device display. In alternative embodiments, one or more of the functions provided by display system 506 may be on-board an integrated circuit of processor 502. Additionally, one or more of the functions provided by bus interface unit 507 may be in on-board form on an integrated circuit of processor 502 .

[0067] In some embodiments, computer system 500 is a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 500 is implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0068] It should be noted that Figure 5 is intended to illustrate representative major components of an exemplary computer system 500. However, in some embodiments, the individual components may have greater or less complexity than depicted in Figure 5, there may be components other than or in addition to those shown in Figure 5, and the number, type, and configuration of such components may vary.

[0069] In some embodiments, the data storage and retrieval processes described herein may be implemented within a cloud computing environment, as described below with respect to FIGS.

[0070] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that practice of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0071] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0072] The characteristics are as follows:

[0073] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed without requiring human interaction with the service provider.

[0074] Wide network access: Capabilities are available over the network and are accessed through standard mechanisms that facilitate use by heterogeneous thin- or thick-client platforms (e.g., cell phones, laptops, and PDAs).

[0075] Resource Pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated according to demand. There is a type of location independence in that consumers generally have no control over or knowledge of the exact location of the resources provided, although the location may be specified at a higher level of abstraction (e.g., country, state, or data center).

[0076] Rapid scalability: Capacity can be provisioned quickly and elastically, sometimes automatically, and can be instantly scaled out or quickly released and instantly scaled in. To the consumer, this often feels like there is unlimited capacity available to provision, and any amount can be purchased at any time.

[0077] Measurable Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of utilized services.

[0078] The service model is as follows:

[0079] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0080] Platform as a Service (PaaS): The ability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but rather controls the deployed applications and, in some cases, the application hosting environment configuration.

[0081] Infrastructure as a Service (IaaS): The capability provided to consumers is to provision processing, storage, network, and other basic computing resources, allowing the consumer to deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0082] The deployment model is as follows:

[0083] Private Cloud: The cloud infrastructure is operated solely for one organization. It can be managed by the organization or a third party and can exist on-premise or off-premise.

[0084] Community Cloud: Cloud infrastructure is shared among several organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and regulatory compliance considerations). It can be managed by the organization or a third party and can reside on-premises or off-premises.

[0085] Public cloud: Cloud infrastructure is made available to the general public or a large industry organization and is owned by an organization that sells cloud services.

[0086] Hybrid Cloud: A cloud infrastructure that combines two or more clouds (private, community, or public), where each cloud remains a distinct entity but is bound together by standardized or proprietary technologies that allow for data and application portability (e.g., cloud bursting to load balance between clouds).

[0087] Cloud computing environments are service-oriented, emphasizing statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0088] 6 is a block diagram illustrating a cloud computing environment 50 according to some embodiments of the present disclosure. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described above. This enables the cloud computing environment 50 to provide infrastructure, platform, or software, or combinations thereof, as a service, without requiring the cloud consumer to maintain resources on their local computing device for the service. It should be understood that the types of computing devices 54A-54N shown in FIG. 6 are intended to be illustrative only, and that computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0089] 7 is a block diagram illustrating a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 6) in accordance with some embodiments of the present disclosure. It should be understood in advance that the components, layers, and functions illustrated in FIG. 7 are intended to be exemplary only, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

[0090] Hardware and software layer 60 includes hardware and software components. Example hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0091] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0092] In one example, management layer 80 provides the functions described below. Resource provisioning 81 dynamically procures computing and other resources used to execute tasks within the cloud computing environment. Metering and pricing 82 tracks costs as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security verifies the identity of cloud consumers and tasks and protects data and other resources. User portal 83 provides access to the cloud computing environment to consumers and system administrators. Service level management 84 allocates and manages cloud computing resources to ensure required service levels are met. Service level agreement (SLA) planning and fulfillment 85 proactively coordinates and procures anticipated future cloud computing resource needs according to SLAs.

[0093] The workload layer 90 provides example functional characteristics for which a cloud computing environment can be utilized. Examples of workloads and functions that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instructional delivery 93, data analytics processing 94, transaction processing 95, and object processing for container orchestration systems 96.

[0094] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0095] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, the computer-readable storage medium itself is not considered to be a transitory signal such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0096] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0097] The computer-readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk® or C++, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may run entirely on the user's computer, as a standalone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0098] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams or combinations thereof, and combinations of blocks in the flowchart illustrations or block diagrams or combinations thereof, can be implemented by computer-readable program instructions.

[0099] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to create a machine, such that the instructions, when executed by the computer processor or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or a combination thereof. These computer-readable program instructions may also be stored on a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, or other device, or a combination thereof, to function in a particular manner, such that the computer-readable storage medium having the instructions stored thereon comprises an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or both.

[0100] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0101] The flowcharts and block diagrams in the figures illustrate the architecture, functional characteristics, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implement a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be realized as a single step, executed simultaneously, substantially simultaneously, partially, or fully in a time-overlapping manner, or the blocks may possibly be executed in the reverse order depending on the functional characteristics involved. It should also be noted that each block of a block diagram or flowchart diagram, or a combination thereof, and combinations of blocks in block diagrams or flowchart diagrams, or a combination thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0102] The description of various embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art that do not depart from the scope and spirit of the described embodiments. The terminology used herein has been selected to best explain the principles of the embodiments, practical applications of, or technical improvements to, the technology found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0103] While the present disclosure has been described with reference to specific embodiments, it is anticipated that variations and modifications thereof will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted to cover all such variations and modifications as fall within the true spirit and scope of the present disclosure.

[0104] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of various embodiments. 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" or "comprising," or combinations thereof, when used herein, specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0105] In the foregoing detailed description of exemplary embodiments of various embodiments, reference has been made to the accompanying drawings, in which like numerals represent like elements, which form a part of this specification and in which are shown, by way of illustration, specific exemplary embodiments in which the various embodiments may be practiced. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the embodiments, but other embodiments may be used, and logical, mechanical, electrical, and other changes may be made without departing from the scope of the various embodiments. In the foregoing description, numerous specific details were set forth to provide a thorough understanding of the various embodiments. However, the various embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the embodiments.

[0106] Where different reference numerals include a common number followed by a different letter (e.g., 100A, 100B, 100C, 100N), or a common number followed by a punctuation followed by a different number (e.g., 100-1, 100-2, or 100.1, 100.2), the use of the reference numeral alone (e.g., 100) without a letter or a following number may also refer to the entire group of elements, any subset of the group, or an illustrative example of the group.

[0107] As used herein, "a number of," when used in reference to an item, means one or more of the item. For example, "several different types of networks" is one or more different types of networks.

[0108] Furthermore, the phrase "at least one of," when used in conjunction with a list of items, means that various combinations of one or more of the listed items may be used, and only one of each item in the list may be required. In other words, "at least one of" means that any combination of items and any number of items from the list may be used, but not all of the items in the list are required. An item may be a particular object, thing, or category.

[0109] For example, "at least one of item A, item B, or item C" may include, but is not limited to, item A, item A and item B, or item B. This example may also include item A, item B, and item C, or item B and item C. Of course, any combination of these items may be present. In some instances, "at least one of" may be, without limitation, for example, two of item A, one of item B, ten of item C, four of item B, seven of item C, or other suitable combinations.

Claims

1. A method for testing a container orchestration system using a computer, comprising: The computer replicating a plurality of objects in a production cluster, extracting an object definition from an object by the computer; transforming, by the computer, the object definition to create a replicated object definition having an equivalent syntactic form, the replicated object definition requiring fewer resources than the object definition; a replicating step comprising: applying the replicated objects of the production cluster to a simplified test cluster that replicates the configuration of the production cluster in a scaled-down form; testing the upgraded version of the container orchestration system using the simplified test cluster by the computer; A method for providing

2. A step in which the computer detects new objects in the production cluster; extracting, by the computer, a new object definition from the new object; transforming the new object definition to create a new replicated object definition; applying the new replicated object having the new replicated object definition to the simplified test cluster by the computer; The method of claim 1 further comprising:

3. The method of claim 2, further comprising a step in which the computer monitors the production cluster for new objects.

4. 4. The method of claim 1, wherein transforming the object definition comprises modifying the object definition using a set of rules that are dependent on the object type.

5. 4. The method of claim 1, wherein the step of converting the object definition includes scaling back required resources to the minimum required for operation of the one object.

6. The method of claim 1 , wherein the one object is a deployment object, and wherein transforming the object definition comprises scaling down the deployment to one replica.

7. 4. The method of claim 1, wherein the one object is a deployment object, and converting the object definition comprises modifying the deployment image into a simple simulated operating system and applications with no running code and minimal resources.

8. 4. The method of claim 1, wherein the one object is a deployment object, and converting the object definition includes modifying a deployment image to an alternative image for operating selected aspects of a container to check configuration.

9. 9. The method of claim 8, wherein the alternate images are user configurable to test selected functional properties.

10. 4. The method of claim 1, wherein the one object is an expanded object, and the step of transforming the object definition includes the step of simplifying checking.

11. 1. A system for testing a container orchestration system, comprising: Memory and a processor communicatively coupled to the memory; Equipped with The processor is configured to perform a method, the method comprising: replicating a plurality of objects of a production cluster, Extracting an object definition from an object; transforming the object definition to create a replicated object definition having an equivalent syntactic form, the replicated object definition requiring fewer resources than the object definition; a replicating step comprising: applying the replicated objects of the production cluster to a simplified test cluster that replicates the configuration of the production cluster in a scaled-down form; testing the upgraded version of the container orchestration system using the simplified test cluster; Including, system.

12. The method comprises: detecting new objects in the production cluster; extracting a new object definition from the new object; transforming the new object definition to create a new replicated object definition; applying the replicated object with the new replicated object definition to the simplified test cluster; Further comprising: The system of claim 11.

13. The system of claim 12 , wherein the method further comprises monitoring the production cluster for new objects.

14. 14. The system of claim 11, wherein transforming the object definition comprises modifying the object definition using a set of rules that are dependent on the object type.

15. 14. The system of claim 11, wherein transforming the object definition includes scaling back required resources to a minimum required for operation of the one object.

16. 14. The system of claim 11, wherein the one object is a deployment object, and wherein transforming the object definition comprises scaling down the deployment to one replica.

17. 14. The system of claim 11, wherein the one object is a deployment object, and converting the object definition includes modifying a deployment image to an alternative image for operating selected aspects of a container to check configuration.

18. 20. The system of claim 17, wherein the alternate images are user configurable to test selected functional properties.

19. 14. The system of claim 11, wherein the one object is a deployment object, and wherein transforming the object definition includes simplifying checking.

20. 1. A computer program for testing a container orchestration system, the computer program comprising: A method for replicating a plurality of objects in a production cluster, the method comprising: extracting an object definition from an object; transforming the object definition to create a duplicated object definition having an equivalent syntactic form, the duplicated object definition requiring fewer resources than the object definition; a replicating step having applying the replicated objects of the production cluster to a simplified test cluster that replicates the configuration of the production cluster in a scaled-down form; testing the upgraded version of the container orchestration system using the simplified test cluster; A computer program for executing

Images