Game operation management system based on kubernetes crd

Abstract

The application discloses a game operation management system based on a kubernetes CRD, and relates to the technical field of game operation, solves the problem of not solving the server load condition based on the residual computing power among multiple servers, and performs computing power scheduling according to the accurate accounting of the total load ZF and the total idle amount KF. When KF is greater than or equal to ZF, the idle server computing power is sequentially allocated to the load server until all the load servers enter a reasonable computing power interval, so that each server can be in an optimal operating state, and the scene loading, battle matching response and the like in the game can be rapidly smooth, and a high-level player service experience is maintained. Under the complex condition that KF is less than ZF, the load server sequence is locked through detailed load server computing power feature analysis, and the to-be-scheduled server is skillfully selected, so that the limited idle computing power is most reasonably distributed.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of game operation, in particular to a game operation management system based on kubernetes CRD. BACKGROUND

[0002] Game operation should make full use of systems such as those based on Kubernetes CRD to finely manage server resources. Through real-time monitoring of player traffic on the server by an index monitoring terminal (such as Prometheus), the "pulse" of the game server running state can be grasped, which enables the operator to accurately determine whether the server is in a load state or an idle state according to the player traffic and server computing power; for example, during a popular game event, player traffic surges, and through dynamic assessment of server load by the system, servers with excessive load can be found in time to provide a basis for subsequent resource allocation.

[0003] Application No. CN105812465A discloses a game server load balancing method, including the steps of: maintaining a game server list containing information of multiple in-operation game servers currently providing game services and information of at least one standby game server; real-time monitoring of the load level of the multiple in-operation game servers in the list; when the load level of any in-operation game server reaches a first load upper limit, setting one standby game server in the list as an in-operation game server; in response to a login request from a client, selecting an in-operation server from the in-operation game servers in the list according to a first rule; and sending the server information of the selected in-operation server to the client so that it establishes a long connection with the client. The application also provides a corresponding game server load balancing device and system.

[0004] In view of the specific situation of server load, in the specific operation process, when a load server appears, power optimization and scheduling are directly performed from the outside to reduce the load of the corresponding server. However, the original processing method does not associate and schedule the computing power of multiple servers, does not perform internal scheduling optimization, and thus the computing power resources are wasted. SUMMARY

[0005] In view of the deficiencies of the prior art, the application provides a game operation management system based on kubernetes CRD, which solves the problem of not solving the server load condition based on the residual computing power between multiple servers.

[0006] To achieve the above purpose, the application realizes the following technical scheme: a game operation management system based on kubernetes CRD, comprising:

[0007] The index monitoring end adopts Prometheus to monitor the player flow of different servers in the game in real time, and transmits the different player flow monitored by different servers in real time to the server load analysis end.

[0008] The server load analysis end assesses the load state of each server based on the computing power held by the corresponding server and the real-time associated player flow, and marks the server with a load state as a load server and the server without a load state as an idle server, in a specific manner:

[0009] The real-time monitored player flow about the corresponding server is marked as L i , where i represents different servers, and the computing power held by the corresponding server is marked as S i .

[0010] S i ÷L i =F i The computing power feature F i shared by the corresponding server and the corresponding player is confirmed, and several groups of computing power features F i confirmed by different servers are processed by averaging to confirm the feature average JJ.

[0011] Based on the confirmed feature average JJ, a group of feature intervals is locked, and the feature interval is [JJ-Y1, JJ+Y1], where Y1 is a preset value. The corresponding server with F i <JJ-Y1 is marked as a load server, and the corresponding server with F i >JJ+Y1 is marked as an idle server.

[0012] The server deployment optimization end, based on the marked load server or idle server, preferentially confirms the load total amount of the load server, and then confirms the idle total amount of the corresponding idle server, schedules the computing power between servers based on the difference between the two computing power values, in a specific manner:

[0013] Based on the marked load server, the computing power feature F i associated with the corresponding load server is confirmed, and (JJ-Y1)-F i =FC i The load parameter FC i of the corresponding load server is confirmed, and the load parameters associated with several load servers are processed by summation to confirm the load total amount ZF of the load server.

[0014] Based on the marked idle server, the computing power feature F i associated with the corresponding idle server is confirmed, and F i -(JJ+Y1)=KCi Confirming the idle parameter KC corresponding to the idle server i , and then summing up the idle parameters associated with several idle servers to confirm the total idle amount KF of the idle servers;

[0015] Checking the total load amount ZF and the total idle amount KF:

