CN111459611A - Mirror image pulling method and device for Kubernetes system - Google Patents
Mirror image pulling method and device for Kubernetes system Download PDFInfo
- Publication number
- CN111459611A CN111459611A CN202010231931.8A CN202010231931A CN111459611A CN 111459611 A CN111459611 A CN 111459611A CN 202010231931 A CN202010231931 A CN 202010231931A CN 111459611 A CN111459611 A CN 111459611A
- Authority
- CN
- China
- Prior art keywords
- node
- mirror image
- address
- target
- selection condition
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Abstract
The specification discloses a mirror image pulling method and device for a Kubernets system. The method comprises the following steps: receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address; according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system; and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a mirror image pull method and apparatus for a kubernets system.
Background
Kubernets, an open source system that can automatically deploy, extend, and manage "containerized applications," can provide a platform for automatically deploying, extending, and running application containers across a host cluster. In a cluster, there may be a plurality of nodes (Node, also called Worker or Minion), which may be physical machines or virtual machines deploying containers, and each Node may have an operating environment of a container. The basic scheduling unit in the cluster may be referred to as Pod. To implement a service, multiple pods may be required to be completed cooperatively, and different pods may run on the same or different nodes.
Due to the fact that different pods are respectively operated on different nodes, it is very important to indicate the nodes to pull the needed mirror image conveniently and accurately according to the needs. Therefore, a scheme is needed to be provided, which can conveniently and accurately indicate the node in the kubernets system to pull the mirror image required by the update Pod according to different requirements.
Disclosure of Invention
Embodiments of the present specification provide a mirror image pulling method and apparatus for a kubernets system, which can indicate a node in the kubernets system to pull a mirror image required for updating Pod conveniently and accurately according to different user requirements.
In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:
the embodiment of the specification adopts the following technical scheme:
in a first aspect, a mirror image pulling method for a kubernets system is provided, including:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
In a second aspect, a mirror image pull apparatus for a kubernets system is provided, including: a receiving unit, a searching unit, and an indicating unit, wherein,
the receiving unit is used for receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
the searching unit is used for searching a target node and a corresponding IP address from a Kubernetes system according to the node selection condition;
and the indicating unit is used for indicating the target node to pull the corresponding mirror image according to the mirror image address according to the IP address of the target node.
In a third aspect, an electronic device is provided, which is applied to an application server, and includes:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
In a fourth aspect, a computer-readable storage medium applied to an application server is provided, the computer-readable storage medium storing one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to perform the following operations:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
According to the technical scheme provided by the embodiment, the user can send the mirror image pulling request aiming at the selected condition of the specific node and the pulling address of the mirror image according to the requirement. After receiving the mirror image pulling request, the target node meeting the selected condition and the corresponding IP address can be searched from the system according to the node selected condition, so that the target node can be indicated according to the IP address to pull the mirror image according to the pulling address of the mirror image.
Therefore, when the mirror image is pulled, the target node corresponding to the requirement can be found according to the requirement of the user, and then the target node is indicated to pull the mirror image. Therefore, in the Kubernets system, according to different user requirements, a specific node can be conveniently and accurately indicated to pull the mirror image required by the update Pod, so that higher mirror image pulling efficiency can be provided.
In addition, the pulling condition of the mirror image can be known in time by returning the pulling progress and the pulling state of the mirror image.
Drawings
In order to more clearly illustrate the embodiments or prior art solutions in the present specification, the drawings needed to be used in the description of the embodiments or prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present specification, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without any creative effort.
Fig. 1 is a schematic flowchart of a mirror image pulling method for a kubernets system according to an embodiment of the present disclosure;
fig. 2 is a schematic diagram of a mirror image pull method for a kubernets system according to an embodiment of the present disclosure;
fig. 3 is a block diagram of a mirror image pull apparatus for the kubernets system according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of the present specification.
Detailed Description
In order to make the objects, technical solutions and advantages of the present disclosure more clear, the technical solutions of the present disclosure will be clearly and completely described below with reference to the specific embodiments and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort belong to the protection scope of the present specification.
Technical solutions provided by the embodiments in the present specification are described in detail below with reference to the accompanying drawings.
Example 1
The embodiment provides a mirror image pulling method for a kubernets system, which can conveniently and accurately indicate a specific node to pull a mirror image required by an update Pod according to different user requirements in the kubernets system, so that relatively high mirror image pulling efficiency can be achieved. It can be assumed that the execution subject of the method is a server, and a specific flow diagram is shown in fig. 1, including:
step 102: and receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address.
As already introduced above, kubernets may be an open source system that automatically deploys, extends, and manages "containerized applications", while Pod may be the basic scheduling unit of kubernets. In an actual application environment, different Pod can run on different nodes, and a Node (also referred to as a Worker or Minion, hereinafter referred to as a Node) may be a physical machine or a virtual machine. For example, in an actual kubernets application environment, there may be a controller Deployment, which may be used to create and manage a Pod, thereby performing a control function. During specific operation, the Pod can be created, activated, deactivated, deleted, etc. on different nodes according to the load conditions among the nodes.
In practical application, a plurality of different Pod are usually created and run cooperatively according to a service, and in order to meet an increasing service demand, the Pod needs to be updated periodically, for example, based on a new function or repairing a bug. In each update, the Node that needs to run the Pod pulls the mirror image for update, however, in practical application, there are many nodes, so in order to accurately find the Node corresponding to the Pod that needs to be updated, the Node selection condition can be determined according to the requirement.
Specifically, in an embodiment, different service tags may be configured for different nodes in advance, for example, a corresponding service tag is created for a certain service. For example, for a web service, a particular tag referring to the web service may be created for the Node. Then when the controller Deployment creates a Pod for the service, then a Node with a web service tag can be selected to create a Pod based on the service tag. Therefore, if the Pod of a certain service needs to be updated, the service label can be used as the basis for selecting a Node.
For example, taking a web service as an example, service tags indicating the web service may be preconfigured for 10 nodes, and when Pod update needs to be performed on a node corresponding to the service, the node selection condition may be set to include the service tag corresponding to the web service, so that the 10 nodes may be instructed to execute pull mirroring in subsequent steps.
In one embodiment, different nodes may have unique identifiers, for example, each Node may be configured with a unique number, a Node name, or the like in advance. Specifically, for example, unique identifiers such as 001, 002, 003 may be preconfigured for different nodes. Then when the Pod in a certain Node or certain nodes needs to be updated, the Node unique identifier can be used as the basis for selecting the Node.
As described above, the controller Deployment can control Pod, which is controlled by the Deployment to operate in different nodes, so that a Node can also be selected by the Deployment. In an embodiment, the condition selected by the node may also be controller information, for example, there may be one controller delivery for a certain service, and if all the pods of the service need to be updated, the condition may be used as a basis for pulling the mirror image to implement the update according to information of the delivery, such as an ID (Identity) for example.
In practical application, the Node selection condition may also be set to be fully selected, that is, all nodes are required to execute mirror image pull, so as to perform update operation on their respective Pod.
That is, the node selection condition may include a node service label, a node unique identifier, controller information for controlling Pod, or all of them.
In order to realize the mirror image pull, the mirror image pull request may further include a mirror image address, so that the mirror image file can be pulled or downloaded to the corresponding mirror image file according to the address.
According to different requirements, a user can create a mirror image pulling request according to the node selection condition and the mirror image address, and then the mirror image pulling request is sent to an execution main body so as to be received by the execution main body.
Step 104: and according to the node selection condition, searching the target node and the corresponding IP address from the Kubernets system.
As described in the foregoing step, if the mirror image pull request includes the node selection condition, in this step, the corresponding target node and the corresponding IP (Internet Protocol) address may be found from the kubernets system according to the node selection condition.
Specifically, when the Node selection condition is all nodes, all nodes can be found in the system by calling a specific function, and the IP address corresponding to each Node is respectively queried.
When the selected condition of the Node is the Node service label, the Node matched with the service label of the Node can be searched from the system by calling a specific function, so that the corresponding IP address can be inquired.
That is, the present step may include: and searching a target node matched with the service label of the node in advance and a corresponding IP address from the Kubernetes system according to the service label of the node and the service labels configured for different nodes in advance.
Specifically, the matching may be used to implement forward selection and reverse selection, for example, the selection condition may include selecting a target node matching the node traffic label, or selecting a target node not matching the node traffic label. Specifically, for example, if the selected condition is that the "web" service label is selected or not selected, all nodes with the "web" service label configured in advance can be found from the kubernets system, and then the nodes are determined as target nodes, or all nodes except the nodes are determined as target nodes.
When the Node selection condition is the Node unique identifier, the Node with the preconfigured unique identifier matched with the Node unique identifier can be searched from the system by calling a specific function, and the corresponding IP address is inquired.
That is, the present step may include: and searching a target node with the preset unique identifier matched with the unique identifier of the node and a corresponding IP address from the Kubernets system according to the unique identifier of the node and the unique identifiers preset for different nodes.
Specifically, the matching can also be used to implement forward selection and reverse selection similar to the above description, for example, the selection condition may include selecting a target node matching the node unique identifier or selecting a target node not matching the node unique identifier.
When the Node selection condition is the controller information, the corresponding controller Deployment can be searched by calling a specific function, the ID information of the Deployment is obtained, and the Pod information corresponding to the Deployment is obtained through the specific function, so that the corresponding Node and the IP address corresponding to the Node can be searched through the Pod according to the affiliated relationship.
That is, the present step may include: searching a target controller of which the pre-configured information is matched with the information of the controller from the Kubernets system according to the information of the controller and the information pre-configured for different controllers; searching target Pod information controlled by a target controller; and searching a target node for operating the target Pod and an IP address corresponding to the target node from the Kubernets system according to the target Pod information.
Specifically, the controller information may be ID information of the above-described Deployment, or may be other description information. Each Deployment in the system can be preconfigured with a unique ID to find the target controller from the kubernets system whose preconfigured ID matches the controller ID in the selected condition. Thereafter, all the controlled target Pod information, such as description information of the target Pod, IP address, etc., can be found through the ID of the Deployment. Then, the nodes running the target Pod can be found through the target Pod information, and determined as target nodes, and the IP addresses corresponding to the target nodes are obtained.
In practical application, the Deployment may also correspond to a replicase copy controller (RS for short), and manage the Pod by controlling the RS. At this time, the ID of the corresponding RS can be found through the ID of the depolyment, and further, the target Pod information controlled by the RS and the target node running the target Pod can be found.
That is, in this step, based on different selected conditions, the corresponding Node and the corresponding IP address can be found in different manners.
Step 106: and according to the determined IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address in the request.
In the foregoing step, the target node and the corresponding IP address corresponding to the selected condition are already determined, and in this step, the target node may be indicated according to the IP address, and the corresponding mirror image is pulled according to the mirror image address in the mirror image pull request.
Specifically, in an actual business scenario, a demansost service may be created in advance, so that a Node in the system owns the service. A Node with this service, when creating Pod and starting, may mount a container service on the Node, for example, the container service may be/var/run/socket. And the container service may be used to pull the corresponding image file according to a given image address.
In an actual business scenario, a rom program can be developed and can be deployed in each Node, and the functions of the rom program can be used for controlling the container service pull mirror image in the Node. In a service scenario, the process of pulling a mirror to a Node may also be referred to as mirror warming.
That is, in this step, the method may indicate a war program in the target Node according to the determined IP address of the target Node and the mirror image pull address, and indicate the container service in the Node by the war program to perform mirror image preheating.
In practical applications, there may be one or more image repositories for storing different image files. The mirror address in this embodiment may be a mirror address corresponding to a mirror, that is, the target node may preheat a certain mirror file according to the mirror address.
In practical application, the rom program can also obtain the situation of the container service when the mirror image is pulled in real time, for example, the situation may include a pulling progress, a pulling state, and the like, that is, when the mirror image is preheated, the container service may generate a downloading progress, and in the downloading process, the downloading state may also be generated according to the practical situation. The pull progress may be a progress ratio in the process of downloading the image file, and the pull state may include success, failure, interruption, and the like in the pull process. Accordingly, these conditions can be returned in response to the received mirror pull request, and finally fed back to the user sending the mirror pull request, for example, the feedback can be performed in a display manner.
Fig. 2 is a schematic diagram of the mirror image pull method for the kubernets system. In an actual service scenario, a Restful API and a logic processing module may be created outside the kubernets system, and in the kubernets system, an external kubernets API may be opened, the external kubernets API may interact with the logic processing module, and the internal kubernets API may interact with different nodes and function modules in the nodes. There may be multiple nodes Node inside, for example, there may be 3 nodes illustrated in fig. 2.
The Restful API serves as an application interface that may be provided to a user for receiving mirror pull requests, exposing pull conditions, and the like. And the logic processing module can be used for processing the request sent by the Restful API and interacting with the inside of the system through the Kubernetese API. The controller Deployment can manage the corresponding Pod.
A demamonset service may be created in the kubernets system, so that each Node may hang a container service (e.g.,/var/run/socket) on the Node when starting Pod, and in each running Node, a pre-developed war program may be deployed.
The Service function in the Kubernetes system is used to create the Service based on the NodePort Service mode, which can open the corresponding port on the Node, so that the outside of the system can access the inside of the Node by combining the IP address and the port.
The user can determine the node selection condition and the corresponding mirror image address according to different requirements, and send the mirror image pull request containing the node selection condition and the corresponding mirror image address through the restful API. After receiving the request sent by the user, the Restful API can be sent to the logic processing module, and after receiving the request, the logic processing module can call the kubernets API to find out the target node and the corresponding IP address according to the node selection condition.
For example, when the selected condition is all, the kubernets API may be called to obtain the IP addresses corresponding to all nodes. When the selected condition is the service label, the Kubernetes API can be called to search the Node matched with the service label and the corresponding IP address of the pre-configured service label. When the selected condition is the unique Node identifier, the Kubernetes API can be called to search the Node matched with the pre-configured unique Node identifier and the corresponding IP address.
When the selected condition is controller delivery information (such as ID, unique identifier, or service label), kubernets API may be called, to search the delivery information matched with the pre-configured information and the delivery information, and obtain ID, and then kubernets API is called to obtain ID of RS corresponding to the ID of the delivery, and then find corresponding Pod through the ID of RS, so that nodes running these pods and corresponding IP addresses may be found through Pod information.
After the target Node and the corresponding IP address are obtained, the logic processing module may send an HTTP request including the mirror address to the IP port corresponding to the Node, and finally reach the corresponding rom program. Accordingly, the arm program can instruct the container service to perform mirror pull according to the mirror address by using the mirror address.
In the process of pulling the mirror image, the rom program can also obtain the progress and the state of the mirror image pulling and return the progress and the state to the logic processing module, so that the module can return to the Restful API to realize feedback to a user.
According to the technical scheme provided by the embodiment, the user can send the mirror image pulling request aiming at the selected condition of the specific node and the pulling address of the mirror image according to the requirement. After receiving the mirror image pulling request, the target node meeting the selected condition and the corresponding IP address can be searched from the system according to the node selected condition, so that the target node can be indicated according to the IP address to pull the mirror image according to the pulling address of the mirror image.
Therefore, when the mirror image is pulled, the target node corresponding to the requirement can be found according to the requirement of the user, and then the target node is indicated to pull the mirror image. Therefore, in the Kubernets system, according to different user requirements, a specific node can be conveniently and accurately indicated to pull the mirror image required by the update Pod, so that higher mirror image pulling efficiency can be provided.
In addition, the pulling condition of the mirror image can be known in time by returning the pulling progress and the pulling state of the mirror image.
Example 2
Based on the same concept, embodiment 2 of the present specification provides a mirror image pulling apparatus for a kubernets system, which can relatively conveniently and accurately instruct a specific node to pull a mirror image required for updating Pod according to different user requirements in the kubernets system, so that relatively high mirror image pulling efficiency can be achieved. The device can be applied to a server, and the schematic structural diagram of the device is shown in fig. 3, and the device comprises: a receiving unit 202, a look-up unit 204, and an indication unit 206, wherein,
a receiving unit 202, configured to receive a mirror image pull request sent by a user, where the mirror image pull request includes a node selection condition and a mirror image address;
the searching unit 204 may be configured to search the target node and the corresponding IP address from the kubernets system according to the node selection condition;
the instructing unit 206 may be configured to instruct the target node to pull the corresponding mirror according to the mirror address according to the IP address of the target node.
In one embodiment, the node selection condition includes a node traffic label, then
The lookup unit 204 may be configured to:
and searching a target node matched with the service label of the node in the selected condition and a corresponding IP address from the Kubernetes system according to the service label of the node and the service labels configured for different nodes in advance.
In one embodiment, the node selection condition includes a node unique identifier, then
The lookup unit 204 may be configured to:
and searching a target node with the preset unique identifier matched with the unique identifier of the node in the selected condition and a corresponding IP address from the Kubernets system according to the unique identifier of the node and the unique identifiers preset for different nodes.
In one embodiment, the node selection condition includes controller information, then:
a lookup unit operable to:
searching a target controller of which the pre-configured information is matched with the controller information in the selected condition from the Kubernets system according to the controller information and the information pre-configured for different controllers;
searching target Pod information controlled by a target controller;
and searching a target node for operating the target Pod and an IP address corresponding to the target node from the Kubernets system according to the target Pod information.
In an embodiment, the apparatus further comprises a return unit operable to:
and responding to the mirror image pulling request, and acquiring and returning the pulling progress and/or the pulling state of the target node to the mirror image.
As can be seen from the system provided by the above embodiment, a user can send a mirror pull request for a selected condition of a specific node and a pull address of a mirror as needed. After receiving the mirror image pulling request, the target node meeting the selected condition and the corresponding IP address can be searched from the system according to the node selected condition, so that the target node can be indicated according to the IP address to pull the mirror image according to the pulling address of the mirror image.
Therefore, when the mirror image is pulled, the target node corresponding to the requirement can be found according to the requirement of the user, and then the target node is indicated to pull the mirror image. Therefore, in the Kubernets system, according to different user requirements, a specific node can be conveniently and accurately indicated to pull the mirror image required by the update Pod, so that higher mirror image pulling efficiency can be provided.
In addition, the pulling condition of the mirror image can be known in time by returning the pulling progress and the pulling state of the mirror image.
Fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of this specification. On the hardware level, the electronic device comprises a processor, and optionally an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (peripheral component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, FIG. 4 is shown with only a single double-headed arrow, but does not indicate only a single bus or a single type of bus.
And the memory is used for storing programs. In particular, the program may include program code comprising computer operating instructions. The memory may include both memory and non-volatile storage and provides instructions and data to the processor.
The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form a mirror image pulling device aiming at the Kubernetes system on a logic level. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
The method performed by the mirror image pull apparatus according to the embodiment of fig. 3 in this specification may be applied to a processor, or may be implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The steps of a method disclosed in connection with the embodiments of the present specification may be embodied directly in a hardware decoding processor, or in a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.
The electronic device may further perform the functions of the mirror image pull apparatus for the kubernets system provided in the embodiment shown in fig. 3 in the embodiment shown in fig. 4, which are not described herein again in this specification.
Embodiments of the present specification also propose a computer-readable storage medium storing one or more programs, where the one or more programs include instructions, which, when executed by an electronic device including a plurality of application programs, enable the electronic device to perform the method performed by the image pulling apparatus for the kubernets system in the embodiment shown in fig. 3, and are specifically configured to perform:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.
As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, apparatus, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of claims of this document.
Claims (10)
1. A mirror image pulling method aiming at a Kubernetes system is characterized by comprising the following steps:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
2. The method of claim 1, wherein the node selection condition comprises a node traffic label, then
According to the node selection condition, the target node and the corresponding IP address are searched from the Kubernets system, and the method comprises the following steps:
searching the service label which is configured in advance from the Kubernetes system to be matched with the node service label according to the node service label and the service labels which are configured for different nodes in advanceIs/are as followsA destination node, and a corresponding IP address.
3. The method of claim 1, wherein the node selection condition comprises a node unique identification, then
According to the node selection condition, the target node and the corresponding IP address are searched from the Kubernets system, and the method comprises the following steps:
and searching a target node with the preset unique identifier matched with the unique identifier of the node and a corresponding IP address from the Kubernets system according to the unique identifier of the node and the unique identifiers preset for different nodes.
4. The method of claim 1, wherein the node selection condition comprises controller information, then
According to the node selection condition, the target node and the corresponding IP address are searched from the Kubernets system, and the method comprises the following steps:
searching a target controller of which the pre-configured information is matched with the controller information from a Kubernets system according to the controller information and information pre-configured for different controllers;
searching target Pod information controlled by the target controller;
and searching a target node for operating the target Pod and an IP address corresponding to the target node from a Kubernets system according to the target Pod information.
5. The method of claim 1, wherein the method further comprises:
and responding to the mirror image pulling request, and acquiring and returning the pulling progress and/or the pulling state of the target node to the mirror image.
6. An image pull apparatus for a kubernets system, comprising: a receiving unit, a searching unit, and an indicating unit, wherein,
the receiving unit is used for receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
the searching unit is used for searching a target node and a corresponding IP address from a Kubernetes system according to the node selection condition;
and the indicating unit is used for indicating the target node to pull the corresponding mirror image according to the mirror image address according to the IP address of the target node.
7. The apparatus of claim 6, wherein the node selection condition comprises controller information, then:
the search unit is configured to:
searching a target controller of which the pre-configured information is matched with the controller information from a Kubernets system according to the controller information and information pre-configured for different controllers;
searching target Pod information controlled by the target controller;
and searching a target node for operating the target Pod and an IP address corresponding to the target node from a Kubernets system according to the target Pod information.
8. The apparatus of claim 6, further comprising a return unit to:
and responding to the mirror image pulling request, and acquiring and returning the pulling progress and/or the pulling state of the target node to the mirror image.
9. An electronic device, the electronic device is applied to an application server and comprises:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
10. A computer-readable storage medium applied to an application server, the computer-readable storage medium storing one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to perform operations of:
receiving a mirror image pulling request sent by a user, wherein the mirror image pulling request comprises a node selection condition and a mirror image address;
according to the node selection condition, searching a target node and a corresponding IP address from a Kubernetes system;
and according to the IP address of the target node, indicating the target node to pull the corresponding mirror image according to the mirror image address.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010231931.8A CN111459611A (en) | 2020-03-27 | 2020-03-27 | Mirror image pulling method and device for Kubernetes system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010231931.8A CN111459611A (en) | 2020-03-27 | 2020-03-27 | Mirror image pulling method and device for Kubernetes system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111459611A true CN111459611A (en) | 2020-07-28 |
Family
ID=71683318
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010231931.8A Pending CN111459611A (en) | 2020-03-27 | 2020-03-27 | Mirror image pulling method and device for Kubernetes system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111459611A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112506617A (en) * | 2020-12-16 | 2021-03-16 | 新浪网技术(中国)有限公司 | Mirror image updating method and device for sidecar container in Kubernetes cluster |
| CN113535324A (en) * | 2021-06-25 | 2021-10-22 | 杭州朗澈科技有限公司 | Method and system for pulling mirror image at edge side |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106227579A (en) * | 2016-07-12 | 2016-12-14 | 深圳市中润四方信息技术有限公司 | A kind of Docker container construction method and Docker manage control station |
| US20170124114A1 (en) * | 2015-10-28 | 2017-05-04 | Beijing Baidu Netcom Science And Technology, Ltd. | Method and Device for Pulling Virtual Machine Mirror File |
| CN108628664A (en) * | 2018-05-11 | 2018-10-09 | 北京辰森世纪科技股份有限公司 | A kind of method and device of container processing |
| CN109005232A (en) * | 2018-08-10 | 2018-12-14 | 腾讯科技（深圳）有限公司 | Method for down loading, providing method and the equipment of container image file |
| CN110134455A (en) * | 2019-04-12 | 2019-08-16 | 平安医疗健康管理股份有限公司 | A kind of application management system and method |
-
2020
- 2020-03-27 CN CN202010231931.8A patent/CN111459611A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170124114A1 (en) * | 2015-10-28 | 2017-05-04 | Beijing Baidu Netcom Science And Technology, Ltd. | Method and Device for Pulling Virtual Machine Mirror File |
| CN106227579A (en) * | 2016-07-12 | 2016-12-14 | 深圳市中润四方信息技术有限公司 | A kind of Docker container construction method and Docker manage control station |
| CN108628664A (en) * | 2018-05-11 | 2018-10-09 | 北京辰森世纪科技股份有限公司 | A kind of method and device of container processing |
| CN109005232A (en) * | 2018-08-10 | 2018-12-14 | 腾讯科技（深圳）有限公司 | Method for down loading, providing method and the equipment of container image file |
| CN110134455A (en) * | 2019-04-12 | 2019-08-16 | 平安医疗健康管理股份有限公司 | A kind of application management system and method |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112506617A (en) * | 2020-12-16 | 2021-03-16 | 新浪网技术(中国)有限公司 | Mirror image updating method and device for sidecar container in Kubernetes cluster |
| CN112506617B (en) * | 2020-12-16 | 2023-10-24 | 新浪技术（中国）有限公司 | Mirror image updating method and device for side car containers in Kubernetes cluster |
| CN113535324A (en) * | 2021-06-25 | 2021-10-22 | 杭州朗澈科技有限公司 | Method and system for pulling mirror image at edge side |
| CN113535324B (en) * | 2021-06-25 | 2024-04-05 | 深圳软通动力信息技术有限公司 | Method and system for edge side pull mirroring |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112506617B (en) | Mirror image updating method and device for side car containers in Kubernetes cluster | |
| CN108027724B (en) | Method and device for upgrading in service of kernel loadable module | |
| US9465625B2 (en) | Provisioning of operating environments on a server in a networked environment | |
| US10216514B2 (en) | Identification of a component for upgrade | |
| CN105159704B (en) | A kind of method and device of batch deployment operation system | |
| CN110463162B (en) | Application deployment method, device and system | |
| WO2018072503A1 (en) | Method for initiating software modification, method and device for publishing metadata | |
| CN110727653B (en) | Multi-project load balancing method and device | |
| WO2017041486A1 (en) | Cluster deployment implementation method and apparatus | |
| CN103677807A (en) | Customizing program logic for booting a system | |
| CN107193609B (en) | Function module calling method and device in application and electronic equipment | |
| CN101393524A (en) | Firmware update method and system using the same | |
| CN111459611A (en) | Mirror image pulling method and device for Kubernetes system | |
| JP6763429B2 (en) | Control device, container startup method and program | |
| US20240111549A1 (en) | Method and apparatus for constructing android running environment | |
| CN111324361A (en) | Application upgrading method and device | |
| CN113127150A (en) | Rapid deployment method and device of cloud native system, electronic equipment and storage medium | |
| US9146749B1 (en) | System and methods for updating digital signage device operating systems and registering signage devices to a global network | |
| US11119754B1 (en) | Upgrading system components with forward and backward compatibility | |
| WO2016078326A1 (en) | Method, apparatus and system for displaying names of virtual machine | |
| US11900089B2 (en) | Automatically configuring and deploying a software operator in a distributed computing environment from a package | |
| CN114546588A (en) | Task deployment method and device, storage medium and electronic device | |
| CN110083366B (en) | Application running environment generation method and device, computing equipment and storage medium | |
| CN113821226A (en) | ONIE system installation method, apparatus, device and medium | |
| CN109739518B (en) | Method and device for generating offline software resources |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20230316 Address after: Room 501-502, 5/F, Sina Headquarters Scientific Research Building, Block N-1 and N-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193 Applicant after: Sina Technology (China) Co.,Ltd. Address before: 100193 7th floor, scientific research building, Sina headquarters, plot n-1, n-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193 Applicant before: Sina.com Technology (China) Co.,Ltd. |