CN110704165A - High-availability deployment method for container - Google Patents

High-availability deployment method for container Download PDF

Info

Publication number
CN110704165A
CN110704165A CN201910949675.3A CN201910949675A CN110704165A CN 110704165 A CN110704165 A CN 110704165A CN 201910949675 A CN201910949675 A CN 201910949675A CN 110704165 A CN110704165 A CN 110704165A
Authority
CN
China
Prior art keywords
node
affinity
scheduling
pod
machine
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
Application number
CN201910949675.3A
Other languages
Chinese (zh)
Inventor
尹东超
王文岗
石光银
高传集
蔡卫卫
孙思清
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inspur Cloud Information Technology Co Ltd
Original Assignee
Inspur Cloud Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Inspur Cloud Information Technology Co Ltd filed Critical Inspur Cloud Information Technology Co Ltd
Priority to CN201910949675.3A priority Critical patent/CN110704165A/en
Publication of CN110704165A publication Critical patent/CN110704165A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45562Creating, deleting, cloning virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/4557Distribution of virtual machine instances; Migration and load balancing

Abstract

The invention particularly relates to a high-availability deployment method for a container. According to the container high-availability deployment method, a scheduling strategy is reasonably configured based on the inverse affinity characteristic of K8s, and multiple copies of the same application are forcibly scheduled to virtual machine nodes located on different physical machines, so that high availability of a cluster is guaranteed. The container high-availability deployment method can realize automatic scheduling of the cluster key Pod on different physical machine nodes, and effectively avoids the problem that the scheduling of the cluster key Pod is abnormal due to the fact that a plurality of virtual machine nodes are unavailable due to the failure of a single physical machine.

Description