[0016] If KF≥ZF, the holding computing power of the idle servers is sequentially dispatched to the load servers, and when the computing power characteristic associated with a single group of idle servers changes to the characteristic interval during the dispatch, the dispatch stops, and the computing power of the next group of idle servers is dispatched, and when the computing power characteristic of the load server changes to the characteristic interval during the acceptance of the computing power dispatch, the acceptance of the computing power dispatch stops, and so on, until the computing power characteristic of all the load servers changes to the characteristic interval, and the dispatch process stops;

[0017] If KF<ZF, the computing power characteristic of the load server is analyzed, and from the analysis result, the load server sequence is locked, and the computing power characteristic F i , and then the computing power characteristic of the other load servers is sequentially selected and summed up to confirm the sum value ZH, when the confirmed sum value ZH=ZF, the selected load server is marked as a to-be-dispatched server, and the computing power dispatch mode when KF≥ZF is directly used to dispatch the to-be-dispatched server, when the confirmed sum value ZH>ZF, the selected computing power characteristic is removed to make ZH<ZF, the selected load server is marked as a to-be-dispatched server, and the computing power dispatch mode when KF≥ZF is used to dispatch the to-be-dispatched server, and the load server that does not participate in the confirmation of the sum value in this stage is marked as a to-be-determined server;

[0018] The to-be-determined server processing end confirms the number of replicas in the to-be-determined server based on the marked to-be-determined server, records the request times of the related replicas in a specified period based on the record result, confirms the related replicas that need to reduce the parameters based on the record result, and transfers the related replicas to the replica parameter locking end, and the specific mode is:

[0019] Based on the determined to-be-determined server, the running replicas in the to-be-determined server are confirmed, and a group of specified periods are determined, the request times of the corresponding running replicas in the specified period are recorded and marked as Q k , wherein k represents different running replicas, and then the confirmed several groups Q k are processed by the mean value to confirm the processing mean value JZ;

[0020] The running replicas with Q k < JZ are marked as related replicas;

[0021] The copy optimal parameter locking end locks the lowest CPU usage rate of the related copy based on the calibrated related copy, synchronously records the CPU usage rate of the current related copy as a calibration value, identifies the upload speed and download speed lower than the calibration value from the historical data of the related copy, and locks the lowest CPU usage rate of the related copy based on specific numerical values. The specific method is:

[0022] Based on the determined calibration value, the related historical data lower than the calibration value is locked from the historical data of the related copy, and the upload speed and download speed associated with different CPU usage rates are identified from the related historical data. The identified upload speed and download speed are summed to lock the total speed, and the total speed is used as the determination feature of the CPU usage rate;

[0023] The determination feature is compared with the preset value Y2, and the CPU usage rate with a determination feature greater than or equal to Y2 is selected as the optional utilization rate;

[0024] The minimum value is selected from the different determination features associated with the different optional utilization rates, and the optional utilization rate corresponding to the minimum value is selected as the lowest CPU usage rate of the related copy;

[0025] Based on the lowest CPU usage rate confirmed for the corresponding related copy, the CPU usage rate of the corresponding related copy is reduced to the lowest CPU usage rate by the server processing end, and the excess CPU usage rate generated after the reduction is allocated to the running copy that does not belong to the related copy.

[0026] Preferably, the server deployment optimization end locks the specific method of the load server sequence as follows:

[0027] A set of traceable periods is defined from the current time, and the traceable period is a preset period. The computing power feature F i is confirmed, and based on the chronological relationship, the computing power features F i associated with different time points are sorted to confirm the feature sequence. The computing power features associated with adjacent time points in the feature sequence are F j , F j+1 , where F j belongs to the previous group of time points in the adjacent time points, and F j+1 belongs to the latter group of time points in the adjacent time points. The computing power feature change value = F j - F j+1 The confirmed several groups of computing power feature change values are processed by mean value to confirm the feature value associated with the load server in the traceable period.

[0028] The associated characteristic values of different load servers are confirmed in sequence, and then the load servers are sorted according to the associated characteristic value from large to small, and the sequence of the load servers is confirmed.

[0029] Preferably, in the pending server processing end, the Kubernetes performs the allocation of the redundant CPU usage to the running replica not belonging to the relevant replica.

[0030] The application provides a game operation management system based on a kubernetes CRD.

