USING A DISTANT PODS IN KUBERNETES

By running virtual pod machines remotely from virtual worker nodes with an overlay network, Kubernetes systems overcome performance issues, ensuring better isolation and efficiency in CPU, memory, and disk utilization.

DE112022003720B4Active Publication Date: 2026-05-07INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 3 Cites 0 Cited by

Patent Information

Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
INTERNATIONAL BUSINESS MACHINE CORPORATION
Filing Date
2022-08-05
Publication Date
2026-05-07

AI Technical Summary

Technical Problem

Existing Kubernetes systems face performance issues with nested virtual machines, leading to CPU, memory, and I/O inefficiencies when running software applications in pods.

Method used

Implementing a system where virtual pod machines run as remote peers to virtual worker nodes, using an overlay network for data exchange and maintaining logical connectivity, allowing them to operate independently while sharing the same network.

Benefits of technology

This approach improves isolation and performance of virtual pod machines by avoiding nested virtual machine drawbacks, enhancing CPU, memory, and disk utilization, and enabling extensibility across different host machines.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

Implementations are designed for the use of remote pods. Intermediate software is instantiated in a virtual worker node machine and used to cause the creation of a virtual pod machine, which is remote from the virtual worker node machine. An overlay network is established between the intermediate software in the virtual worker node machine and a pod storage area in the virtual pod machine. The overlay network is used to cause containers to be created in the virtual pod machine, with the virtual worker node machine configured to use the overlay network to manage transfers with the virtual pod machine.
Need to check novelty before this filing date? Find Prior Art

Description

BACKGROUND

[0001] The present invention relates generally to computer systems and in particular to computer-executed methods, computer systems and computer program products that are configured and arranged for use with remote pods in Kubernetes.

[0002] Kubernetes, commonly known as K8s, is an open-source container orchestration system for automating the deployment, scaling, and management of computing applications. Specifically, it aims to provide a platform for automating the deployment, scaling, and operation of application containers across clusters of hosts. Kubernetes works with a suite of container tools and runs containers within a cluster, often using images built with Docker. Docker is a suite of Platform as a Service (PaaS) products that use operating system (OS)-level virtualization to deliver software in packages called containers. Containers are isolated from each other, bundling their own software, libraries, and configuration files; containers can communicate with each other through clearly defined channels.All containers can share the services of a single operating system kernel. The basic scheduling unit in Kubernetes is a pod. A pod is a grouping of containerized components. A pod comprises one or more containers, all of which are guaranteed to reside on the same node. Many cloud services offer a Kubernetes-based platform or Infrastructure as a Service (IaaS), where Kubernetes can be used as a platform-providing service. A scheduler is the modular component that selects, based on resource availability, which node an unscheduled pod (i.e., the basic entity managed by the scheduler) will run on. The scheduler monitors resource utilization on each node to ensure that workload scheduling does not exceed available resources.While existing techniques for pods with containers configured to launch and run a software application on a node in the cloud are suitable for their intended purposes, a system is needed that has certain features of embodiments of the present invention.

[0003] US 2020 0 073 692 A1 describes techniques for creating multiple virtual network interfaces that can be used by a logically connected group of one or more containers (“pods”) for communication within their respective virtual networks of a network infrastructure. In some examples, a control flow for configuring the pod's network interface on a host involves a CNI instance retrieving a list of multiple virtual network interfaces from a network controller agent running on the host. The single CNI instance processes the list of multiple virtual network interfaces to create corresponding virtual network interfaces for the pod and, for each virtual network interface, connects the virtual network interface to the pod and to the virtual router or bridge on the host.In this way, the single CNI enables packetized communication through containers of the pod across multiple networks using the multiple virtual network interfaces configured for the pod.

[0004] US 2021 0 058 327 A1 describes techniques for defining a virtual backend network for service load balancing.An example of an orchestrator is configured to receive a service definition for a service that is implemented by load balancing the service traffic for the service between a multitude of virtual backend execution elements, where the service definition specifies a first virtual network to be used as the virtual backend network for the service, to instantiate a virtual backend execution element for the service in one of the selected computer devices, and to configure a network controller for the virtualized computing infrastructure based on the service definition specifying the first virtual network to be used as the virtual backend network for the service, in order to configure a load balancer that balances the service traffic to a first virtual network interface of the virtual backend element for the first virtual network.

[0005] US 2021 O 141 655 A1 describes various examples of unified resource management for containers and virtual machines. A podVM resource configuration for a pod virtual machine (podVM) is determined using container configurations. The podVM comprises a virtual machine (VM) that provides resource isolation for a pod based on the podVM resource configuration. A host selection for the podVM is received from a VM scheduler. The host selection identifies hardware resources for the podVM. A container scheduler is constrained to bind the podVM to a node that matches the hardware resources of the host selection from the VM scheduler. The podVM is created on a host that matches the host selection. Containers are started within the podVM. The containers conform to the container configurations. SUMMARY

[0006] Embodiments of the present invention are directed to computer-executed methods for using remote pods in Kubernetes. A non-limiting, exemplary computer-executed method comprises instantiating intermediate software in a virtual worker node machine, the intermediate software being used to cause the creation of a virtual pod machine, wherein the virtual pod machine is remote from the virtual worker node machine, and causing an overlay network to be established between the intermediate software in the virtual worker node machine and a pod storage area in the virtual pod machine.The procedure, executed by a computer, involves using the overlay network to cause containers to be created in the virtual pod machine, with the virtual worker node machine being configured to use the overlay network to manage transfers (e.g., data, traffic, etc.) with the virtual pod machine.

[0007] This can provide an improvement over known methods for pods, which is based at least in part on the fact that the virtual pod machine is remote from the virtual worker node machine and an overlay network is used for remote data exchange.

[0008] In addition to one or more of the features described above or below, or alternatively, in further embodiments of the invention, the intermediate software is configured to create a proxy network storage area in an isolated data processing environment on the virtual worker node machine. This advantageously provides an improvement that acts as a proxy for the remote virtual pod machine to send traffic to and from the virtual worker node machine.

[0009] In addition to one or more of the features described above or below, or alternatively, in further embodiments of the invention, the intermediate software is configured to cause a logical network to be connected between a proxy network memory area on the virtual worker node machine and the pod memory area on the virtual pod machine. This advantageously provides an improvement that ensures the virtual worker node machine operates as if the remote virtual pod machine were present on / in the virtual worker node machine (and connected to it via an interface).

[0010] In addition to one or more of the features described above or below, or alternatively, in further embodiments of the invention, an Internet Protocol (IP) address is assigned to a proxy network memory area of ​​the virtual worker node machine, and the intermediate software is configured to reassign the IP address to the pod memory area. This advantageously provides an improvement that allows the remote virtual pod machine to be operated as if it were located on the virtual worker node machine.

[0011] In addition to one or more of the features described above or below, or alternatively, in further embodiments of the invention, upon receiving a container intended for an isolated data processing environment on the virtual worker node machine, the container is transferred to the virtual pod machine to be allocated to the pod memory area, with the intermediate software being configured to cause a software application to be instantiated in the container on the virtual pod machine. This advantageously provides an improvement that allows the remote virtual pod machine to run on a host machine separate from the virtual worker node machine while remaining on the same logical network.