High-availability deployment method for container
Technical Field
The invention relates to the technical field of cluster deployment, in particular to a high-availability deployment method for a container.
Background
Kubernetes (K8s) is a brand-new container technology-based distributed architecture leading scheme, and on the basis of the Docker technology, a series of complete functions such as deployment and operation, resource scheduling, service discovery, dynamic scaling and the like are provided for containerized applications, so that the convenience and high availability of large-scale container cluster management are improved.
The primary functions of a container platform are to allocate computing, storage, and network resources to the container that are needed at runtime. The container scheduling system is responsible for choosing the most appropriate host on which to launch the containers and associating them. It must be able to automatically handle container failures and to automatically launch more containers on more hosts to handle more application accesses.
Task scheduling based on resource allocation is a core component of kubernets and is also the basis and key for achieving high availability. The key component of the K8s scheduling system is a Scheduler, which is responsible for allocating defined Pod to the nodes of the cluster according to a certain scheduling policy. Reasonable scheduling nodes need to comprehensively consider various factors including but not limited to the following:
(one) fairness: how to guarantee that each node can be allocated resources;
(II) efficient resource utilization: all resources of the cluster are maximally used;
(III) efficiency: the scheduling performance is good, and the scheduling work can be completed on a large batch of Pod as fast as possible;
(IV) flexibility: allowing the user to control the scheduling logic according to his own needs.
The router operates as an independent program, after starting, the router continuously monitors the kube-api over, obtains the Pod with the PodSpec, the Nodename of which is empty, and creates a corresponding Binding for each Pod, which marks the node on which the Pod should operate. Wherein, several core scheduling strategies realized by the Scheduler are as follows:
firstly, Node Affinity and inverse Affinity (Affinity/Affinity);
(II), Node taint and tolerance (Taints and tolerizations);
(III), Affinity and counter-Affinity of Pod (Affinity/Affinity);
and (IV) customizing the scheduler.
If two applications frequently interact with application B, it is necessary to bring the two applications as close as possible, even at one node, using affinity, to reduce the performance loss due to network communication.
When the application adopts multi-copy deployment, it is necessary to adopt inverse affinity to scatter application instances on nodes to improve availability.
The conventional Kubernetes (K8s) cluster deployment mode is that a physical machine is taken as a unit, and as a single node in a K8s cluster, a multi-physical machine cluster realizes K8s cluster building and high availability. Another deployment environment is based on multiple virtual machines on a physical machine being deployed as a K8s node. When a cluster is deployed in a multiple physical machine X multiple virtual machine scheme, if a single physical machine fails, all virtual machines/nodes of the machine will be unavailable, which in turn may cause serious availability problems for the entire K8s cluster. It is therefore necessary to manually assign a master node (master) to a virtual machine located on a different physical machine to deal with the availability problem of a single physical machine failure causing all nodes on the same machine to hang.
Therefore, how to reasonably utilize the scheduling tool of K8s to implement the Pod scheduling based on the physical machine by reasonably customizing the scheduling policy is a problem of great concern to those skilled in the art.
Based on the situation, in order to provide a Pod scheduling scheme based on a physical machine for a scheduling tool and a scheduling strategy based on kubernets, the scheme can realize reasonable scheduling of the cluster key Pod to virtual machine nodes on different physical machines, and finally realize high availability of cluster application. The invention provides a high-availability deployment method for a container.
Disclosure of Invention
In order to make up for the defects of the prior art, the invention provides a simple and efficient container high-availability deployment method.
The invention is realized by the following technical scheme:
a method for deploying a container with high availability, characterized by: and reasonably configuring a scheduling strategy based on the anti-affinity characteristic of K8s, and forcibly scheduling a plurality of copies of the same application to virtual machine nodes on different physical machines so as to ensure high availability of the cluster.
When the cluster is deployed, distributing physical _ machine _ IP attribute for each node, and declaring the IP address of a physical machine where the node is located; when deploying a Pod, a declarative affinity (affinity) policy, using physical machine IP as the topology key value of the anti-affinity policy, the Pod will be forced to be allocated to a virtual machine node located on a different physical machine when it is scheduled.
The high-availability deployment method of the container comprises the following steps:
first, the nodes are distributed
When the nodes are distributed, editing a my _ inventory.cfg file, and designating virtual machines IP corresponding to a master node (master) as virtual machines located in different physical machine nodes;
second, IP is allocated
Adding physical _ machine _ IP to each node, wherein the physical _ machine _ IP is x.x.x.x label and corresponds to the IP of the physical machine where the current node is located;
thirdly, configuring the anti-affinity strategy
Editing all.yml files, starting an anti-affinity switch anti _ affinity _ enabled, namely, true (default closed), allowing a deployment script to execute corresponding tasks, and marking a physical _ machine _ ip label for each node; and the label value is a physical machine IP address provided by all.
In the third step, a tag Selector label Selector is used to define the key Pod to apply the anti-affinity strategy.
In the third step, required During Scheduling Ignorred duringExecution mandatory inverse affinity is applied.
In order to avoid the situation that the current cluster node cannot meet the Scheduling requirement and the Pod is always in a waiting (Pending) state and cannot be scheduled, in the third step, a preferred dual Scheduling ignoreddual Execution priority back affinity policy may also be used, allowing Scheduling between nodes on the same physical machine.
In order to avoid the situation that the current cluster node cannot meet the scheduling requirement and the Pod is always in a waiting (Pending) state and cannot be scheduled, in the third step, the cluster node may be expanded, and conditions are created to meet the Pod scheduling.
In the third step, a Pod tolerance policy (tolerizations), a taint policy (pointers) on the tolerant master node (master), and a Pod is scheduled to the master node meeting the condition.
In the third step, an external IP controller is deployed at an external IP node in the cluster of K8s, and is used for binding an external access network card and ensuring high availability of the external IP.
The invention has the beneficial effects that: the container high-availability deployment method can realize automatic scheduling of the cluster key Pod on different physical machine nodes, and effectively avoids the problem that the scheduling of the cluster key Pod is abnormal due to the fact that a plurality of virtual machine nodes are unavailable due to the failure of a single physical machine.
Detailed Description
In order to make those skilled in the art better understand the technical solution of the present invention, the technical solution in the embodiment of the present invention will be clearly and completely described below with reference to the embodiment of the present invention. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
According to the container high-availability deployment method, a scheduling strategy is reasonably configured based on the inverse affinity characteristic of K8s, and multiple copies of the same application are forcibly scheduled to virtual machine nodes located on different physical machines, so that high availability of a cluster is guaranteed.
When the cluster is deployed, distributing physical _ machine _ IP attribute for each node, and declaring the IP address of a physical machine where the node is located; when deploying a Pod, a declarative affinity (affinity) policy, using physical machine IP as the topology key value of the anti-affinity policy, the Pod will be forced to be allocated to a virtual machine node located on a different physical machine when it is scheduled.
The high-availability deployment method of the container comprises the following steps:
first, the nodes are distributed
When the nodes are distributed, editing a my _ inventory.cfg file, and designating virtual machines IP corresponding to a master node (master) as virtual machines located in different physical machine nodes;
second, IP is allocated
Adding physical _ machine _ IP to each node, wherein the physical _ machine _ IP is x.x.x.x label and corresponds to the IP of the physical machine where the current node is located;
thirdly, configuring the anti-affinity strategy
Editing all.yml files, starting an anti-affinity switch anti _ affinity _ enabled, namely, true (default closed), allowing a deployment script to execute corresponding tasks, and marking a physical _ machine _ ip label for each node; and the label value is a physical machine IP address provided by all.
Yal. yaml configuration example:
---
[all]
master1 ip=192.168.0.10 physical_machine_ip=192.168.1.12
master2 ip=192.168.0.11 physical_machine_ip=192.168.1.13
master3 ip=192.168.0.12 physical_machine_ip=192.168.1.14
slave1 ip=192.168.0.13 physical_machine_ip=192.168.1.15
in the third step, a tag Selector label Selector is used to define the key Pod to apply the anti-affinity strategy.
Pod yaml configuration example:
Figure BDA0002225369070000051
in the third step, required During Scheduling Ignorred duringExecution mandatory inverse affinity is applied.
In order to avoid the situation that the current cluster node cannot meet the Scheduling requirement and the Pod is always in a waiting (Pending) state and cannot be scheduled, in the third step, a preferred dual Scheduling ignoreddual Execution priority back affinity policy may also be used, allowing Scheduling between nodes on the same physical machine.
In order to avoid the situation that the current cluster node cannot meet the scheduling requirement and the Pod is always in a waiting (Pending) state and cannot be scheduled, in the third step, the cluster node may be expanded, and conditions are created to meet the Pod scheduling.
In the third step, a Pod tolerance policy (tolerizations), a taint policy (pointers) on the tolerant master node (master), and a Pod is scheduled to the master node meeting the condition.
Configuration examples refer to the following:
Figure BDA0002225369070000052
Figure BDA0002225369070000061
the dirty descriptor master1 can be used to view the dirty (pointers) configuration policy of the current master node (master).
In the third step, an external IP controller is deployed at an external IP node in the cluster of K8s, and is used for binding an external access network card and ensuring high availability of the external IP.
A method for deploying a container with high availability in the embodiment of the present invention is described in detail above. While the present invention has been described with reference to specific examples, which are provided to assist in understanding the core concepts of the present invention, it is intended that all other embodiments that can be obtained by those skilled in the art without departing from the spirit of the present invention shall fall within the scope of the present invention.