[0031] 1. Through real-time and accurate monitoring of the player flow of different servers in the game by Prometheus, combined with the load evaluation of the server itself, the load server and the idle server can be accurately distinguished, which avoids the problem of inaccurate estimation of server resources in traditional extensive management, ensures that idle resources are not wasted, and busy servers will not be overloaded and performance will not be collapsed, greatly improves the overall resource utilization, and reduces unnecessary hardware investment cost.

[0032] 2. According to the accurate calculation of the total load ZF and the total idle KF, the computing power is scheduled. When KF is greater than or equal to ZF, the idle server computing power is allocated to the load server in order until all load servers enter the reasonable computing power interval, so that each server can be in the best operating state, and the scene loading, battle matching response and other scenes in the game can be quickly and smoothly, and the high-quality player service experience is maintained. In the complex case of KF<ZF, the load server sequence is locked through detailed load server computing power feature analysis, and the to-be-scheduled server is skillfully selected to ensure that the limited idle computing power is most reasonably allocated.

[0033] 3. The pending server processing end cooperates with the replica optimal parameter locking end, and accurately locates the optimal replica for the pending server replica from the request frequency mean analysis, locks the lowest CPU usage through historical data digging, breaks through the limitation of traditional single index optimization, and allocates the redundant CPU usage released by the optimized replica to other running replicas through Kubernetes to realize secondary resource balancing in the cluster. BRIEF DESCRIPTION OF DRAWINGS

[0034] Figure 1 It is a schematic diagram of the principle framework of the application;

[0035] Figure 2 It is a schematic diagram of the determination of the relevant replica. DETAILED DESCRIPTION

[0036] With reference to the accompanying drawings, the technical solutions in the embodiments of the present application will be clearly and completely described below, obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0037] First embodiment

[0038] Please refer to Figure 1 The application provides a game operation management system based on kubernetes CRD, which comprises an index monitoring end, a server load analysis end, a server deployment optimization end, a pending server processing end and a replica optimal parameter locking end, wherein the index monitoring end, the server load analysis end, the server deployment optimization end and the pending server processing end are electrically connected in sequence from the output node to the input node, and the pending server processing end and the replica optimal parameter locking end are bidirectionally connected.

[0039] The index monitoring end uses Prometheus (a toolkit with data collection function) to monitor the player flow of different servers in the game in real time, and transmits the different player flows monitored by different servers in real time to the server load analysis end. In the corresponding game entry interface, there are multiple different related servers. Because the popularity of each server is different, it will cause the player flow of some servers to be too much and the player flow of some servers to be too little. However, at the initial running time, the computing power allocated to each server is basically the same. Therefore, in order to avoid the situation that some servers are overloaded, the computing power is allocated from the servers with less load, and the allocated computing power is used by the load servers to avoid affecting the player experience of different servers.

[0040] The server load analysis end evaluates the load state of each server based on the computing power held by the corresponding server and the real-time associated player flow, and marks the servers with load state as load servers and the servers without load state as idle servers. The specific way of evaluating the load state of the server is as follows:

[0041] The real-time monitored player flow of the corresponding server is marked as L i , wherein i represents different servers, and the computing power held by the corresponding server is marked as S i .

[0042] S i ÷L i =F i confirm the computing power feature F evenly distributed by the corresponding server for the corresponding player iand several groups of computing power features F i The mean value JJ is calculated and confirmed;

[0043] Based on the confirmed feature mean value JJ, a group of feature intervals is locked, and the feature interval is [JJ-Y1, JJ+Y1], where Y1 is a preset value, and the specific value is determined by the operator according to experience. F i The corresponding server of <JJ-Y1 is marked as a load server, and F i The corresponding server of >JJ+Y1 is marked as an idle server.

[0044] Specifically, the corresponding load server is a server with large player traffic and small average computing power. Such a server belongs to the corresponding server with load. When the corresponding server has small player traffic and large average computing power, such a server belongs to the corresponding server with idle computing power.

[0045] Among them, the server deployment optimization end, based on the marked load server or idle server, preferentially confirms the total load of the load server, and then confirms the total idle of the corresponding idle server. Based on the difference between the computing power values of the two, the computing power between the servers is scheduled so that the servers can be in the best operating state. The specific way of scheduling the computing power between the servers is:

[0046] Based on the marked load server, the computing power feature F i of the corresponding load server is confirmed, and (JJ-Y1)-F i =FC i The load parameter FC of the corresponding load server is confirmed. i The load parameters associated with several load servers are summed and processed to confirm the total load ZF of the load server.