[0012] Further embodiments of the present invention incorporate features of the method described above into computer systems and computer program products.

[0013] Additional technical features and advantages are realized through the techniques of the present invention. Embodiments and aspects of the invention are described in detail herein and are considered part of the claimed subject matter. For a better understanding, reference is made to the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The specific features of the exclusive rights described herein are particularly highlighted and clearly claimed in the claims at the end of the specification. The foregoing features and other characteristics and advantages of the embodiments of the invention will become apparent from the following detailed description in conjunction with the accompanying drawings, which: Fig. 1 represents a block diagram of an exemplary computer system for use in conjunction with one or more embodiments of the present invention; Fig. 2 represents a block diagram of a system used to provide and use remote pods in Kubernetes according to one or more embodiments of the present invention; Fig. 3 represents a block diagram of a node and pod hierarchy in a system that serves to provide and use remote pods as virtual machines in Kubernetes according to one or more embodiments of the present invention; Fig. 4 represents a block diagram of an example architecture in the system that serves to provide and use remote pods as virtual machines in Kubernetes according to one or more embodiments of the present invention; Fig. 5 represents a flowchart of a process executed by a computer for the purpose of providing and using remote pods as virtual machines for Kubernetes according to one or more embodiments of the present invention; Fig. 6 represents an example network architecture in the system that serves to provide and use remote pods as virtual machines in Kubernetes according to one or more embodiments of the present invention; Fig. 7 represents a flowchart of a process executed by a computer for the purpose of provisioning and using remote pods as virtual machines in Kubernetes according to one or more embodiments of the present invention; Fig. 8 represents a cloud computing environment according to one or more embodiments of the present invention; and Fig. 9 abstraction model layers according to one or more embodiments of the present invention. DETAILED DESCRIPTION

[0015] One or more embodiments of the present invention provide computer-executed methods, computer systems, and computer program products that are arranged and configured for use with remote pods in Kubernetes. One or more embodiments of the invention introduce a novel worker and pod hierarchy in which a virtual pod machine logically belongs to a virtual worker node machine, but the virtual pod machine physically runs in a virtual machine that is remote from the virtual worker machine. Therefore, the virtual pod machine has both better isolation and better performance because it resides in its own virtual machine.

[0016] In a typical Kubernetes cluster, the workload (e.g., a software application) runs within a pod as a container, which is a process on a worker node. Kata Containers, which is open-source and Open Container Initiative (OCI) compliant, introduced a virtual machine as a pod, allowing workloads to run within a virtual guest machine on a worker node for a cloud-native application. However, the Kata pod running as a virtual guest machine on the virtual worker node machines causes performance issues. Specifically, a second-tier or nested virtual machine typically experiences a 5-10% loss in central processing power (CPU) and memory usage / efficiency, and an even greater loss in input / output (I / O) performance, such as input / output operations per second (IOPS).In a worst-case scenario, the downgrade in I / O is approximately 30%.

[0017] One or more embodiments provide a new system that ensures the virtual pod machine (physically) runs as a virtual peer machine, while logically still belonging to the virtual worker node machine. In this way, the system is consistent with Kubernetes functionality and avoids the performance losses / issues of a nested virtual machine in Kata. Technical advantages include improved isolation between a virtual worker node machine and a remote virtual pod machine, as the worker node, according to one or more embodiments, cannot directly access the managed remote virtual pod machines. These technical advantages include improved performance of the remote virtual pod machines in terms of CPU, memory, and disk utilization / performance.Furthermore, one or more embodiments prove to be more extensible, since the remote virtual pod machines are not limited by the resources of the virtual worker node machine and can be used on any host machine.

[0018] With regard to Fig. Figure 1 is a computer system 100 according to one or more embodiments of the invention, generally shown. The computer system 100 can be an electronic computer framework that includes and / or utilizes any number and combination of data processing units and networks, employing various transmission technologies as described herein. The computer system 100 can be easily scalable, expandable, and modular, with the ability to switch to different services or to reconfigure some features independently of others. For example, the computer system 100 can be a server, a desktop computer, a laptop computer, a tablet computer, or a smartphone. In some examples, the computer system 100 can be a cloud computing node.Computer System 100 can be described in the general context of instructions executable by a computer system, such as program modules that are executed by a computer system. In general, program modules can include routines, programs, objects, components, logic, data structures, and so on, that perform specific tasks or execute certain abstract data types. Computer System 100 can be implemented in distributed cloud computing environments, where tasks are performed by remote processing units connected by a transmission network. In a distributed cloud computing environment, program modules can reside in both local and remote storage media of a computer system, including main memory units.

[0019] As in Fig. As shown in Figure 1, the computer system 100 has one or more central processing units (CPUs) 101a, 101b, 101c, etc. (collectively or generally referred to as processor(s) 101). The processors 101 can be a single-core processor, a multi-core processor, a data processing cluster, or any number of other configurations. The processors 101, also referred to as processing circuits, are coupled via a system bus 102 to a system memory 103 and various other components. The system memory 103 can include a read-only memory (ROM) 104 and a random-access memory (RAM) 105. The ROM 104 is coupled to the system bus 102 and can include a basic input / output system (BIOS) or its successor, such as a unified extensible firmware interface (UEFI), which controls certain basic functions of the computer system 100.RAM is a read / write memory coupled to the system bus 102 for use by the processors 101. System memory 103 provides temporary main memory space for instruction operations during operation. System memory 103 can include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0020] The computer system 100 includes an input / output (I / O) adapter 106 and a transfer adapter 107, which are connected to the system bus 102. The I / O adapter 106 can be a Small Computer System Interface (SCSI) adapter that exchanges data with a hard disk 108 and / or any other similar component. The I / O adapter 106 and the hard disk 108 are collectively referred to herein as mass storage 110.

[0021] Software 111 for execution on the computer system 100 can be stored in the mass storage device 110. The mass storage device 110 is an example of a tangible storage medium readable by the processors 101, wherein the software 111 is stored in the form of instructions for execution by the processors 101 to cause the computer system 100 to carry out its operation as described below with reference to the various figures. Examples of a computer program product and the execution of such an instruction are described in more detail herein. The transmission adapter 107 connects the system bus 102 to a network 112, which may be an external network, thus enabling the computer system 100 to exchange data with other such systems.In a single embodiment, a portion of the system memory 103 and the mass storage 110 jointly store an operating system, which can be any suitable operating system, to perform the functions of the various, in . Fig. to coordinate the components shown in section 1.

[0022] Additional input / output units are shown connected to the system bus 102 via a screen adapter 115 and an interface adapter 116. In a single embodiment, the adapters 106, 107, 115, and 116 can be connected to one or more I / O buses that are connected to the system bus 102 via an intermediate bus bridge (not shown). A screen 119 (e.g., a display or monitor) is connected to the system bus 102 through the screen adapter 115, which may include a graphics control unit to improve the performance of graphics-intensive applications and a video controller. A keyboard 121, a mouse 122, a speaker 123, etc., can be connected to the system bus 102 via the interface adapter 116, which may, for example, include a super I / O chip that combines several unit adapters into a single integrated circuit.Suitable I / O buses for connecting peripheral devices such as hard drive controllers, network adapters, and graphics adapters typically use common protocols such as Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCle). Thus, as in... Fig. Configured as 1, the computer system includes processing functionality in the form of processors 101 and storage functionality, including system memory 103 and mass storage 110, input devices such as the keyboard 121 and mouse 122, and output functionality, including the speaker 123 and the screen 119.