Claims (9)

1. A method for deploying a container with high availability, characterized by: and reasonably configuring a scheduling strategy based on the anti-affinity characteristic of K8s, and forcibly scheduling a plurality of copies of the same application to virtual machine nodes on different physical machines so as to ensure high availability of the cluster.
2. The vessel high availability deployment method of claim 1, characterized by: when the cluster is deployed, distributing physical _ machine _ IP attribute for each node, and declaring the IP address of a physical machine where the node is located; when the Pod is deployed, an affinity strategy is declared, physical machine IP is used as a topological key value of the anti-affinity strategy, and the Pod is forced to be distributed to virtual machine nodes located on different physical machines when being scheduled.
3. The vessel high availability deployment method of claim 2, comprising the steps of:
first, the nodes are distributed
Editing a my _ inventoryy.cfg file when the nodes are allocated, and designating virtual machines IP corresponding to the main nodes as virtual machines located in different physical machine nodes;
second, IP is allocated
Adding physical _ machine _ IP to each node, wherein the physical _ machine _ IP is x.x.x.x label and corresponds to the IP of the physical machine where the current node is located;
thirdly, configuring the anti-affinity strategy
Yml files are edited, an anti-affinity switch anti _ affinity _ enabled is enabled, true is allowed to be deployed, scripts are allowed to execute corresponding tasks, and physical _ machine _ ip tags are marked on each node; and the label value is a physical machine IP address provided by all.
4. The vessel high availability deployment method of claim 3, wherein: in the third step, a tag Selector label Selector is used to define the key Pod to apply the anti-affinity strategy.
5. The vessel high availability deployment method of claim 3, wherein: in the third step, required During Scheduling Ignorred During Execution mandatory anti-affinity is applied.
6. The vessel high availability deployment method of claim 5, wherein: in order to avoid the situation that the current cluster node cannot meet the Scheduling requirement and the Pod is always in a waiting state and cannot be scheduled, in the third step, a preferred dual Scheduling advertised dual affinity priority inverse affinity policy may be further used to allow Scheduling between nodes on the same physical machine.
7. The vessel high availability deployment method of claim 5, wherein: in order to avoid the situation that the current cluster node cannot meet the scheduling requirement and the Pod is always in a waiting state and cannot be scheduled, in the third step, the cluster node can be expanded, and conditions are created to meet the Pod scheduling.
8. The vessel high availability deployment method of any one of claims 3 to 7, wherein: and in the third step, a Pod tolerance strategy can be configured, a taint strategy on the tolerant master node is realized, and the Pod is scheduled to the master node meeting the condition.
9. The vessel high availability deployment method of claim 8, wherein: in the third step, an external IP controller is deployed at an external IP node in the cluster of K8s, and is used for binding an external access network card and ensuring high availability of an external IP.
CN201910949675.3A 2019-10-08 2019-10-08 High-availability deployment method for container Pending CN110704165A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910949675.3A CN110704165A (en) 2019-10-08 2019-10-08 High-availability deployment method for container

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910949675.3A CN110704165A (en) 2019-10-08 2019-10-08 High-availability deployment method for container