[0047] Based on the marked idle server, the computing power feature F i of the corresponding idle server is confirmed, and F i -(JJ+Y1)=KC i The idle parameter KC of the corresponding idle server is confirmed. i The idle parameters associated with several idle servers are summed and processed to confirm the total idle KF of the idle server.

[0048] The confirmed total load ZF and total idle KF are checked:

[0049] If KF≥ZF, the holding computing power of the idle server is sequentially dispatched to the load server, and when the single group of idle servers is dispatched, the associated computing power feature changes to the feature interval, the dispatching stops, and the next group of idle servers is dispatched, and when the load server accepts the computing power dispatch, the computing power feature changes to the feature interval, the dispatching stops, and so on, until the computing power feature of all load servers changes to the feature interval, the dispatching process stops. Specifically, because the computing power of the idle server is much higher than the load feature of the corresponding load server, during the computing power dispatching process, the corresponding computing power is dispatched from the idle server to the corresponding load server, and the computing power feature is sufficient, so the related dispatching can be directly performed to complete the load state adjustment process of the corresponding load server and improve the game experience of the corresponding game player.

[0050] If KF<ZF, the computing power feature of the load server is analyzed, and from the computing power feature analysis result, the load server sequence is locked, wherein the specific way of locking the load server sequence is:

[0051] A group of tracing periods is defined from the current time, and the tracing period is a preset period, which is determined in advance by the relevant operating personnel according to experience. The tracing period is a history period, a group of time periods are confirmed from the current time, and the computing power features F i associated with the corresponding load server at different times in the tracing period are confirmed, and based on the chronological relationship, the computing power features F i associated with the corresponding load server at different times are sorted to confirm the feature sequence, the computing power feature values between adjacent time points are confirmed, and the computing power features associated with adjacent time points in the feature sequence are F j , F j+1 , wherein F j belongs to the former time point in the adjacent time point, and F j+1 belongs to the latter time point in the adjacent time point, and the computing power feature change value = F j -F j+1 The confirmed computing power feature change values are processed by averaging, and the associated feature value of this load server in this tracing period is confirmed.

[0052] The associated feature values of different load servers are sequentially confirmed, and then the load servers are sorted according to the associated feature values from large to small to confirm the load server sequence.

[0053] Based on the confirmed load server sequence, the computing power feature F iAt the beginning, the hash power features of other load servers are selected in turn to sum up, and the total value ZH is confirmed. When the confirmed total value ZH = ZF, the selected load server is marked as a server to be scheduled, and the hash power scheduling mode when KF ≥ ZF is directly used to schedule the server to be scheduled. When the confirmed total value ZH > ZF, the hash power feature selected in this stage is removed so that ZH < ZF. The selected load server is marked as a server to be scheduled, and the hash power scheduling mode when KF ≥ ZF is used to schedule the server to be scheduled. The load server that does not participate in the total value confirmation in this stage is marked as a pending server. Specifically, the determined ZF is 10, and the hash power features associated with the load server sequence corresponding to the hash power feature sequence are 1, 2, 1.5, 5, 1, and 6. Then, the sum is calculated from the value 1 to the rear. When the value 5 is calculated, the confirmed total value ZH = 9.5, but 9.5 + 1 = 10.5 > 10 (ZF), so the selected value 1 in this time needs to be removed, and the front value column is retained, that is, 1, 2, 1.5, and 5. The four groups of hash power features corresponding to the load servers are marked as servers to be scheduled. The load servers associated with the subsequent values 1 and 6 belong to the pending servers.

[0054] Second embodiment

[0055] For the marked pending servers, the servers of the same type also belong to the load state, but cannot obtain the corresponding hash power scheduling process. Therefore, such pending servers need to be optimized internally, and the replicas in the pending servers are associated and optimized to reduce the load of the pending servers. The specific replica optimization is performed by the Kubernetes executed by the pending server processing end.

[0056] Among them, in combination with Figure 2 , the pending server processing end confirms the number of replicas in the pending server based on the marked pending server, records the number of requests of the related replicas in the specified period, confirms the related replicas that need to be reduced in parameters based on the record result, and transmits the related replicas to the replica optimization parameter locking end. The specific way to confirm the related replicas is:

[0057] Based on the determined pending server, the running replicas in the pending server are confirmed, and a group of specified periods are determined. The specified period is a preset period, which is determined in advance by the related operating personnel according to experience. Generally, the value is 2 min. The number of requests of the corresponding running replicas in the specified period is recorded and marked as Q k , where k represents different running replicas. Then, the confirmed several groups of Q k are processed by mean value to confirm the processing mean value JZ.