[0023] In some embodiments, the transmission adapter 107 can transmit data using any suitable interface or protocol, such as the Internet Small Computer System Interface, among others. The network 112 can be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, among others. An external data processing unit can be connected to the computer system 100 through the network 112. In some examples, the external data processing unit can be an external web server or a cloud computing node.

[0024] Let it be made clear from the outset that the block diagram of Fig. 1 should not be interpreted as meaning that the computer system 100 can handle all of the in Fig. The computer system is not intended to include the components shown in point 1. Rather, it may include 100 fewer or additional corresponding components, which are shown in point 1. Fig. 1 are not illustrated (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Furthermore, the embodiments described herein with reference to computer system 100 can be implemented with any appropriate logic, wherein the logic, as defined herein, can comprise any suitable hardware (e.g., a processor, an embedded controller, or an application-specific integrated circuit, etc.), software (e.g., an application, etc.), firmware, or any suitable combination of hardware, software, and firmware in various embodiments.

[0025] Fig. Figure 2 is a block diagram of a system 200 used to provision and use remote pods in Kubernetes according to one or more embodiments of the present invention. The system 200 comprises a computer system 202 coupled with computer systems 251, 252, 253, and 254. The computer system 202 can be referred to as a control node, master node, Kubernetes deployment controller, etc. The computer system 202 can be part of the control plane. The computer systems 251, 252, 253, and 254 can each be a server in a cluster. For illustrative purposes, the computer systems 251, 252, 253, and 254 can each host one or more worker nodes in the cluster and are generally referred to as computer systems 251 to 254. The computer systems 251 to 254 can be hosts or host machines for nodes and for running virtual machines, as described in more detail herein.Computer system 202 and computer systems 251 to 254 can perform all elements and functions of the in . Fig. The computer system described in 1 comprises 100 components to operate according to one or more embodiments.

[0026] Kubernetes has a control plane / control console at the top, also known as the master node. After the control plane (e.g., computer system 202) receives a workload, which is the application, an API server 204 stores the application in "etcd" as an API object. In Kubernetes, the controller manager is responsible for orchestrating the control cycle. This control cycle is used to perform orchestration, helping to create the pods required by these applications. Once a pod is created, the scheduler monitors the changes to the new pod. When the scheduler finds a new pod, it assists in executing the scheduling algorithms and writing the execution result (e.g., the name of a node in the NodeName field of the pod object, which is called the binding operation).The scheduler then writes the binding result back to etcd, which is the scheduler's work process. Consequently, the pod is bound to a node, a process known as scheduling. For example, the pod is bound to a worker node.

[0027] The Kubelet (e.g. the Kubelet 312 in Fig. 3) It monitors changes to all pod objects, and when it detects that a pod is bound to a node, the kubelet performs all subsequent tasks. After receiving this information, the kubelet invokes the containerd process running on each machine and executes each container in that pod. At this point, containerd (e.g., CRI 314 in Fig. 3) Call other runtimes (e.g., runc, shim, etc.). Consequently, runtimes can help set up these namespaces and cgroups, and they can help create a container required by an application.

[0028] Fig. Figure 3 is a block diagram of a node and a pod hierarchy in the system 200, which serves to provide and use remote pods in Kubernetes according to one or more embodiments of the present invention. Fig. 3 represents a virtual worker node machine 310, a virtual pod machine 301, a virtual pod machine 302, and a virtual pod machine 303. Virtual worker node machine 310 can run on the same and / or different host machines as virtual pod machines 301, 302, and 303 in any combination of options, where virtual pod machines 301, 302, and 303 could reside on the same and / or different host machines. For example, virtual worker node machine 310 and virtual pod machine 301 can run on the same host machine, such as computer system 251. Alternatively, virtual worker node machine 310 and virtual pod machine 301 can run on two different host machines, such as computer system 251 and computer system 252, respectively. Similarly, the virtual worker node machine 310 and the virtual pod machine 302 can run on the same host machine (e.g.,Both virtual worker node machines (301, 302, 303) can be executed on computer system 251 and / or on different host machines (e.g., one on computer system 251 and one on computer system 253). Likewise, the virtual worker node machine 310 and the virtual pod machine 303 can be executed on the same host machine (e.g., both on computer system 251) and / or on different host machines (e.g., one on computer system 251 and one on computer system 254). Although each virtual pod machine 301, 302, 303 can be bound to a virtual worker node machine 310, it should be clear that each of the virtual pod machines 301, 302, 303 can be executed on its own host machine, which could be different from the host machine that executes the virtual worker node machine 310. Although three pods are described for explanatory purposes, it should be clear that embodiments are not to be understood as being limited to three pods.Furthermore, each host machine, such as computer systems 251 through 254, has its own host operating system running its own hypervisor. If a virtual pod machine 301, 302, or 303 is running on a different host machine and / or computer system than the virtual worker node machine 301, the hypervisor for each other host machine and / or computer system must be located on the same logical network.

[0029] The control plane has one or more Application Programming Interface (API) servers (204) configured to exchange data with a kubelet (312). The API server (204), also known as an API server or APIserver, is a simple web application that allows Kubernetes to create and expose data APIs without requiring custom development. The kubelet is the primary "node agent" running on each worker node. The kubelet registers the node with the APIserver using one or more of the following: the hostname, a flag to override the hostname, and / or special logic for a cloud provider. The kubelet uses and works with a pod descriptor, such as PodSpec. A PodSpec is a YAML or JSON object that describes a pod.Kubernetes resources are created declaratively and therefore utilize, for example, YAML files. Kubernetes resources, such as pods, services, and deployments, can be created using YAML files, as any expert understands. The Kubelet uses a set of PodSpecs, provided through various mechanisms (primarily the API server), and ensures that the containers described in these PodSpecs are active and error-free.

[0030] In Fig. The virtual worker node machine 310 has the kubelet 312, which is configured to use a container runtime interface (CRI) 314 to create one or more shims 320_1, 320_2, 320_3. Shims 320_1, 320_2, and 320_3 can be collectively referred to as the shims 320. Each Shim 320_1, 320_2, 320_3 has a one-to-one relationship to its own virtual pod machine 301, 302, and 303, respectively. Each individual Shim 320_1, 320_2, 320_3 is configured to create its own virtual pod machine 301, 302, and 303, respectively, so that the virtual pod machines 301, 302, and 303 are not nested within virtual guest machines of the virtual worker node machine 310.A container network interface (CNI) 316 is configured to ensure that the IP network system in the virtual pod machines 301, 302, and 303 is managed by the IP network system in the virtual worker node machine 310. The CRI 314, the CNI 316, and the shims 320_1, 320_2, and 320_3 are all computer-executable software components that run on a processor, such as the 101 processors.

[0031] CRI 314 is sometimes referred to as CRI containerd, containerd, containerd CRI, etc. CRI 314 is a higher-level runtime and daemon, which can be thought of as an API faceplate for other runtimes in the stack. While lower-level runtimes like runc are responsible for the actual execution of a container, a higher-level runtime like containerd is responsible for container lifecycles, image management, and abstraction to a lower-level runtime. While lower-level runtimes provide mechanisms for creating containers, containerd has mechanisms for creating container platforms and an API used by remote applications for monitoring and delegation. CRI includes APIs, specifications / requirements, and libraries for container runtimes for integration into Kubelet on a node.CNI 316 is a runtime and / or specification for managing network resources on a cluster. CNI consists of a specification and libraries for writing plugins to configure network interfaces in containers, along with several supported plugins. CNI deals with container network connectivity and the removal of associated resources when the container is deleted. Because of this focus, CNI has extensive support and the specification is easy to implement. If a Kubernetes component is unable to exchange data with another component, a Shim 320 is a piece of software configured to translate between that component and the corresponding Kubernetes interface. For example, the Shim 320 receives CRI commands and translates them into something that an Agent 420 (in . Fig. (as shown in Figure 4) and vice versa. Furthermore, the container runtime shim is a piece of software that sits between a container manager (containerd, cri-o, podman) and a container runtime (runc, crun), thus resolving the integration problems of these counterparts.

[0032] To provide further details, Fig. Figure 4 shows a block diagram of an example architecture in System 200, which serves to provide and use remote pods as virtual machines in Kubernetes according to one or more embodiments of the present invention. For clarity, the computer system 202 is the control plane in Fig. 4 is omitted, but is considered present. Fig. Figure 4 presents an example that uses the Shim 320_1 in the virtual worker node machine 310 to deploy, create, and / or configure a virtual pod machine 301 remotely from the virtual worker node machine 310. The virtual pod machine 301 could be hosted on a separate host machine remote from the host machine running the virtual worker node machine 310. Alternatively, the virtual pod machine 301 could be hosted on the same host machine as the virtual worker node machine 310, while still residing in a separate or remote virtual machine.Although examples may describe the use of Shim 320_1 in the virtual worker node machine 310 to set up a virtual pod machine 301, it should be clear that the description applies accordingly to Shim 320_2 to set up the virtual pod machine 302 and Shim 320_3 to set up the virtual pod machine 303.

[0033] Fig. Figure 5 is a flowchart of a computer-executed process 500, which serves to provision and use remote pods as virtual machines for Kubernetes according to one or more embodiments of the present invention. The computer-executed process 500 in Fig. Process 5 can be executed using System 200. Consequently, the process 500, executed by a computer, will now be described with reference to System 200.

[0034] At block 502, virtual worker node machine 310 is configured to receive the pod description, or pod descriptor, to create a new pod in the cluster on a host machine. For example, kubelet 312 is configured to receive the pod description from computer system 202. The pod description can include pod specifications (e.g., PodSpecs) and may be in YAML or JSON files. Every Kubernetes deployment uses a pod template. This pod template provides a specification that determines what the pod should look like, which application will run in the pod's containers, and more, as a practitioner would understand. Using the scheduler, the controller manager of computer system 202 can match or assign the pod to virtual worker node machine 310.

[0035] In Block 504, the virtual worker node machine 310 is configured to use the kubelet 312 to monitor the pod and invoke a sandbox function (as an environment) in runtime software (which has instructions executable by a computer). In one or more embodiments, the shim 320_1 can invoke the sandbox function as a computational environment after the shim 320_1 has started, as described below. The sandbox 460, or pod sandbox, is an isolated computational environment on a virtual worker node machine. For example, the kubelet 312 is configured to invoke a sandbox function (e.g., execute pod sandbox) in the CRI 314 to start the execution of the pod. A sandbox is a security mechanism used to isolate active programs, usually in an effort to contain the spread of system errors and / or software vulnerabilities.The sandbox is often used to run programs or code without risking damage to the host machine or operating system. Kubelet 312 and / or CRI 314 can call CNI 316.

[0036] At block 506, the virtual worker node machine 310 is configured to start / create a new shim 320_1 to prepare the new pod, if one hasn't already been created previously. For example, CRI 314 can call shim 320_1 to create the remote virtual machine for the new pod. Shim 320_1 is configured to create / start a shell pod 464 in the pod sandbox (environment), so that shim 320_1 and / or the SHELL pod of virtual worker node machine 310 appear as the actual virtual pod machine. Shell pod 464 can be an incomplete pod used as a placeholder for the virtual pod machine that will be created. More precisely, the virtual worker node machine 310 interacts with the shim 320_1, which manages / runs the pod sandbox 460, which has the shell pod 464, so that the shim 320_1 is a proxy of the pod.The virtual worker node machine 310 sees and / or recognizes the shim 320_1, which manages / runs the pod sandbox 460 (which has the shell pod 464), as an actual virtual pod machine due to the shell pod 463. The shell pod 464 is started like any other pod, but is stopped before it is fully configured.

[0037] In block 508, the virtual worker node machine 310 is configured to use shim 320_1 to invoke a virtual (pod) machine service 432, causing the virtual machine's service 432 to create / instantiate the virtual pod machine 301. Shim 320_1 contains computer-executable instructions to exchange data with the virtual machine's service 432 and request that the virtual pod machine 301 be created on a host machine. The virtual machine's service 432 is a service for the cluster and provides access to an endpoint. Shim 320_1 of worker node 310 invokes the virtual machine's service 432 because it needs a service endpoint, and the virtual machine's service 432 then selects a host machine (e.g., a computer system) according to its policy, such as host resource usage.For example, the virtual worker node machine 310 can be hosted on computer system 251, and the virtual pod machine 301 could be hosted separately on the same computer system 251 (i.e., not nested within the virtual worker node machine 310) and / or on another computer system 252. In contrast to prior art systems that create the pod within the virtual worker node machine itself, the shim 320_1, according to one or more embodiments of the invention, has computer-executable instructions that cause the service 432 of the virtual machine to retrieve virtual resources (including CPU, main memory, I / O, etc.) to create the virtual pod machine 301 outside of the virtual worker node machine 310.

[0038] In block 510, the virtual worker node machine 310 is configured to use the shim 320_1 to initialize the virtual pod machine, create / call / set up an agent 420, create / call / set up an inner CRI 414 (e.g., the inner containerd CRI) in the virtual pod machine 301, and establish a network and tunnel between the virtual worker node machine 310 and the virtual pod machine 301. To establish the network, the shim 320_1 is configured to exchange data with the virtual machine's service 432 and / or instruct it to cause a network handler 434 to establish a logical network connection between the virtual worker node machine 310 and the virtual pod machine 301. This logical network connection is an overlay network that builds upon the underlay network.Using the overlay network, the virtual worker node machine 310 is configured to expose the virtual pod machine 301 with an Internet Protocol (IP) address. The logical network connection establishes a tunnel between the virtual worker node machine 310 and the virtual pod machine 301 to exchange data, as described herein. The virtual worker node machine 310 has a worker node identity, and the virtual pod machine 301 has a pod identity, both of which are used to establish the logical network connection and are represented in an mapping table 650 in [reference missing]. Fig. 6. The virtual network connection from the virtual Ethernet (e.g., eth0) in the virtual worker node machine 310 to the virtual Ethernet (e.g., eth0) in the virtual pod machine 301 places the virtual worker node machine 310 and the virtual pod machine 301 in the same network. The network handler 434 can work in conjunction with a hypervisor to provide the logical network connection. The network handler 434 runs on the host (e.g., computer system 251) and is responsible for creating the underlay network to connect the remote virtual pod machine and the virtual worker node machine. If the virtual pod machine and the virtual worker node machine run on two separate hosts, there can be two separate host operating systems and two network handlers working together in one network.

[0039] After the logical connection is established, Shim 320_1 creates Agent 420, and Agent 420 in virtual pod machine 301 is configured to exchange data with Shim 320_1 in virtual worker node machine 310. In one or more embodiments, Shim 320_1 can call Agent 420 to be created in virtual pod machine 301. In one or more embodiments, Shim 320_1 can create Agent 420 in sandbox 460 and forward Agent 420 to virtual pod machine 301. Agent 420 includes computer-executable instructions to operate as described herein. Once the logical connection is established, the Shim 320_1 creates the inner CRI 414, and the inner CRI 414 is configured to create containers in the virtual pod machine 301.Agent 420 is configured to assist in forwarding requests between Shim 320 and the inner CRI 414. In one or more embodiments, Shim 320_1 can invoke the inner CRI 414 to be created in the virtual pod machine 301 using Agent 420. In one or more embodiments, Shim 320_1 can create the CRI 414 in the sandbox 460 and forward the CRI 414 to the virtual pod machine 301 via Agent 420.

[0040] In block 512, shim 320_1 is configured to call / induce inner CRI 414 to create example containers 440 and 441. Specifically, shim 320_1 is configured to forward APIs and / or API objects for containers destined for shell pod 464, via agent 420, to virtual pod machine 301, and in particular to inner CRI 414, so that inner CRI 414 can create containers 440 and 441. Shim 320_1 is configured to send requests to agent 420, which then redirects the requests to inner CRI 414 within virtual pod machine 301. CRI 414 is instructed to call containerd to create containers 440 and 441.Containers 440 and 441 are each open / running to start / instantiate a separate software application on virtual pod machine 301, so that the software application runs on the host machine running virtual pod machine 301. Instead of containers 440 and 441 being created in shell pod 464 of sandbox 460, containers 440 and 441 are created within virtual pod machine 301. Furthermore, a suspended container 462 can be started in sandbox 460. The suspended container 462 is incomplete and / or a shell of a container.

[0041] Block 514 configures a customized cAdvisor 410 and / or the kubelet 312 (the customized cAdvisor 410 can reside within the kubelet 312) to call a resource discovery service 430 to report the virtual pod machine 301 for resource monitoring. Reporting the virtual pod machine 301 involves reporting the pod identity for the virtual pod machine 301 to the resource discovery service 430 and the API server 204. The resource discovery service 430 is then configured to manage resources for the virtual pod machine 301.

[0042] Fig. Figure 6 is a block diagram of an example network architecture in System 200, which serves to provision and use remote pods as virtual machines in Kubernetes according to one or more embodiments of the present invention. System 200 in Fig. Figure 6 omits some elements to avoid overburdening the figure, although it should be clear that System 200 includes the elements and their functions as described herein. Virtual Pod Machines 301 and 302 are shown for clarity, but the description applies to Virtual Pod Machine 303 and any additional Virtual Pod Machines.

[0043] Host network handler 434 is responsible for providing access to the underlay network to set up the overlay network for virtual worker node machine 310 and virtual pod machines 301 and 302. The underlay network is the physical infrastructure on which the overlay network is built. It is the underlying network responsible for cross-network packet delivery. The overlay network can be a virtual local area network (VLAN) and / or any applicable network set up by CNI 316. As initialized by shim 320_1 during the creation of the virtual pod machines, each of virtual pod machines 301 and 302 has a unique pod namespace. For example, virtual pod machine 301 has the pod namespace 601, whereas virtual pod machine 302 has the pod namespace 602.Similarly, Shim 320_1 is configured to create a proxynet namespace 611 and a proxynet namespace 612 in the virtual worker node machine 310. Each pod namespace 601 and 602 is an object in the virtual pod machine 301 and 302, respectively, and each proxynet namespace 611 and 612 is an object in the virtual worker node machine 310. Using the pod identity for virtual pod machine 301 stored in mapping table 650, Shim 320_1 assigns proxynet namespace 611 as a proxy or proxynet for virtual pod machine 301. Using the pod identity stored in mapping table 650 for virtual pod machine 302, the shim 320_1 assigns proxy network namespace 612 as the proxy or proxy network for virtual pod machine 302. This mapping is stored in mapping table 650.

[0044] Each virtual pod machine 301, 302, has a virtual Ethernet connection into and out of the pod namespace containing the containers. For example, virtual pod machine 301 has a virtual Ethernet connection (VETH1) in pod namespace 601, which is connected to another virtual Ethernet connection (VETH0) located outside pod namespace 601 within virtual pod machine 301, with the virtual Ethernet connections (VETH1 and VETH0) forming a pair. Similarly, virtual pod machine 302 has a virtual Ethernet connection (VETH1) in pod namespace 602, which is connected to another virtual Ethernet connection (VETH0) located outside pod namespace 602 within virtual pod machine 302, with the virtual Ethernet connections (VETH1 and VETH0) forming a pair on virtual pod machine 302.In virtual worker node machine 310, proxy network namespace 611 has one virtual Ethernet connection (VETH1) within proxy network namespace 611, which is connected to another virtual Ethernet connection (VETH0) located outside proxy network namespace 611, with the virtual Ethernet connections (VETH1 and VETH0) forming a pair. In virtual worker node machine 310, proxy network namespace 612 has one virtual Ethernet connection (VETH3) within proxy network namespace 612, which is connected to another virtual Ethernet connection (VETH2) located outside proxy network namespace 612, with the virtual Ethernet connections (VETH3 and VETH2) forming another pair. The proxy network namespaces 611 and 612 are each connected to the bridge (which has its own IP address) via their respective virtual Ethernet connections.

[0045] The CNI 316 and / or the Shim 320_1 are configured to create a tunnel (e.g., tunnel 0) such as a virtual private network between the proxy network namespace 611 in the virtual worker node machine 310 and the pod namespace 601 in the virtual pod machine 301, so that traffic (e.g., data) is mirrored / copied and transferred back and forth between the virtual worker node machine 310 and the pod namespace 601. Similarly, the CNI 316 and / or the Shim 320_2 are configured to create another tunnel (e.g., Tunnel 1), such as a virtual private network, between the proxy network namespace 612 in the virtual worker node machine 310 and the pod namespace 602 in the virtual pod machine 301, so that traffic (e.g., data) is mirrored / copied and transferred back and forth between the virtual worker node machine 310 and the pod namespace 602.In other words, the tunnels and virtual Ethernet connections mirror traffic in both directions. The CNI 316 and / or the Shim 320_1 are configured to assign unique IP addresses to each of the pod namespaces 601 and 602, respectively, in the virtual pod machines 301 and 302, all of which are stored in the mapping table 650.

[0046] As described herein, the virtual pod machines 301, 302, and 303 can be deployed to run on any host machine, each of which may be different from the host machine running the virtual worker node machine 310, and / or one or more virtual pod machines 301, 302, and 303 can reside on the same host machine as the virtual worker node machine 310, while other virtual pod machines reside on different host machines. From the worker node's perspective, it is unaware that the actual footprints of the containers reside on virtual machines other than the virtual worker node machine 310. That is, no CNI code resides on the virtual pod machines.Furthermore, the virtual worker node machine 310 is connected via an interface to the shim 320_1, 320_2, 320_3, which has created proxynet namespaces; therefore, the virtual worker node machine 310 sends and receives data from pod namespaces using the proxynet namespaces, as if the virtual pod machines 301, 302, 303 were on the same host machine.

[0047] Fig. Figure 7 is a flowchart of a computer-executed method 700 for instantiating / starting and using remote virtual pod machines located away from their virtual worker node machine according to one or more embodiments of the present invention. The computer-executed method 700 in Fig. 7 can be executed using System 200. If necessary, the Fig. Reference is made to points 1 to 6.

[0048] In block 702 of the computer-executed procedure 700, the virtual worker node machine 310 is configured to instantiate / start / call intermediate software (e.g., the Shim 320) within a virtual worker node machine 310. For example, the CRI 316 (such as containerd) can instantiate / start / call the Shim 320 within the virtual worker node machine 310.

[0049] At block 704, virtual worker node machine 310 is configured to use the intermediate software (e.g., shim 320_1) to create a virtual pod machine (e.g., virtual pod machine 301), which is separate from virtual worker node machine 310. For example, virtual pod machine 301 is not nested within or contained in virtual worker node machine 310. Virtual pod machine 301 can be hosted on the same host machine as virtual worker node machine 310; for example, both can be hosted on computer system 251. Alternatively, virtual pod machine 301 and virtual worker node machine 310 can be hosted on different host machines; for example, one can be hosted on computer system 251 and the other on computer system 252.

[0050] At block 706, the virtual worker node machine 310 is configured to cause an overlay network to be built between the intermediate software (e.g., the shim 320_1) in the virtual worker node machine 310 and a pod memory area (e.g., the pod namespace 601) in the virtual pod machine (e.g., the virtual pod machine 301).

[0051] At block 708, the virtual worker node machine 310 is configured to use the overlay network to cause containers (e.g., containers 440, 441) to be created in the virtual pod machine (e.g., virtual pod machine 301), and the virtual worker node machine 310 is configured to use the overlay network to manage transfers with the virtual pod machine (e.g., virtual pod machine 301).

[0052] The intermediate software (e.g., the Shim 320_1) is configured to create an isolated data processing environment on the virtual worker node machine 310. For example, the Shim 320_1 is configured to start / create the sandbox 460 as an isolated data processing environment on the virtual worker node machine 310.

[0053] The intermediate software (e.g., the Shim 320_1) is configured to create a proxy network storage area in an isolated data processing environment on the virtual worker node machine. For example, the Shim 320_1 is configured to start / create a proxy network namespace 611 in sandbox 460 as an isolated data processing environment on the virtual worker node machine 310.

[0054] The intermediate software (e.g., the Shim 320_1) is configured to establish a logical network between a proxy network storage area (e.g., proxy network namespace 611) on the virtual worker node machine 310 and the pod storage area (e.g., pod namespace 601) on the virtual pod machine (e.g., virtual pod machine 301). This logical network (via the overlay network) can be a tunnel, such as a virtual private network, a virtual local area network, a virtual Ethernet, etc., for data exchange between proxy network namespace 611 on the virtual worker node machine 310 and pod namespace 601 (which has an active software application created using container 440).

[0055] An Internet Protocol (IP) address is assigned to a proxy network storage area (e.g., proxy network namespace 611) of the virtual worker node machine 310, and the intermediate software is configured to reassign / move the IP address to the pod storage area (e.g., pod namespace 601). For example, Shim 320_1 is configured to extract the image for the container to be created, and Shim 320_1 is configured to create / start a container 462 in sandbox 460, where container 462 is subsequently stopped. Container 462 is stopped and is a shell container. As soon as Shim 320_1 informs CNI 316 that container 462 has been created / started on virtual worker node machine 310, CNI 316 (e.g.,Using Classless Inter-Domain Routing (CIDR), a TCP / IP address is assigned to the suspended container 462, and the shim 320_1 is configured to move / assign the TCP / IP address from the proxy network namespace 611 (which may be located in sandbox 460) in the virtual worker node machine 310 to the virtual pod machine 301, thereby setting up the network. Consequently, the TCP / IP address is assigned to the pod namespace 601.

[0056] In response to receiving a container destined for an isolated data processing environment on the virtual worker node machine, virtual worker node machine 310 is configured to transfer the container to the virtual pod machine to be allocated to the pod namespace. For example, shim 320_1 is configured to transfer container 440, 441 to pod namespace 601. The intermediate software (e.g., shim 320_1) is configured to cause a software application to be instantiated in container 440, 441 on the virtual pod machine (e.g., virtual pod machine 301). Consequently, the software application is configured to run on virtual pod machine 301, which is remote from virtual worker node machine 310.

[0057] It should be clarified from the outset that the implementation of the teachings set forth herein is not limited to a cloud computing environment, although this disclosure includes a detailed description of cloud computing. Rather, embodiments of the present invention can be implemented together with any other type of data processing environment, now known or hereafter invented.

[0058] Cloud computing is a service delivery model that enables seamless, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing power, main memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management overhead or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four implementation models.

[0059] The properties are as follows:

[0060] On-Demand Self-Service: A cloud user can unilaterally and automatically provide data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider.

[0061] Broad Network Access: Functions are available over a network, accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g. mobile phones, laptops and PDAs).

[0062] Resource pooling: The provider's data processing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources being dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control over or knowledge of the exact location of the provided resources, but may be able to define a location at a higher level of abstraction (e.g., country, state, or data center).

[0063] Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling (scale out), in some cases automatically, and released quickly for rapid scale-in. To the user, the available features often appear unlimited and can be purchased in any quantity at any time.

[0064] Measured Service: Cloud systems automatically control and optimize resource usage by employing a measurement function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, thereby creating transparency for both the provider and the user of the service.

[0065] The service models are as follows:

[0066] Software as a Service (SaaS): The functionality provided to the user consists of using the provider's applications running in a cloud infrastructure. These applications are accessible from various client devices via a thin-client interface, such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0067] Platform as a Service (PaaS): The function provided to the user is to deploy applications created or obtained by the user, using programming languages ​​and tools supported by the provider, within the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and potentially over configurations of the application hosting environment.

[0068] Infrastructure as a Service (IaaS): The functionality provided to the user consists of supplying processing, storage, networking, and other basic data processing resources, enabling the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and potentially limited control over selected network components (e.g., host firewalls).

[0069] The following are the deployment models:

[0070] Private Cloud: The cloud infrastructure is operated solely for one organization. It can be managed by the organization or a third party and can be located on the organization's own premises or on external premises.

[0071] Community Cloud: This cloud infrastructure is shared by multiple organizations and supports a specific user community with shared concerns (e.g., mission, security requirements, policies, and regulatory compliance considerations). It can be managed by the organizations themselves or a third party and can be located on-premises or externally.

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

[0073] Hybrid Cloud: The cloud infrastructure is a composition of two or more clouds (private, community or public) that remain separate entities but are connected by a standardized or proprietary technology that enables data and application portability (e.g. cloud audience distribution for load balancing between clouds).

[0074] A cloud computing environment is service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing lies an infrastructure comprising a network of interconnected nodes.

[0075] With reference to Fig. Figure 8 illustrates a cloud computing environment 50. As shown, the cloud computing environment 50 comprises one or more cloud computing nodes 10 with which local data processing units used by cloud users, such as an electronic assistant (PDA) or a mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automotive computer system 54N, can exchange data. The nodes 10 can exchange data with each other. They can be grouped physically or virtually into one or more networks, such as private, community, public, or hybrid clouds (not shown), as described above, or into a combination thereof. This enables the cloud computing environment 50 to offer infrastructure, platforms, and / or software as services, for which a cloud user does not need to maintain resources on a local data processing unit.It should be noted that the types of in . Fig. The data processing units 54A to N shown in Figure 8 are intended to be illustrative only, and the data processing nodes 10 and the cloud computing environment 50 can exchange data with any type of computer unit via any type of network and / or any type of network-accessible connection (e.g., using a web browser).

[0076] With reference to Fig. Figure 9 shows a set of functional abstraction layers used by the cloud computing environment 50 ( Fig. 8) be provided. It should be clear from the outset that the in Fig. The components, layers, and functions shown in Figure 9 are intended to be illustrative only, and embodiments of the invention are not limited to them. As shown, the following layers and corresponding functions are provided:

[0077] A hardware and software layer 60 comprises hardware and software components. Examples of hardware components include: mainframe computers 61; servers 62 based on the RISC (Reduced Instruction Set Computer) architecture; servers 63; blade servers 64; storage units 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

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

[0079] In one example, an administration layer 80 can provide the functions described below. A resource provisioning layer 81 provides the dynamic procurement of data processing resources and other resources used to perform tasks within the cloud computing environment. A metering and pricing layer 82 provides cost tracking when using resources within the cloud computing environment and billing for the consumption of these resources. In one example, these resources could include application software licenses. A security layer provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 83 provides users and system administrators with access to the cloud computing environment.Service scope management (84) provides the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment (85) provides the advance planning and procurement of cloud computing resources for which a future requirement is anticipated, in accordance with an SLA.

[0080] A workload layer 90 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation 91; software development and lifecycle management 92; delivery of training in virtual classrooms 93; data analytics processing 94; transaction processing 95; and software applications running in workloads and functions 96 (e.g., software applications in the virtual worker node machine 310, software applications in the virtual pod machines 301, 302, 303, etc.).

[0081] Various embodiments of the invention are described herein with reference to the accompanying drawings. Alternative embodiments of the invention may be devised without departing from the scope of this invention. Various connections and positional relationships (e.g., above, below, beside, etc.) between elements are specified in the following description and in the drawings. These connections and / or positional relationships may be direct or indirect unless otherwise specified, and the present invention is not intended to be limiting in this respect. Consequently, a coupling of entities may refer to either a direct or an indirect coupling, and a positional relationship between entities may be a direct or indirect positional relationship.Furthermore, the various tasks and process steps described herein can be incorporated into a more comprehensive procedure or process that includes additional steps or functionality not described in detail herein.

[0082] One or more of the methods described herein may be implemented using any or a combination of the following technologies, each of which is well known in the art: (a) discrete logic circuit(s) with logic gates to perform logic functions on data signals, an application-specific integrated circuit (ASIC) with appropriate combinational logic gates, (a) programmable gate array (PGA), a field-programmable gate array (FPGA), etc.

[0083] For the sake of brevity, conventional techniques relating to the manufacture and use of aspects of the invention may or may not be described in detail herein. In particular, various aspects of data processing systems and certain computer programs for implementing the various technical features described herein are well known. Consequently, for the sake of clarity, many conventional implementation details are only briefly mentioned herein or omitted entirely, without specifying the well-known details of the system and / or process.

[0084] In some embodiments, various functions or processes can take place at a specific location and / or in connection with the operation of one or more devices or systems. In some embodiments, part of a specific function or process can be performed at a first unit or location, and the remaining function or process can be performed at one or more additional units or locations.

[0085] The terminology used herein serves only to describe certain embodiments and is not to be understood as restrictive. In its usage herein, the singular forms "a," "an," and "the" are to include the plural forms unless the context clearly indicates otherwise. It is further noted that the terms "has" and / or "having" when used in this specification denote the presence of specified features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other / further features, integers, steps, operations, element components, and / or groups thereof.

[0086] The corresponding structures, materials, processes, and equivalents of all means or step-plus-function elements in the following claims shall comprise any structure, material, or process for performing the function in combination with other claimed elements, which are claimed individually. The present disclosure is for illustrative and descriptive purposes only and is neither exhaustive nor limited to the disclosed form. Many modifications and variants are apparent to the person skilled in the art without deviating from the scope of the disclosure.The embodiments were chosen and described in order to best explain the basic ideas of the disclosure and its practical application, and to enable other skilled persons to understand the disclosure with regard to different embodiments with different modifications suitable for the respective intended use.

[0087] The diagrams presented herein are for illustrative purposes only. Many changes can be made to the diagram or the steps (or operations) described therein without altering the scope of the disclosure. For example, the actions can be performed in a different order, or actions can be added, deleted, or modified. Furthermore, the term "coupled" describes the existence of a signal path between two elements and does not imply a direct connection between the elements without intervening elements / connections. All these variations are considered part of the present disclosure.

[0088] The following definitions and abbreviations are to be used for the interpretation of the claims and the specification. In their use herein, the terms "includes," "comprising," "comprising," "has," "possessing," "incorporating," or "containing," or any other variant thereof, are to be understood as covering non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent in such composition, mixture, process, method, article, or apparatus.

[0089] Additionally, the term "exemplary" is used herein to mean "serving as an example, case, or illustration." Any design or form described herein as "exemplary" is not necessarily to be construed as preferable or advantageous over other designs or forms. The terms "at least one" and "one or more" are to include any whole number greater than or equal to one, i.e., one, two, three, four, etc. The terms "a plurality" are to include any whole number greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" can include both an indirect "connection" and a direct "connection."

[0090] The terms "approximately", "largely", "about" and variations thereof are intended to encompass the degree of error associated with measuring the respective quantity based on the equipment available at the time the application was filed. For example, "about" may encompass a range of ± 8%, 5%, or 2% of a given value.

[0091] The present invention may be a system, a method, and / or a computer program product at any possible level of integration of technical details. The computer program product may comprise a computer-readable storage medium (or media) containing computer-readable program instructions to induce a processor to execute aspects of the present invention.

[0092] A computer-readable storage medium can be a physical unit capable of retaining and storing instructions for use by a system to execute instructions. For example, a computer-readable storage medium can be an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof, without limitation. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a removable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM).Flash memory), static random-access memory (SRAM), removable compact storage disk-read-only memory (CD-ROM), a DVD (digital versatile disc), a memory stick, a floppy disk, a mechanically coded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium shall not, in its use herein, be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses traveling through an optical fiber cable), or electrical signals transmitted by a wire.

