CN116360834A - Kubernetes cluster in-situ upgrading method and system based on OSTree - Google Patents
Kubernetes cluster in-situ upgrading method and system based on OSTree Download PDFInfo
- Publication number
- CN116360834A CN116360834A CN202310347744.XA CN202310347744A CN116360834A CN 116360834 A CN116360834 A CN 116360834A CN 202310347744 A CN202310347744 A CN 202310347744A CN 116360834 A CN116360834 A CN 116360834A
- Authority
- CN
- China
- Prior art keywords
- upgrade
- upgrading
- node
- controller
- kubernetes
- 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
- 238000000034 method Methods 0.000 title claims abstract description 59
- 238000011065 in-situ storage Methods 0.000 title claims abstract description 28
- 239000000306 component Substances 0.000 claims abstract description 60
- 239000008358 core component Substances 0.000 claims abstract description 9
- 238000003860 storage Methods 0.000 claims description 18
- 230000002159 abnormal effect Effects 0.000 claims 1
- 230000008569 process Effects 0.000 description 21
- 238000010586 diagram Methods 0.000 description 13
- 238000012545 processing Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 238000012423 maintenance Methods 0.000 description 7
- 239000008186 active pharmaceutical agent Substances 0.000 description 5
- 238000004590 computer program Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 238000000889 atomisation Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 239000002184 metal Substances 0.000 description 2
- 229910052751 metal Inorganic materials 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000001902 propagating effect Effects 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 238000005096 rolling process Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 229910052802 copper Inorganic materials 0.000 description 1
- 239000010949 copper Substances 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- 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
- G06F8/656—Updates while running
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- 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
- 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/4557—Distribution of virtual machine instances; Migration and load balancing
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The invention provides an in-situ upgrading method and system of a Kubernetes cluster based on an OSTree, wherein the upgrading method comprises the following steps: upgrading an upgrade controller running in the Kubernetes cluster, wherein the upgrade controller is deployed in a form of Deployment; after the upgrade controller upgrades to the new version, the upgrade controller of the new version upgrades the CNI component; upgrading a core-related component of Kubernetes, wherein the core-related component at least comprises a core component on a Master node; in the event that the core related component upgrade is complete, the OSTree is introduced to upgrade the kubelet and operating system of each node, the kubelet being part of the operating system package.
Description
Technical Field
The application relates to the technical field of distributed systems, in particular to a Kubernetes cluster in-situ upgrading method and system based on an OSTree.
Background
Kubernetes (K8S) is a completely new distributed architecture solution based on container technology, and is an open source system for automatically deploying, expanding and contracting and managing containerized application programs, and is the most widely used cloud native support platform at present, all components of Kubernetes need to be continuously upgraded to repair software bug and security hole, as a Kubernetes is a distributed system comprising a plurality of components, and the upgrading process of Kubernetes needs to follow specific sequence and steps to avoid version incompatibility among the components. The problem of easy error and high time consumption is faced by the manual upgrading operation; in addition, most of Kubernetes clusters used for supporting an online cloud primary service system generally require that the upgrade process does not interfere with and interrupt upper-layer services, and generally have a limited upgrade time window, so that migration of node loads is required before each node is upgraded, and a rollback scheme after the upgrade encounters an abnormality is required; furthermore, in addition to the component upgrades of Kubernetes, the operating system of the node also needs to be upgraded from time to repair bugs and security holes of the operating system; finally, in view of no additional physical nodes for replacement upgrades in a bare metal deployment scenario, kubernetes requires in-situ upgrades of support nodes.
In the prior art, the Kubernetes can be upgraded in the following manner: (1) The manual upgrade is to control the upgrade sequence by the operation and maintenance personnel and execute the upgrade operation. The disadvantage is that it is time-consuming, labor-consuming and error-prone. The Kubernetes cluster upgrade process requires a per-component node upgrade, which is a relatively serialized process. Therefore, if the operation and maintenance personnel manually execute the operation and maintenance personnel, the operation and maintenance personnel need to take care of the whole process, and much time and effort are consumed. Furthermore, the entire process must be performed in a certain order, or the entire cluster may be unavailable due to version incompatibility among components, affecting and even interrupting upper layer traffic. (2) Semi-automatic upgrades refer to solutions that can support automated upgrades of some or all of the components of Kubernetes, but cannot compromise operating system upgrades. The upgrading technology solves the problems of time consumption and error easiness in manual upgrading to a certain extent, but the upgrading of the operating system still needs to be manually carried out by operation and maintenance personnel. While upgrading of the kernel or some of the dependent libraries requires restarting the node or restarting Kubernetes components on the node, manually upgrading the operating system can still be a cumbersome and time-consuming task. (3) The replacement type automatic upgrading refers to a scheme that the upgrading process needs to rely on additional nodes, and the nodes of a current old version are removed from a cluster after a target new version is deployed and added into the cluster, so that the nodes are upgraded one by one in a replacement type. Because the newly deployed node can use the new version of the operating system version, the technology solves the problem of synchronous upgrading of the operating system in the semiautomatic upgrading technology. However, this upgrade method needs to use an additional node, so that it is difficult to temporarily schedule additional physical server resources in a bare metal deployment scenario, and the difficulty of actual floor execution is faced.
Based on the defects of the upgrading of the Kubernetes in the prior art, there is a great need to propose an in-situ upgrading method of Kubernetes clusters, which is unattended, does not influence business and supports rollback at the same time.
Disclosure of Invention
In order to solve the problems that unattended automatic Kubernetes upgrading operation cannot be achieved in the prior art, load migration before upgrading is achieved so as not to interrupt upper-layer service, the capability of rollback at any time due to upgrading failure is achieved, and upgrading of a node operating system and in-situ upgrading of an extra node are not relied on, the application provides a Kubernetes cluster in-situ upgrading method and system based on an OSTree.
In a first aspect of the present application, a Kubernetes cluster in-situ upgrade method based on an OSTree is provided, the method comprising:
upgrading an upgrade controller running in the Kubernetes cluster, wherein the upgrade controller is deployed in a form of Deployment;
after the upgrade controller upgrades to the new version, the upgrade controller of the new version upgrades the CNI component;
upgrading a core-related component of Kubernetes, wherein the core-related component at least comprises a core component on a Master node;
in the event that the core related component upgrade is complete, the nodes that introduce the OSTree as the Kubernetes cluster upgrade each node's kubrelet, which is part of the operating system software package, and the operating system software package.
In one possible implementation manner of the first aspect, upgrading an upgrade controller running in a Kubernetes cluster includes:
the upgrade controller running currently creates a controller for managing resource update tasks;
and according to a kubectl apply command corresponding to the execution resource update of the Deployment resource corresponding to the new version, updating the Deployment resource corresponding to the new version into the current Kubernetes cluster.
In one possible implementation manner of the first aspect, the upgrading the CNI component by the new version of the upgrade controller includes:
the upgrade controller running currently creates a controller for managing the CNI update task;
and according to the YAML corresponding to the new version CNI component corresponding to the new version, executing the kubectl apply command corresponding to the CNI update, and updating the YAML corresponding to the new version CNI component into the current Kubernetes cluster.
In one possible implementation manner of the first aspect, upgrading the core related components of Kubernetes includes:
sequentially upgrading the control plane nodes based on a kubuead command line tool;
under the condition that the last control plane node is upgraded, sequentially upgrading the load nodes;
the command of the command line is realized by a pre-established controller for updating the task of the management node scheduled to the node, and the command is locally run on the node to be updated.
In one possible implementation manner of the first aspect, upgrading the operating system includes:
after restarting the node to be upgraded, the upgrade controller creates a Pod running upgrade command which is scheduled to the node to be upgraded;
according to the upgrade command, upgrading the operating system at the local of each node to be upgraded;
in one possible implementation manner of the first aspect, before restarting the node to be upgraded, the method includes:
and the upgrade controller drains the load on the node to be upgraded and transfers the load to other preset nodes through the scheduling of the Kubernetes.
In one possible implementation manner of the first aspect, the version of the mirrored address is used to implement the exception rollback based on the mirrored address of the OSTree operating system.
A second aspect of the present application provides an OSTree-based Kubernetes cluster in-situ upgrade system, applied to an OSTree-based Kubernetes cluster in-situ upgrade method as described above, the system comprising:
the first upgrading unit is used for upgrading an upgrading controller running in the Kubernetes cluster, and the upgrading controller is deployed in a form of depoyment;
the second upgrading unit is used for upgrading the CNI component by the upgrading controller of the new version after the upgrading controller is upgraded to the new version;
the third upgrading unit is used for upgrading the core related components of the Kubernetes, and the core related components at least comprise core components on a Master node;
and the fourth upgrading unit is used for introducing the OSTree as a node of the Kubernetes cluster to upgrade kubrelet and an operating system software package of each node when the core-related components are upgraded, wherein the kubrelet is a part of the operating system software package.
A third aspect of the present application provides an electronic device, comprising:
a memory for storing a processing program;
the processor, when executing the processing program, realizes the Kubernetes cluster in-situ upgrading method based on the OSTree as any one of the above.
A fourth aspect of the present application is a readable storage medium having stored thereon a processing program which, when executed by a processor, implements an OSTree-based Kubernetes cluster in-place upgrade method as set forth in any of the preceding aspects.
The technical scheme provided by the invention has at least the following beneficial technical effects:
according to the method, an upgrade controller is operated in the Kubernetes, unattended automatic upgrade of the Kubernetes cluster is realized, dependence on an external controller is avoided, an automatic upgrade process realized by the upgrade controller adopts a mode of rolling and upgrading nodes one by one, and zero interruption of the load service of the Kubernetes cluster is realized by draining the load of the nodes, restarting the nodes and finally recovering the load scheduling of the nodes; the whole upgrading process follows the rolling upgrading of each node, does not need extra node resources, does not influence and does not interrupt the upper layer service; the whole upgrading process is realized in the in-situ node, so that dependence on extra node resources is avoided; the Kubernetes cluster in-situ upgrading technology based on the OSTree is unattended, does not affect business and supports rollback.
Furthermore, the OSTree is used as a Kubernetes node operating system to manage and upgrade the node operating system software package, so that the method has the characteristic of atomization upgrading, and simultaneously supports timely rollback of the system when the upgrading fails, so that the condition that the node cannot recover for a long time due to the upgrading failure is avoided.
Drawings
Other features, objects and advantages of the present invention will become more apparent upon reading of the detailed description of non-limiting embodiments, given with reference to the accompanying drawings in which:
FIG. 1 illustrates a flow diagram of an OSTree-based Kubernetes cluster in-place upgrade method, according to an embodiment of the present application;
fig. 2 illustrates a block diagram of an OSTree-based Kubernetes cluster in-place upgrade system, according to an embodiment of the present application.
Detailed Description
The present invention will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the present invention, but are not intended to limit the invention in any way. It should be noted that variations and modifications could be made by those skilled in the art without departing from the inventive concept. These are all within the scope of the present invention.
The term "comprising" and variations thereof as used herein means open ended, i.e., "including but not limited to. The term "or" means "and/or" unless specifically stated otherwise. The term "based on" means "based at least in part on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment. The term "another embodiment" means "at least one additional embodiment". The terms "first," "second," and the like, may refer to different or the same object. Other explicit and implicit definitions are also possible below.
OSTree is a system for version updating of the Linux-based operating system that can be considered "git for operating system binaries". Just like the random switching and rollback of the historical version of the code by the git, the OSTree can conveniently switch the historical version of the operating system, and the functions of atomization upgrading and rollback are realized. Unlike conventional Linux package management systems, the OSTree cannot directly install or upgrade a certain package, but controls the integrated upgrade of all packages of the entire operating system. By the method, the version and the content of an operating system operated by each node can be controlled more accurately, and errors possibly occurring in the operation and maintenance process are reduced as much as possible.
Currently available Linux release versions of OSTree are Fedora CoreOS, photon OS, etc. The technology of the patent is mainly applied to Fedora CoreOS at present, but is also applicable to Linux release of other OSTree.
In order to solve the problems that in the prior art, the upgrading of the Kubernetes cluster needs to depend on an external controller, the service needs to suspend the upper-layer service in the upgrading process, the cluster cannot be rolled back accidentally or cannot be restored to a state before upgrading in the upgrading process, and the like, the application provides an in-situ upgrading method and system of the Kubernetes cluster based on an OSTree. According to the technical scheme, the upgrade controllers are deployed and operated in the cluster, the self-upgrade of the controllers is realized, unknown upgrade operation steps are dealt with, synchronous and automatic upgrade of the node operating system is realized by combining with the OSTree, and in-situ upgrade is avoided, so that dependence on additional node resources is avoided.
Specifically, as shown in fig. 1, a flow chart of an OSTree-based Kubernetes cluster in-situ upgrade method is shown according to an embodiment of the present application, and the method specifically may include:
step S1: upgrade controllers running in Kubernetes clusters are upgraded, and the upgrade controllers are deployed in the form of deployments. It can be understood that in the Kubernetes cluster upgrading process, the upgrading controller is firstly upgraded to a corresponding new version, the subsequent upgrading steps are controlled by the upgrading controller of the new version after upgrading, when each version is released, whether the subsequent version has some auxiliary operations or requirements on the upgrading process cannot be expected, the upgrading controller is preferred to be upgraded every time the Kubernetes cluster is upgraded, and the auxiliary operations or requirements can be realized in the upgrading controller of the new version, so that the requirements of the upgrading operation are met.
It can be understood that the upgrade of the upgrade agent will reconstruct the entire Pod, which will have a certain influence on the service, and the upgrade controller in this embodiment is used as a container level, and upgrades itself to the corresponding new version change range in a very controllable manner, and only the upgrade controller to be upgraded will be reconstructed, and the other containers including the network, the mounting disc, etc. will not be affected.
Step S2: after the upgrade controller upgrades to the new version, the new version upgrade controller upgrades the CNI component. It will be appreciated that after the upgrade controller completes the upgrade to the new version, the new version upgrade controller will update the resource objects of the upgrade CNI (container network interface ) component through the Kubernetes API.
In some embodiments of the present application, upgrading the CNI component takes precedence over the core related components of Kubernetes, so that situations in which the current CNI component cannot be compatible with the new version of Kubernetes can be avoided.
Step S3: the core related components of Kubernetes are upgraded, and the core related components at least comprise core components on a Master node. It can be understood that Kubernetes contains Master nodes and components on Node nodes, and the Master nodes are responsible for cluster scheduling, external interfaces, access control, life cycle maintenance of objects, and the like; the Node is responsible for maintaining the life cycle of the container, such as creating, deleting and stopping the Docker container, and is responsible for the service abstraction, load balancing and other works of the container. The Master Node is provided with three core components including an API Server for exposing kubernetes APIs, a process Scheduler for scheduling resources, an automation control center Controller Mananger for resource objects in the cluster, and a carrier Kube-Proxy for executing two core components including a Kubelet and Kuberbetes Service resources, wherein the Kubelet is a part of an operating system software package suite.
In some embodiments of the present application, core-related components may include kube-apiserver, kube-controller-manager, kube-schedule, and kube-proxy components, and upgrades to core-related components may be made based on local nodes.
Step S4: in the event that the core related component upgrade is complete, the nodes that introduce the OSTree as the Kubernetes cluster upgrade each node's kubrelet, which is part of the operating system software package, and the operating system software package. It can be understood that Kubernetes has completed upgrading except Kubelet, and has Kubelet and operating system of each Node which have not been upgraded, the Kubelet is responsible for the full life cycle management of Pod such as creation, modification, monitoring, deletion and the like on the Node of the present Node, and the Kubelet sends information of the computing Node (Node) to the API Server in real time; kubelet is released and installed in the form of a software package, and the upgrade kubelet is actually included in the upgrade of the operating system.
It is understood that various types of resource objects, such as Pod, label, service, replication Controller, etc., may be included in the Kubernetes cluster, and all of the resource objects may be added, deleted, changed, searched, etc., by the kubectl tool and stored persistently.
In some embodiments of the present application, since the os can use the OSTree, the new version of kubelet and all other software packages that need to be upgraded are contained in an OSTree upgrade package, and the upgrade of the os is performed simultaneously with the kubelet of each node.
It can be understood that Kubelet is responsible for maintaining a Pod (application instance) set, and in-place upgrade performs version upgrade on the node by replacing Kubelet components in-place, so that the Pod on the node is ensured not to be rebuilt due to cluster upgrade, and the continuity of service is ensured.
In some embodiments of the present application, the upgrade controller and the upgrade of the CNI thereof may create one or more Pod execution kubectl apply commands through Job (controller of management task) of kubecneties, and the kubectl apply commands may accept description files in JSON and YAML formats, and then submit related update requests to kubecneties for update.
In the step S1, upgrading the upgrade controller running in the Kubernetes cluster includes:
the upgrade controller running currently creates a controller for managing resource update tasks;
and according to a kubectl apply command corresponding to the execution resource update of the Deployment resource corresponding to the new version, updating the Deployment resource corresponding to the new version into the current Kubernetes cluster.
It will be appreciated that since the upgrade controller is a depoyment running in the Kubernetes cluster, it includes: management of the Deployment group of the depoyments, management of the Pod application instance, and the like, in the upgrading process of S1, a user can update the container mirror image of the depoyments of any Deployment group in the Kubernetes cluster according to the requirement, in order to upgrade the container mirror image to a new version, an upgrading controller of the current version executes a kubenetel application command for upgrading the upgrading controller by creating a controller for managing resource updating tasks, namely, a Kubernetes Job, and when the application mirror image version is required to be upgraded, the depoyment resource is updated to the Kubernetes cluster.
In an embodiment of the present application, the interface server is requested to delete the designated application instance and create the application instance by the Kubernetes API in the process of upgrading the upgrade controller to update the upgrade controller.
In the step S2, the upgrading of the CNI component by the new version upgrading controller includes:
the upgrade controller running currently creates a controller for managing the CNI update task;
and according to the YAML corresponding to the new version CNI component corresponding to the new version, executing the kubectl apply command corresponding to the CNI update, and updating the YAML corresponding to the new version CNI component into the current Kubernetes cluster.
It will be appreciated that after the upgrade controller completes the upgrade, the new version of the upgrade controller will upgrade the CNI component. The process is similar to the upgrading process of an upgrading controller, namely, the file name or the console of an input CNI updating resource is executed by creating a controller Kubernetes Job for managing CNI updating tasks, CNI updating resource configuration is carried out, a description file Deployment file in a YAML format corresponding to a new version CNI component is updated to Kubernete, and the alternate updating of new and old versions is realized depending on the update support of the Kubernetes on the development and DaemonSet.
In the step S3, the upgrading of the core related components of Kubernetes includes:
sequentially upgrading the control plane nodes based on a kubuead command line tool;
under the condition that the last control plane node is upgraded, sequentially upgrading the load nodes;
the command of the command line is realized by a pre-established controller for updating the task of the management node scheduled to the node, and the command is locally run on the node to be updated.
It will be appreciated that a Kubernetes cluster includes at least one set of working nodes that host the Pod running the containerized application and one control plane node that manages the working nodes and Pod in the cluster.
It will be appreciated that the core related components of the upgrade Kubernetes may utilize the official kubinedem command line tool to follow the sequence of the control plane node first and the load node later, execute kubeadm upgrade apply commands for the control plane node first upgraded, execute kubeadm upgrade node commands for other control plane nodes after the upgrade of the control plane node first upgraded is completed, and execute kubeadm upgrade node commands for all load nodes in turn to execute the upgrade of the load node after the upgrade of the control plane node is completed.
In the step S4, the upgrading the operating system includes:
after restarting the node to be upgraded, the upgrade controller creates a Pod running upgrade command which is scheduled to the node to be upgraded;
and according to the upgrade command, upgrading the operating system at the local of each node to be upgraded.
It will be appreciated that the commands of the kubceadm command line tool all need to be run locally, i.e. upgraded in place, on the node being upgraded, and that the upgrade commands are also implemented by creating a Kubernetes Job that is scheduled to this node.
It will be appreciated that the OSTree only supports the recording and deployment of complete (bootable) file system trees, and that the upgrade of the OSTree needs to be performed locally at each node, i.e. in-place, and needs to be effected by restarting the node, again in a manner that creates a Pod that is scheduled to that node to run the upgrade command.
In some embodiments of the present application, before restarting the node to be upgraded, the method includes: and the upgrade controller drains the load on the node to be upgraded and transfers the load to other preset nodes through the scheduling of the Kubernetes.
It can be understood that, in order to avoid affecting or even interrupting the upper layer service, before restarting the node to be upgraded, the upgrade controller will drain the loads on the (drain) node, migrate the loads to other nodes through the Kubernetes schedule, and after the node to be upgraded is drained, the upgrade controller will restart the node to be upgraded.
In some embodiments of the present application, the upgrade command of the operating system includes: the mirrored address of the OSTree-based operating system, the version of the mirrored address is used to implement the exception rollback. It can be understood that the update command of the OSTree is rpm-OSTree base-experimental OSTree-uncovered-region: < image >, wherein < image > is the address of the new version OSTree image, the address is not a fixed value, but is different according to the different image warehouse addresses and OSTree versions, when the exception occurs and the rollback is required, the image address is only replaced by the image address corresponding to the old version, and the rollback when the system is updated abnormally can be realized by using the same command.
In some embodiments of the present application, there is further provided an OSTree-based Kubernetes cluster in-situ upgrade system, which is applied to the in-situ upgrade method in the foregoing embodiments, where fig. 2 shows a schematic structural diagram of the OSTree-based Kubernetes cluster in-situ upgrade system, and the in-situ upgrade system includes:
a first upgrade unit 01, configured to upgrade an upgrade controller running in a Kubernetes cluster, where the upgrade controller is deployed in a form of a upgrade;
a second upgrade unit 02, configured to upgrade the CNI component by the new version upgrade controller after the upgrade controller upgrades to the new version;
a third upgrading unit 03, configured to upgrade core related components of Kubernetes, where the core related components at least include core components on a Master node;
a fourth upgrade unit 04, configured to introduce an OSTree as a node of the Kubernetes cluster to upgrade kubrelet and an operating system software package of each node, where kubrelet is a part of the operating system software package, when the upgrade of the core related components is completed.
It can be understood that each functional module in the Kubernetes cluster in-situ upgrading system based on the OSTree performs the same step flow as the Kubernetes cluster in-situ upgrading method based on the OSTree in the foregoing embodiment, and will not be described herein.
In some embodiments of the present application, an electronic device is also provided. The electronic equipment comprises a memory and a processor, wherein the memory is used for storing a processing program, and the processor executes the processing program according to the instruction. The Kubernetes cluster in-place upgrade method based on the OSTree in the foregoing embodiment is enabled when the processor executes the processing program.
The technical solutions presented in the present application relate to a method, an apparatus, a system, a chip, an electronic device, a computer-readable storage medium and/or a computer program product. The computer program product may include computer readable program instructions for performing various aspects of the present disclosure.
The computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: portable computer disks, hard disks, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static Random Access Memory (SRAM), portable compact disk read-only memory (CD-ROM), digital Versatile Disks (DVD), memory sticks, floppy disks, mechanical coding devices, punch cards or in-groove structures such as punch cards or grooves having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media, as used herein, are not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., optical pulses through fiber optic cables), or electrical signals transmitted through wires.
The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a respective computing/processing device or to an external computer or external storage device over a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network interface card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium in the respective computing/processing device.
Computer program instructions for performing the operations of the present disclosure can be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, c++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present disclosure are implemented by personalizing electronic circuitry, such as programmable logic circuitry, field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), with state information of computer readable program instructions, which can execute the computer readable program instructions.
Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.
These computer readable program instructions may be provided to a processing unit of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowcharts and block diagrams 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 disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The foregoing description of the embodiments of the present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the technical improvements in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
Claims (10)
1. An Kubernetes cluster in-situ upgrading method based on an OSTree is characterized by comprising the following steps of:
upgrading an upgrade controller running in a Kubernetes cluster, wherein the upgrade controller is deployed in a form of a upgrade;
after the upgrade controller upgrades to a new version, the new version upgrade controller upgrades the CNI component;
upgrading a core-related component of Kubernetes, wherein the core-related component at least comprises a core component on a Master node;
in the event that the core related component upgrade is complete, the nodes that introduce the OSTree as a Kubernetes cluster upgrade each node's kubrelet, which is part of the operating system software package, and the operating system software package.
2. The method of in-situ upgrade of Kubernetes cluster based on OSTree, wherein upgrading the upgrade controller operating in the Kubernetes cluster comprises:
the upgrade controller running currently creates a controller for managing resource update tasks;
and according to a kubectl apply command corresponding to the execution resource update of the Deployment resource corresponding to the new version, updating the Deployment resource corresponding to the new version into the current Kubernetes cluster.
3. The Kubernetes cluster in-place upgrade method of claim 1, wherein the upgrade controller of the new version upgrades CNI components comprising:
the upgrade controller running currently creates a controller for managing the CNI update task;
and according to the YAML corresponding to the new version CNI component corresponding to the new version, executing the kubectl apply command corresponding to the CNI update, and updating the YAML corresponding to the new version CNI component into the current Kubernetes cluster.
4. The Kubernetes cluster in-place upgrade method of claim 1, wherein upgrading the core related components of Kubernetes comprises:
sequentially upgrading the control plane nodes based on a kubuead command line tool;
under the condition that the last control plane node is upgraded, sequentially upgrading the load nodes;
the command of the command line is realized by a pre-established controller for updating the task of the management node scheduled to the node, and the command is locally run on the updated node.
5. The Kubernetes cluster in-place upgrade method of claim 1, wherein upgrading the operating system comprises:
after restarting a node to be upgraded, the upgrade controller creates a Pod operation upgrade command which is scheduled to the node to be upgraded;
and according to the upgrade command, upgrading the operating system at the local of each node to be upgraded.
6. The Kubernetes cluster in-situ upgrade method based on OSTree of claim 5, wherein before restarting the node to be upgraded comprises:
and the upgrade controller drains the load on the node to be upgraded and transfers the load to other preset nodes through the scheduling of the Kubernetes.
7. The Kubernetes cluster in-place upgrade method based on the OSTree of claim 5, wherein the upgrade order of the operating system comprises: and the version of the mirror address is used for realizing abnormal rollback based on the mirror address of the OSTree.
8. An OSTree-based Kubernetes cluster in-situ upgrade system, applied to the OSTree-based Kubernetes cluster in-situ upgrade method according to any one of claims 1-7, the system comprising:
the first upgrading unit is used for upgrading an upgrading controller running in the Kubernetes cluster, and the upgrading controller is deployed in a form of deviyment;
the second upgrading unit is used for upgrading the CNI component by the upgrading controller of the new version after the upgrading controller is upgraded to the new version;
the third upgrading unit is used for upgrading the core related components of the Kubernetes, and the core related components at least comprise core components on a Master node;
and the fourth upgrading unit is used for introducing an OSTree as a node of the Kubernetes cluster to upgrade kubrelet and an operating system software package of each node when the core related components are upgraded, wherein the kubrelet is a part of the operating system software package.
9. An electronic device, comprising:
a memory for storing a processing program;
a processor which, when executing the processing program, implements the Kubernetes cluster in-place upgrade method based on OSTree according to any one of claims 1 to 7.
10. A readable storage medium, wherein a processing program is stored on the readable storage medium, and when executed by a processor, the processing program implements the Kubernetes cluster in-place upgrade method based on the OSTree according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310347744.XA CN116360834A (en) | 2023-04-03 | 2023-04-03 | Kubernetes cluster in-situ upgrading method and system based on OSTree |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310347744.XA CN116360834A (en) | 2023-04-03 | 2023-04-03 | Kubernetes cluster in-situ upgrading method and system based on OSTree |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116360834A true CN116360834A (en) | 2023-06-30 |
Family
ID=86904506
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310347744.XA Pending CN116360834A (en) | 2023-04-03 | 2023-04-03 | Kubernetes cluster in-situ upgrading method and system based on OSTree |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116360834A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116866180A (en) * | 2023-07-04 | 2023-10-10 | 北京志凌海纳科技有限公司 | Cluster upgrading test method and system |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200073957A1 (en) * | 2018-08-29 | 2020-03-05 | Red Hat, Inc. | Preserving symbolic links and paths in a file system using an intermediate file system structure |
| CN112947976A (en) * | 2021-04-26 | 2021-06-11 | 统信软件技术有限公司 | Operating system upgrading method, computing device and storage medium |
| CN115658235A (en) * | 2022-11-07 | 2023-01-31 | 统信软件技术有限公司 | Cluster deployment method, computing device and storage medium |
-
2023
- 2023-04-03 CN CN202310347744.XA patent/CN116360834A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200073957A1 (en) * | 2018-08-29 | 2020-03-05 | Red Hat, Inc. | Preserving symbolic links and paths in a file system using an intermediate file system structure |
| CN112947976A (en) * | 2021-04-26 | 2021-06-11 | 统信软件技术有限公司 | Operating system upgrading method, computing device and storage medium |
| CN115658235A (en) * | 2022-11-07 | 2023-01-31 | 统信软件技术有限公司 | Cluster deployment method, computing device and storage medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116866180A (en) * | 2023-07-04 | 2023-10-10 | 北京志凌海纳科技有限公司 | Cluster upgrading test method and system |
| CN116866180B (en) * | 2023-07-04 | 2024-03-01 | 北京志凌海纳科技有限公司 | Cluster upgrading test method and system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9471365B2 (en) | Techniques for performing virtual machine software upgrades using virtual disk swapping | |
| EP2946293B1 (en) | Healing cloud services during upgrades | |
| JP5367074B2 (en) | Virtual machine and application life cycle synchronization | |
| EP2929431B1 (en) | Virtual machine-preserving host updates | |
| US8286154B2 (en) | Apparatus and method for live loading of version upgrades in a process control environment | |
| US8464246B2 (en) | Automation of mainframe software deployment | |
| US20140007092A1 (en) | Automatic transfer of workload configuration | |
| US10715594B2 (en) | Systems and methods for update propagation between nodes in a distributed system | |
| US11327738B2 (en) | Software and firmware updates in a combined single pane of glass interface | |
| US20220244944A1 (en) | Desired state model for managing lifecycle of virtualization software | |
| US20210311711A1 (en) | Desired state model for managing lifecycle of virtualization software | |
| CN112434008A (en) | Distributed database upgrading method, device and medium | |
| CN112925609B (en) | OpenStack cloud platform upgrading method and device | |
| CN116360834A (en) | Kubernetes cluster in-situ upgrading method and system based on OSTree | |
| US20230161643A1 (en) | Lifecycle management for workloads on heterogeneous infrastructure | |
| CN110764785B (en) | Cloud platform tool chain and cloud platform operation and maintenance method for power industry based on open source assembly | |
| CN116149713B (en) | Program upgrading method and device for all-level equipment under tree-type heterogeneous network | |
| US20230342181A1 (en) | Validation of combined software/firmware updates | |
| CN111427588A (en) | Suspending installation of firmware packages | |
| US11347497B1 (en) | Uniform software and firmware management of clusters of heterogeneous server hardware | |
| CN112559006A (en) | Enterprise client automatic upgrading method, system, equipment and storage medium | |
| KR102423056B1 (en) | Method and system for swapping booting disk | |
| CN106843952B (en) | Method and device for updating function module in application | |
| CN115277813B (en) | Super-fusion cluster host resource control method, system, equipment and readable medium | |
| US11853275B2 (en) | Upgrading a database management system deployed in a cloud platform |
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 | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20230630 |