[0058] Q kThe running copy of the JZ is calibrated as a relevant copy.

[0059] The copy parameter locking end, based on the calibrated relevant copy, synchronously records the CPU usage of the current relevant copy as a calibration value, identifies the upload speed and download speed lower than the calibration value from the historical data of the relevant copy, and locks the minimum CPU usage of the relevant copy based on the specific numerical expression, and the specific way of locking is:

[0060] Based on the determined calibration value, the relevant historical data lower than the calibration value is locked from the historical data of the relevant copy, and the upload speed and download speed associated with different CPU usage are identified from the relevant historical data, and the identified upload speed and download speed are summed to lock the total speed, and the total speed is taken as the determination feature of the CPU usage;

[0061] The determination feature is checked with the preset value Y2, and the specific value of Y2 is determined by the relevant operating personnel in advance according to experience, and the CPU usage with the determination feature ≥ Y2 is taken as the optional utilization rate;

[0062] Then, the minimum value is selected from the different determination features associated with several different optional utilization rates, and the optional utilization rate corresponding to the minimum value is taken as the minimum CPU usage of the relevant copy.

[0063] The pending server processing end, based on the minimum CPU usage confirmed by the corresponding relevant copy, reduces the CPU usage of the corresponding relevant copy to the minimum CPU usage, and allocates the excess CPU usage generated after the reduction to the running copies not belonging to the relevant copy, and the specific allocation process is executed by Kubernetes;

[0064] Because Kubernetes belongs to the resource configuration definition module in CRD, in order to ensure that the game server uses resources efficiently in the cluster, Kubernetes will schedule according to resource requests and limits to avoid resource waste or excessive allocation. The Kubernetes allocates the excess CPU usage according to the running load of the running copies not belonging to the relevant copy, so the allocation process is a unique function of the Kubernetes, which is a public prior art, and therefore is not described in detail here.

[0065] Some data in the above formula are dimensionless numerical calculations, and the contents not described in detail in the specification are all prior art known to those skilled in the art.

[0066] The above examples are only used to illustrate the technical method of the present application but not limit the present application. Although the present application is described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical method of the present application can be modified or equivalently replaced without departing from the spirit and scope of the technical method of the present application.

Claims

1. A game operation management system based on a kubernetes CRD, characterized in that, The application relates to a server load balancing method and device. The index monitoring terminal adopts Prometheus to monitor the player flow of different servers in a game in real time, and transmits the different player flow monitored by different servers in real time to the server load analysis terminal. The server load analysis terminal evaluates the load state of each server based on the computing power held by the corresponding server and the real-time associated player flow, and marks the server with the load state as a load server and the server without the load state as an idle server. The real-time monitored player traffic about the corresponding server is calibrated as L i , wherein i represents different servers, and the computing power held by the corresponding server is calibrated as S i ; Adopt S i ÷L i =F i Confirm the corresponding server to the corresponding player of the evenly distributed computing power characteristics F i , and the average value of several groups of computing power characteristics F i confirmed by different servers, confirm the average value JJ; Based on the confirmed feature mean JJ, a set of feature intervals is locked, with the feature interval being [JJ-Y1, JJ+Y1], where Y1 is a preset value, the specific value of which is determined by an operator according to experience, and F i The corresponding server of JJ-Y1 is marked as a load server, and F i The corresponding server of JJ+Y1 is marked as an idle server. The server deployment optimization terminal preferentially confirms the total load of the load server and the total idle of the corresponding idle server based on the marked load server or idle server, schedules the computing power between the servers based on the difference between the two computing power values, and specifically schedules the computing power between the servers as follows. Based on the calibrated load server, the computing power feature F associated with the corresponding load server is confirmed i And adopt: (JJ-Y1) -F i = FC i Confirm the load parameter FC of the corresponding load server i The load parameters associated with several load servers are summed up, and the total load ZF of the load server is confirmed; Based on the calibrated idle server, confirm the computing power characteristics F associated with the corresponding idle server i And adopt: F i - (JJ + Y1) = KC i Confirm the idle parameter KC of the corresponding idle server i And then sum the idle parameters associated with several idle servers to confirm the total idle amount KF of the idle server; The confirmed total load ZF and the total idle KF are checked. If KF is greater than or equal to ZF, the computing power held by the idle server is sequentially scheduled to the load server. When the computing power characteristic of a single group of idle servers changes to a characteristic interval during scheduling, the scheduling is stopped. The next group of idle servers is scheduled. When the computing power characteristic of the load server changes to a characteristic interval during the acceptance of the computing power scheduling, the acceptance of the computing power scheduling is stopped.