[0093] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to individual data processing units or, via a network such as the internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routing computers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards them for storage on a computer-readable storage medium within the respective data processing unit.

[0094] Computer-readable program instructions for executing work steps of the present invention may be assembler instructions, ISA (Instruction Set Architecture) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., as well as procedural programming languages ​​such as the programming language "C" or similar programming languages.The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer can 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 can be made to an external computer (for example, 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 using state information from the computer-readable program instructions to personalize the electronic circuits to implement aspects of the present invention.

[0095] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams or charts of methods, devices (systems), and computer program products according to embodiments of the invention. It is pointed out that each block of the flowcharts and / or block diagrams or charts, as well as combinations of blocks in the flowcharts and / or block diagrams or charts, can be executed by means of computer-readable program instructions.

[0096] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a specialized computer, or another programmable data processing device to create a machine, such that the instructions executed via the processor of the computer or other programmable data processing device generate a means of implementing the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device, and / or other units to function in a particular manner, such that the computer-readable storage medium on which instructions are stored has a manufactured product, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams or charts.

[0097] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other unit to cause the execution of a series of process steps on the computer, other programmable device, or other unit in order to create a process implemented on a computer, such that the instructions executed on the computer, other programmable device, or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.

[0098] The flowcharts and block diagrams or charts in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this context, each block in the flowchart or block diagrams or charts can represent a module, segment, or part of instructions that includes one or more executable instructions for performing the specified logical function(s). In some alternative embodiments, the functions specified in the blocks may occur in a different order than shown in the figures. For example, two blocks shown consecutively may in reality be executed largely simultaneously, or the blocks may sometimes be executed in reverse order depending on the corresponding functionality.It should also be noted that each block of the block diagrams or charts and / or flowcharts, as well as combinations of blocks in the block diagrams or charts and / or flowcharts, can be implemented by special hardware-based systems that perform the specified functions or steps, or execute combinations of special hardware and computer instructions.

[0099] The descriptions of the various embodiments of the present invention are provided for illustrative purposes only; they are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variants are recognizable to those skilled in the art without deviating from the scope of the described embodiments. The terminology used herein has been chosen to best explain the basic concepts of the embodiments, their practical application, or technical improvements compared to technologies already on the market, and to enable other skilled individuals to understand the embodiments described herein.

Claims

[1] A computer-executed procedure comprising: Instantiating intermediate software (320) in a virtual worker node machine (310); Using the intermediate software (320) to cause a virtual pod machine (301, 302, 303) to be created, wherein the virtual pod machine (301, 302, 303) is not nested within the virtual worker node machine (310); To cause the worker node machine to establish an overlay network between the intermediate software (320) in the virtual worker node machine (310) and a pod memory area in the virtual pod machine (301, 302, 303); and Assigning an Internet Protocol (IP) address to a proxy network storage area of ​​the virtual worker node machine (310); Reassign, through the intermediate software (320), the IP address to the pod storage area; Using the overlay network to cause containers (440, 441, 462) to be created in the virtual pod machine (301, 302, 303), with the virtual worker node machine (310) configured to communicate with the virtual pod machine (301, 302, 303) using the overlay network. [2] A computer-executed method according to claim 1, wherein the intermediate software (320) is configured to create an isolated data processing environment (460) on the virtual worker node machine (310). [3] A computer-executed method according to claim 1, wherein the intermediate software (320) is configured to create a proxy network storage area in an isolated data processing environment on the virtual worker node machine (310). [4] A computer-executed method according to claim 1, wherein the intermediate software (320) is configured to cause a logical network to be connected between a proxy network storage area on the virtual worker node machine (310) and the pod storage area on the virtual pod machine (301, 302, 303). [5] A computer-executed method according to claim 1, further comprising, in response to receiving a container (440, 441, 462) intended for an isolated data processing environment (460) on the virtual worker node machine (310), transferring the container (440, 441, 462) to the virtual pod machine (301, 302, 303) to be allocated to the pod storage area. [6] A computer-executed method according to claim 5, wherein the intermediate software (320) is configured to cause a software application to be instantiated in the container (440, 441, 462) on the virtual pod machine (301, 302, 303). [7] System that exhibits: a main memory containing instructions readable by a computer; and one or more processors to execute computer-readable instructions, wherein the computer-readable instructions control the one or more processors to perform operations that include: Instantiating intermediate software (320) in a virtual worker node machine (310); Using the intermediate software (320) to cause a virtual pod machine (301, 302, 303) to be created, wherein the virtual pod machine (301, 302, 303) is not nested within the virtual worker node machine (310); To cause the worker node machine to establish an overlay network between the intermediate software (320) in the virtual worker node machine (310) and a pod memory area in the virtual pod machine (301, 302, 303); Assigning an Internet Protocol (IP) address to a proxy network storage area of ​​the virtual worker node machine (310); Reassign, through the intermediate software (320), the IP address to the pod storage area; and Using the overlay network to cause containers (440, 441, 462) to be created in the virtual pod machine (301, 302, 303), with the virtual worker node machine (310) configured to communicate with the virtual pod machine (301, 302, 303) using the overlay network. [8] System according to claim 7, wherein the intermediate software (320) is configured to create an isolated data processing environment (460) on the virtual worker node machine (310). [9] System according to claim 7, wherein the intermediate software (320) is configured to create a proxy network storage area in an isolated data processing environment on the virtual worker node machine (310). [10] System according to claim 7, wherein the intermediate software (320) is configured to cause a logical network to be connected between a proxy network storage area on the virtual worker node machine (310) and the pod storage area on the virtual pod machine (301, 302, 303). [11] System according to claim 7, wherein the operations further comprise, in response to receiving a container (440, 441, 462) intended for an isolated data processing environment (460) on the virtual worker node machine (310), transferring the container (440, 441, 462) to the virtual pod machine (301, 302, 303) to be allocated to the pod storage area. [12] System according to claim 11, wherein the intermediate software (320) is configured to cause a software application to be instantiated in the container (440, 441, 462) on the virtual pod machine (301, 302, 303). [13] Computer program product comprising a storage medium readable by a processing circuit, on which program instructions are stored which are executed by the processing circuit to carry out a method according to any one of claims 1 to 6.

Citation Information

Patent Citations

  • Multiple virtual network interface support for virtual execution elements

    US20200073692A1

  • Configuring service load balancers with specified backend virtual networks

    US20210058327A1

  • Unified resource management for containers and virtual machines

    US20210141655A1