Publications (1)

Publication Number Publication Date
CN110704165A true CN110704165A (en) 2020-01-17

Family

ID=69197549

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910949675.3A Pending CN110704165A (en) 2019-10-08 2019-10-08 High-availability deployment method for container

Country Status (1)

Country Link
CN (1) CN110704165A (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111290834A (en) * 2020-01-21 2020-06-16 苏州浪潮智能科技有限公司 Method, device and equipment for realizing high availability of service based on cloud management platform
CN111880898A (en) * 2020-07-27 2020-11-03 山东省计算中心(国家超级计算济南中心) Service scheduling method based on micro-service architecture and implementation system thereof
CN112835989A (en) * 2021-03-31 2021-05-25 中国工商银行股份有限公司 Single-application multi-MySQL Set deployment method and system
CN114721743A (en) * 2022-04-15 2022-07-08 支付宝(杭州)信息技术有限公司 Task execution method and device and electronic equipment
US11474905B2 (en) 2020-12-10 2022-10-18 International Business Machines Corporation Identifying harmful containers
CN117112500A (en) * 2023-10-17 2023-11-24 天津市天河计算机技术有限公司 Resource management method, device, equipment and storage medium

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108075914A (en) * 2016-11-15 2018-05-25 中国移动通信有限公司研究院 A kind of method and the network equipment of dynamic capacity-expanding capacity reducing
CN108228354A (en) * 2017-12-29 2018-06-29 杭州朗和科技有限公司 Dispatching method, system, computer equipment and medium
CN108810013A (en) * 2018-07-02 2018-11-13 山东汇贸电子口岸有限公司 A kind of service access method based on container
CN109960585A (en) * 2019-02-02 2019-07-02 浙江工业大学 A kind of resource regulating method based on kubernetes
CN110175077A (en) * 2019-05-27 2019-08-27 浪潮云信息技术有限公司 A kind of method and system based on order management container resource
US20200019622A1 (en) * 2018-07-11 2020-01-16 EMC IP Holding Company LLC Architecture for scalable metadata microservices orchestration

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108075914A (en) * 2016-11-15 2018-05-25 中国移动通信有限公司研究院 A kind of method and the network equipment of dynamic capacity-expanding capacity reducing
CN108228354A (en) * 2017-12-29 2018-06-29 杭州朗和科技有限公司 Dispatching method, system, computer equipment and medium
CN108810013A (en) * 2018-07-02 2018-11-13 山东汇贸电子口岸有限公司 A kind of service access method based on container
US20200019622A1 (en) * 2018-07-11 2020-01-16 EMC IP Holding Company LLC Architecture for scalable metadata microservices orchestration
CN109960585A (en) * 2019-02-02 2019-07-02 浙江工业大学 A kind of resource regulating method based on kubernetes
CN110175077A (en) * 2019-05-27 2019-08-27 浪潮云信息技术有限公司 A kind of method and system based on order management container resource

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
刘利锋: "基于 NFV 的移动核心网可靠性研究", 《通信技术》 *
周国通: "Kubernetes调度之亲和与反亲和", 《HTTPS://WWW.BBSMAX.COM/A/KPZOKEZAZX/》 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111290834A (en) * 2020-01-21 2020-06-16 苏州浪潮智能科技有限公司 Method, device and equipment for realizing high availability of service based on cloud management platform
CN111290834B (en) * 2020-01-21 2023-06-16 苏州浪潮智能科技有限公司 Method, device and equipment for realizing high service availability based on cloud management platform
CN111880898A (en) * 2020-07-27 2020-11-03 山东省计算中心(国家超级计算济南中心) Service scheduling method based on micro-service architecture and implementation system thereof
CN111880898B (en) * 2020-07-27 2022-04-05 山东省计算中心(国家超级计算济南中心) Service scheduling method based on micro-service architecture and implementation system thereof
US11474905B2 (en) 2020-12-10 2022-10-18 International Business Machines Corporation Identifying harmful containers
CN112835989A (en) * 2021-03-31 2021-05-25 中国工商银行股份有限公司 Single-application multi-MySQL Set deployment method and system
CN112835989B (en) * 2021-03-31 2024-02-09 中国工商银行股份有限公司 Deployment method and system for single-application multi-MySQL Set
CN114721743A (en) * 2022-04-15 2022-07-08 支付宝(杭州)信息技术有限公司 Task execution method and device and electronic equipment
CN114721743B (en) * 2022-04-15 2024-02-13 支付宝(杭州)信息技术有限公司 Task execution method and device and electronic equipment
CN117112500A (en) * 2023-10-17 2023-11-24 天津市天河计算机技术有限公司 Resource management method, device, equipment and storage medium
CN117112500B (en) * 2023-10-17 2024-01-26 天津市天河计算机技术有限公司 Resource management method, device, equipment and storage medium

Similar Documents

Publication Publication Date Title
CN110704165A (en) High-availability deployment method for container
CN108337109B (en) Resource allocation method and device and resource allocation system
US8589920B2 (en) Resource allocation
EP3073374B1 (en) Thread creation method, service request processing method and related device
CN110098946B (en) Method and device for deploying virtualized network element equipment
CN111162941B (en) Method for automatically managing virtual IP (Internet protocol) in Kubernetes environment
CN102609295A (en) Dynamic operation scheduling system of virtual machine
CN105159775A (en) Load balancer based management system and management method for cloud computing data center
CN103064742A (en) Automatic deployment system and method of hadoop cluster
CN110838939B (en) Scheduling method based on lightweight container and edge Internet of things management platform
CN111641515A (en) VNF life cycle management method and device
WO2021103646A1 (en) Pod deployment method and device
CN107920117B (en) Resource management method, control equipment and resource management system
US20230266999A1 (en) Resource scheduling method, resource scheduling system, and device
KR20130019698A (en) Method for optimizing resource by using migration based on user's scheduler
CN114518955A (en) Flunk cloud native deployment architecture method and system based on kubernets
CN114968601A (en) Scheduling method and scheduling system for AI training jobs with resources reserved according to proportion
CN112003931B (en) Method and system for deploying scheduling controller and related components
CN111240824A (en) CPU resource scheduling method and electronic equipment
CN116340005B (en) Container cluster scheduling method, device, equipment and storage medium
CN109614229B (en) Virtual network resource allocation system based on software definition
CN116680078A (en) Cloud computing resource scheduling method, device, equipment and computer storage medium
CN115987872A (en) Cloud system based on resource routing
CN114338670B (en) Edge cloud platform and network-connected traffic three-level cloud control platform with same
CN107122225B (en) Method and device for starting virtual machine

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20200117

RJ01 Rejection of invention patent application after publication