2. The Kubernetes CRD-based game operation management system according to claim 1, wherein, If the total idle amount KF is less than the total load amount ZF, the load server is subjected to a computing power feature analysis, and from the computing power feature analysis result, a load server sequence is locked, and the computing power feature F associated with the first load server of the load server sequence is selected i The computing power features of other load servers are sequentially selected and summed, and a total sum value ZH is confirmed. When the confirmed total sum value ZH = ZF, the selected load server is marked as a server to be dispatched, and the computing power scheduling mode when KF ≥ ZF is directly used to schedule the server to be dispatched. When the confirmed total sum value ZH > ZF, the selected computing power feature of this stage is removed so that ZH < ZF, the selected load server is marked as a server to be dispatched, and the computing power scheduling mode when KF ≥ ZF is used to schedule the server to be dispatched. The load servers not participating in the confirmation of the total sum value in this stage are marked as pending servers.

3. The Kubernetes CRD-based game operation management system of claim 2, wherein, The process is repeated until the computing power characteristic of all load servers changes to a characteristic interval. A set of tracing periods is defined from the current time, the tracing period is a preset period, and the computing power feature F associated with the load server at different times in the tracing period is obtained i The confirmation is performed, and based on the time sequence, the computing power features F associated with different times are sorted i The feature sequence is sorted and confirmed, the computing power feature change value between adjacent time points is confirmed, and the computing power features associated with adjacent time points in the feature sequence are respectively F j , F j+1 , wherein F j belongs to the previous group of time points in the adjacent time points, and F j+1 belongs to the latter group of time points in the adjacent time points, and the computing power feature change value is F j -F j+1 The mean value of the confirmed computing power feature change values is processed, and the associated feature value of the load server in the tracing period is confirmed. The standby server processing terminal confirms the number of replicas in the standby server based on the marked standby server, records the request times of the related replicas in a specified period, confirms the related replicas that need to reduce parameters based on the record result, and transmits the related replicas to the replica optimal parameter locking terminal.

4. The Kubernetes CRD-based game operation management system of claim 2, wherein, The replica optimal parameter locking terminal synchronously records the CPU usage of the related replicas and takes the CPU usage as a marked value, identifies the upload speed and download speed lower than the marked value from the historical data of the related replicas, locks the minimum CPU usage of the related replicas based on the specific numerical value, and reduces the CPU usage of the related replicas to the minimum CPU usage. Based on the determined pending server, confirm the running copy in the pending server, and determine a set of specified periods, record the number of requests for the corresponding running copy in the specified period, and mark it as Q k Where k represents different running copies, and the confirmed several groups Q k Perform mean processing to confirm the processing mean JZ; Q k The running copy of the JZ is calibrated as the relevant copy.

5. The Kubernetes CRD-based game operation management system according to claim 4, characterized in that, The standby server processing terminal reduces the CPU usage of the related replicas to the minimum CPU usage, and allocates the excess CPU usage generated after the reduction to the running replicas that do not belong to the related replicas. The server deployment optimization terminal specifically schedules the load server sequence as follows. The associated characteristic values of different load servers are sequentially confirmed, and the load servers are sorted according to the associated characteristic values from large to small to confirm the load server sequence. The standby server processing terminal specifically confirms the related replicas as follows. The replica optimal parameter locking terminal specifically locks the minimum CPU usage of the related replicas as follows. Based on the determined marked value, the related historical data lower than the marked value is locked from the historical data of the related replicas, the upload speed and download speed associated with different CPU usages are identified from the related historical data, the upload speed and download speed are summed, the sum speed is locked as the determined characteristic of the CPU usage, and the sum speed is locked as the determined characteristic of the CPU usage. The determined feature is compared with a preset value Y2, and the CPU usage rate of the determined feature greater than or equal to Y2 is selected as the optional utilization rate, wherein the specific value of Y2 is determined in advance by relevant operation personnel according to experience; Then, the minimum value is selected from different determined features associated with different optional utilization rates, and the optional utilization rate corresponding to the minimum value is selected as the lowest CPU usage rate of the relevant replica.

6. The Kubernetes CRD-based game operation management system according to claim 1, wherein In the pending server processing end, the Kubernetes performs the allocation of the redundant CPU usage rate to the running replica not belonging to the relevant replica.

Images