Automatic destruction method and device for cloud native Kubernetes cluster, medium and program product

Abstract

The invention belongs to the technical field of cloud computing and cloud native, and provides a high-performance cloud native Kubernetes cluster-oriented automatic destruction method and device, a medium and a program product.The method comprises the steps that after a destruction instruction is responded, a destruction process is triggered based on preset self-defined resources, and Kubernetes metadata, database snapshots and container mirror images are backed up to object storage; constructing a service dependency directed graph by relying on distributed tracking link data, and generating a destruction sequence queue; issuing a flow migration instruction to switch external flow, and blocking a gateway entrance after the flow reaches the standard; calling a middleware operation and maintenance interface according to a queue to complete data cleaning and offline, and realizing smooth service exit by setting a termination grace period and the like; and finally, calling a cloud manufacturer API to release resources such as a virtual machine and a cloud disk. According to the method, cluster automation and zero-residue destruction are realized, the operation risk and cost are reduced, the operation and maintenance efficiency is improved, and multi-industry cloud native operation and maintenance requirements are met.

Description

Technical Field

[0001] This invention relates to the field of automated destruction technology for cloud-native Kubernetes clusters, specifically to an automated destruction method, device, medium, and program product for cloud-native Kubernetes clusters. Background Technology

[0002] With the rapid development of cloud computing and cloud-native technologies, Kubernetes (K8s), as an open-source container orchestration platform, has been widely used for the automated deployment, scaling, and management of containerized applications, becoming a core support for enterprises to build DevOps systems and cloud-native infrastructure. However, in the Kubernetes cluster lifecycle management, the cluster destruction and resource reclamation stages still face significant technical challenges, and existing solutions are insufficient to meet the requirements for secure, thorough, and efficient operation and maintenance.

[0003] Current cluster destruction methods largely rely on manual operations or static scripts, which have three major drawbacks: First, they lack dynamic dependency awareness and cannot identify real-time traffic dependencies between services through distributed tracing. Forced shutdown can easily trigger a service call avalanche effect, leading to business interruption or data inconsistency. Second, there is no security isolation mechanism. External traffic may still access the cluster during the destruction process, and traditional scripts cannot accurately cut off traffic paths, increasing the risk of data leakage. Third, resource reclamation is incomplete and there is no reconciliation loop. After destruction, the integrity of cloud resources (such as virtual machines, cloud disks, and IPs) release is not verified, which can easily lead to residual resources causing continuous cost waste. At the same time, manually performing more than ten steps such as traffic cutting off, data backup, and service shutdown is highly complex, time-consuming, and prone to errors.

[0004] The aforementioned issues severely restrict the automation and compliance of cluster operation and maintenance in cloud-native environments, especially failing to meet the stringent requirements of industries such as finance, government and enterprises for zero-interruption, zero-residue, and auditable cluster destruction. There is an urgent need for an automated destruction solution based on dynamic dependency analysis and end-to-end control. Summary of the Invention

[0005] In response, this invention provides an automated destruction method, system, electronic device, and computer program product for cloud-native Kubernetes clusters, to at least partially solve the aforementioned technical problems.

[0006] This invention provides an automated destruction method for cloud-native Kubernetes clusters, comprising the following steps: In response to receiving a destruction command, it triggers automated destruction based on preset custom resources; Back up Kubernetes metadata, database snapshots, and container images to object storage; A service dependency directed graph is constructed based on the link data collected by distributed tracing, and a destruction order queue is generated according to the service call relationship in the directed graph. Issue traffic migration instructions to switch external traffic to other clusters, and block ingress requests through gateway configuration when traffic drops to a preset threshold; The operation and maintenance interfaces of various middlewares are called sequentially according to the destruction order queue to perform data cleanup and persistence shutdown, thereby taking the middleware offline. Control service shutdown by setting a termination grace period, rejecting new connections, and deregistering registry instances to achieve a smooth exit; Call the cloud vendor's API to release resources in sequence. These resources include at least virtual machines, cloud disks, network addresses, and security groups.

[0007] In another aspect, this application also provides an automated destruction device for cloud-native Kubernetes clusters, comprising: The trigger module is used to respond to received destruction commands and trigger automated destruction based on preset custom resources; The backup module is used to back up Kubernetes metadata, database snapshots, and container images to object storage; The destruction order queue construction module is used to build a service dependency directed graph based on the link data collected by distributed tracing, and generate a destruction order queue according to the service call relationship in the directed graph; The external traffic switching module is used to issue traffic migration instructions to switch external traffic to other clusters, and to block ingress requests through gateway configuration when the traffic drops to a preset threshold. The middleware offline module is used to sequentially call the operation and maintenance interfaces of various middleware according to the destruction order queue, perform data cleanup and persistence shutdown, and realize the middleware offline. The service shutdown control module is used to achieve a smooth exit by setting a termination grace period, rejecting new connections, and deregistering the registry instance. The resource release module is used to call the cloud vendor's API to release resources sequentially. The resources include at least virtual machines, cloud disks, network addresses, and security groups.

[0008] This application also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the automated destruction method for cloud-native Kubernetes clusters as described above.

[0009] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement the automated destruction method for cloud-native Kubernetes clusters as described above.

[0010] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the automated destruction method for cloud-native Kubernetes clusters as described above.

[0011] This invention mitigates the risk of unauthorized operations by pre-setting a custom resource triggering process and combining it with RBAC authentication; it generates a destruction queue by constructing a service dependency directed graph based on OpenTelemetry link data, avoiding service call avalanche; it achieves zero-interruption traffic switching through external DOH traffic switching and gateway blocking; it sequentially completes middleware data cleanup and smooth service shutdown, ensuring data consistency; and it calls cloud vendor APIs to release all types of resources and reconcile and alert, eliminating resource residue and cost waste. The entire process requires no manual intervention, significantly improving destruction efficiency and meeting enterprises' needs for auditable and highly secure cluster destruction. It is suitable for cloud-native operation and maintenance scenarios in multiple industries such as finance and government. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0013] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram illustrating an automated destruction method for cloud-native Kubernetes clusters provided in an embodiment of the present invention.

[0014] Figure 2 This is a schematic diagram of the process for generating a destruction order queue provided in an embodiment of the present invention.

[0015] Figure 3 This is a schematic diagram of the structure of an automated destruction device for cloud-native Kubernetes clusters provided in an embodiment of the present invention.

[0016] Figure 4 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The technical solutions of this application will be described in detail below with reference to various embodiments.

[0019] like Figure 1 As shown in the diagram, this invention discloses an automated destruction method for cloud-native Kubernetes clusters, including the following steps: S101, in response to receiving a destruction command, triggers automatic destruction based on preset custom resources; S102, backs up Kubernetes metadata, database snapshots, and container images to object storage; S103, construct a service dependency directed graph based on the link data collected by distributed tracing, and generate a destruction order queue according to the service call relationship in the directed graph; S104 issues a traffic migration command to switch external traffic to other clusters, and blocks ingress requests through gateway configuration when traffic drops to a preset threshold; S105, according to the destruction order queue, call the operation and maintenance interfaces of various middleware in sequence to perform data cleanup and persistence shutdown, and realize the middleware offline; S106, control service shutdown, achieve smooth exit by setting a termination grace period, rejecting new connections, and deregistering the registry instance; S107, call the cloud vendor's API to release resources in sequence, including at least virtual machines, cloud disks, network addresses, and security groups.

[0020] In some embodiments, for S101, before triggering automated destruction, the definition and registration of the custom resource (Cluster Destroy CRD) are completed in the Kubernetes cluster.

[0021] Specifically, the CRD configuration file is submitted via the Kubernetes API to specify the metadata specifications and spec fields (core parameter fields) for the custom resource Cluster Destroy. The metadata must include the resource group, resource version, and resource name. The spec field pre-defines key parameters required for automated destruction, including the target cluster's unique identifier (e.g., cluster-id:k8s-prod-01, used to locate the cluster to be destroyed), the data backup storage path (e.g., backup-path:s3: / / k8s-destroy-backup / prod-01, providing a path for subsequent backup steps), the traffic switching threshold (e.g., traffic-threshold:10QPS, defining when gateway blocking will be executed if traffic drops to this value), and the reconciliation alarm threshold (e.g., billing-alarm-threshold:1000, used for anomaly detection during resource reconciliation), ensuring that the custom resource can fully meet the configuration requirements for the destruction task.

[0022] Next, the CRD is registered with the Kubernetes cluster. After receiving the CRD configuration file, the Kubernetes API Server verifies the validity of the resource definition (such as field format and permission rules). If the verification is successful, the CRD is registered in the cluster's resource registry. At this point, the Kubernetes cluster recognizes ClusterDestroy as a legitimate resource type at the same level as Pods and Deployments, allowing subsequent creation, querying, and updating of specific resource instances of this type via the API. Simultaneously, default storage logic is bound to this resource, storing the data (including configuration parameters) of subsequently created ClusterDestroy resource instances in etcd, ensuring data persistence and accessibility by components within the cluster.

[0023] Preferably, in one embodiment, when it is necessary to destroy the target Kubernetes cluster, the user initiates a destruction request through the DevOps platform, and first verifies the permissions of the request initiator to avoid accidental destruction caused by unauthorized operations.

[0024] Specifically, the operator logs into the DevOps console, selects the target cluster to be destroyed on the cluster management page (matched by cluster name or ID), and the DevOps console forwards the destruction command request to the RBAC permission management module of the Kubernetes cluster, triggering the permission verification process.

[0025] After successful authentication, the DevOps console generates a Cluster Destroy resource instance based on the initial destruction command request and distributes it to the Kubernetes cluster, completing the transformation of the destruction command into a standardized resource instance.

[0026] Specifically, building a Cluster Destroy resource instance involves the DevOps console automatically filling in the preset spec field parameters of the CRD based on the cluster identifier to be destroyed in the initial destruction command. For example, based on the preset configuration of cluster k8s-prod-01, parameters such as cluster-id:k8s-prod-01 and backup-path are filled in. At the same time, a unique name (such as clusterdestroy-k8s-prod-01) and a tag (such as task-type:destroy,cluster:prod-01) are added to the resource instance to facilitate subsequent component identification and filtering. When a resource instance is deployed to the Kubernetes cluster, the DevOps console sends a request to the Kubernetes API Server via the Kubernetes Client SDK (such as GoClient) to create a ClusterDestroy resource instance. The request includes the complete resource instance configuration (including metadata and the spec field). After receiving the request, the API Server verifies the validity of the resource instance's fields (such as whether the spec field parameter conforms to the format defined by the CRD). If the verification is successful, the resource instance is stored in etcd, and a response indicating successful resource creation (including the unique ID of the resource instance) is returned to the DevOps console. At this point, the destruction command has been officially received by the Kubernetes cluster in the form of a custom resource instance.

[0027] In some embodiments, for S102, the Kubernetes metadata includes, for example, configuration information of all core resources in the cluster, including YAML configurations of native resources such as Deployment, Service, ConfigMap, Secret, PVC (Persistent Volume Declaration), and Namespace, as well as the definition and instance data of custom resources (such as ClusterDestroyCRD, middleware Operator-related resources). This type of data directly reflects the cluster resource topology and running configuration and is the core basis for subsequent data traceability. For database snapshots, for example, a full data snapshot is created for all business databases running in the cluster (such as relational databases like MySQL and PostgreSQL, and non-relational databases like MongoDB). This snapshot includes the database table structure, business data, and index information. For example, when MySQL executes a mysql dump, the database snapshot is generated in the form of a recoverable complete data packet. For container images, for example, focus on the images corresponding to all running business containers in the cluster, including image name, tag and image digest. Prioritize backing up local images that have not been pushed to public / private image repositories, or images that have been pushed but need to retain specific versions, to avoid being unable to trace back the business application version after subsequent destruction.

[0028] In this embodiment, object storage is taken as S3 as an example. Object storage access parameters are pre-configured in the backup execution component (such as a backup Pod in the cluster or a backup service associated with the DevOps platform). For example, this includes: Storage service address (such as the endpoint of S3 compatible storage); Authentication information (AccessKey and SecretKey) must be securely stored via Kubernetes Secret to avoid plaintext configuration. Target bucket and path planning: Create directories by cluster identifier (e.g., k8s-destroy-backup / prod-cluster-01 / 20240115-1430 / ), where prod-cluster-01 is the unique identifier of the cluster to be destroyed, and 20240115-1430 is the backup initiation time. This ensures that backup data from different clusters and at different times is stored separately for easy retrieval later.

[0029] In this embodiment, a differentiated backup strategy is adopted for different data formats and storage locations of Kubernetes metadata, database snapshots, and container images to ensure the integrity and recoverability of the backup data.

[0030] Specifically, for Kubernetes metadata backup, this involves both full export and structured storage; for example, using KubernetesClient tools (such as kubectl) or APIs to fully export the YAML configurations of all resources within the cluster by namespace. First, export the resources under the default Namespace (default, kube-system, kube-public, etc.) and the business Namespace (such as prod, test). The execution logic is to traverse all Namespaces and execute kubectlget [resource type] -n [Namespace] -oyaml on the Deployment, Service, and other resources under each Namespace. Then export cluster-level resources (such as Node, ClusterRole, CRD). These resources do not belong to a specific Namespace. Execute kubectlget [cluster-level resource type] -oyaml directly. Store all exported YAML files categorized by resource type / Namespace.

[0031] Optionally, the categorized metadata files are compressed and encrypted, and the encrypted compressed package is uploaded to a preset object storage path via S3SDK (such as AWSSDK for Python).

[0032] For database snapshot backups, a full snapshot is performed based on the database type. For example, taking MySQL as an example, firstly, for containerized MySQL deployments, enter the MySQLPod via kubectlexec and execute the FLUSHTABLESWITHREADLOCK command to temporarily disable database write operations and prevent data writing during the backup process from causing snapshot inconsistencies. After locking the table, execute the command `mysqldump -u [username] -p [password] --all-databases --single-transaction --quick --lock-tables=false>mysql-snapshot-[timestamp].sql` to export the full database data to an SQL file. The `--single-transaction` option ensures consistency for InnoDB engine tables, and `--quick` reduces memory usage. Compress and upload the SQL file or snapshot directory to the "database-snapshot" subdirectory of the object storage. After the upload is complete, unlock MySQL (execute UNLOCKTABLES) to restore normal database writing.

[0033] For container image backup, image information logging, and critical image push, for example, via kubectl getpods-A-ojsonpath='{range.items[ ]}{.spec.containers[ The command `.image}{"\n"}{end}` iterates through all container images of all Pods, obtains the full name (including repository address and tags) and summary of each image, and organizes them into a CSV image list, recording the Pod name and Namespace corresponding to each image. Upload the image files to the "image-backup" subdirectory of the object storage, and simultaneously upload the image list in CSV format to the same directory to ensure that the image files and the list correspond one-to-one for easy retrieval later.

[0034] In some embodiments, for S103, preferably, the service dependency directed graph is constructed based on OpenTelemetry (an open-source observability framework for generating, collecting and exporting telemetry data) link data, with services as nodes, service call relationships as edges, and the weight of the edge being the real-time request traffic of the current service.

[0035] Specifically, the trace data covers all business services and middleware (such as Kafka, Redis, and MySQL) within the cluster. Business services use instrumentation (such as integrating OpenTelemetrySDK into the application code) to encapsulate the request information of inter-service calls (including the caller service name, the callee service name, the request start / end time, the request ID, and QPS (queries per second)) into trace data. Middleware uses adapted exporters (such as KafkaExporter and RedisExporter) to also convert the interaction requests between business services and middleware (such as services sending messages to Kafka and reading data from Redis) into standardized trace data, ensuring that no trace data is missing. All trace data generated by services and middleware within the cluster is uniformly received and processed by OpenTelemetryCollector (the link data aggregation component). The Collector first cleans the raw trace data (filtering invalid request data, such as abnormal links that have timed out and have not responded) and standardizes it (unifying the trace format of different services / middleware into the OpenTelemetry standard format, which includes core fields such as TraceID, SpanID, and ParentSpanID). Then, it forwards the processed link data in batches to Tracing-Analyzer (the link analysis component) at a preset period (such as every 10 seconds). Based on the access link data, Tracing-Analyzer constructs a directed graph (G=(Service,Edge)) that reflects service call relationships and real-time traffic by defining nodes, edges, and assigning weights.

[0036] Specifically, the directed graph nodes (Services) are determined by extracting all caller and callee identifiers from the link data, deduplicating them, and using them as nodes in the directed graph. For example, there are two types of nodes: one is business service nodes, which are identified by the unique name of the service; the other is middleware nodes, which are identified by the middleware type and instance name. This ensures that each service / middleware involved in the call can find its corresponding node in the graph without any omissions. Define directed graph edges based on the call relationships in the link data. For example, if the link data shows that service A calls service B, then a directed edge is created in the graph from the service A node to the service B node; if it shows that service C calls middleware D, then a directed edge is created from the service C node to the middleware D node. At the same time, each edge is deduplicated (only one edge is retained for multiple link data with the same call relationship) to avoid edge redundancy. Assign weights (QPS) to edges. Extract the real-time QPS (queries per second) corresponding to each call relationship from the link data and use it as the weight of the corresponding directed edge. The weight assignment can intuitively reflect the real-time traffic size of each call link.

[0037] Based on the constructed directed graph of service dependencies, Tracing-Analyzer generates a destruction order queue Q that ensures safe destruction, following the principle of first cutting services with no incoming edges and then cutting convergence services. Figure 2 The diagram illustrates the process of generating a destruction order queue, which includes: S201 identifies services with no incoming edges and prioritizes their enqueueing. In the directed graph, nodes with zero incoming edges (i.e., no other service calls the service / middleware corresponding to this node) are selected. These services / middleware do not carry upstream dependencies, and their priority for destruction will not affect other services; they are the first priority in the queue. For example, if the "log-service" node in the directed graph has no incoming edges (no service calls it), then "log-service" is added to queue Q as the first element. Services are sorted by QPS from smallest to largest (the smaller the QPS, the smaller the impact of destruction on overall traffic), ensuring that low-impact services are destroyed first. S202: Delete queued nodes and associated edges, and iteratively filter secondary priority services. When a service with no incoming edges is queued, Tracing-Analyzer deletes these queued nodes from the directed graph, and simultaneously deletes all edges associated with these nodes (including outgoing edges originating from the node and incoming edges ending at the node). For example, if the queued "log-service" has an outgoing edge pointing to "kafka-prod-01", deleting the "log-service" node requires simultaneously deleting the edge "log-service→kafka-prod-01". After deletion, re-examine the directed graph. At this point, new services with no incoming edges may appear (e.g., if "order-service" originally had an incoming edge to "log-service", deleting "log-service" and if "order-service" has no other incoming edges, it becomes a new service with no incoming edges). Add these new services with no incoming edges to queue Q according to the above rules, and repeat this process until only "aggregation services / middleware" (nodes with ≥1 incoming edge) remain in the directed graph. S203, process the aggregation services / middleware and enqueue them. For the remaining aggregation services / middleware in the directed graph (i.e. nodes called by multiple upstream services), enqueue them in ascending order of the sum of edge weights. The sum of edge weights refers to the sum of the weights (QPS) of all incoming edges of the node. The smaller the sum, the less upstream traffic depends on the node, and the smaller the impact on the overall cluster when it is destroyed.

[0038] In some embodiments, for S104, in order to avoid service interruption or data inconsistency caused by continuous influx of external traffic into the cluster to be destroyed during the destruction process, traffic is redirected to other normal clusters through an external DOH (DNS-over-HTTPS).

[0039] Specifically, before issuing the command, the traffic migration mapping relationship of the cluster to be destroyed is obtained from the preset configuration. That is, the backup clusters (such as "k8s-prod-02" and "k8s-prod-03") corresponding to the cluster to be destroyed (such as "k8s-prod-01") are determined. At the same time, the traffic allocation rules are determined (such as using the "100% migration" strategy to switch all traffic originally pointing to the cluster to be destroyed to the backup cluster, or using the gradient migration strategy to switch in stages to avoid sudden traffic overload on the backup cluster). In addition, the core domain name information of the cluster to be destroyed (such as the business access domain names "api.example.com" and "web.example.com") is obtained. These domain names are the key location identifiers for DOH traffic switching.

[0040] According to the instruction format requirements of the DOH service, generate an instruction that includes the target domain name, a list of backup cluster IPs, migration strategy, and effective time. For example, the instruction content is "Migrate all DNS resolution records of the domain name api.example.com from the cluster IP to be destroyed, 10.10.1.100, to the backup cluster IPs 10.10.2.100 and 10.10.2.101. The instruction will take effect immediately after it is issued."

[0041] The traffic migration command is sent to the API interface of the external DOH service via HTTPS protocol. After receiving the command, the DOH service first verifies the legality of the command (including API key verification and target domain name ownership verification). After the verification is successful, it updates its own DNS resolution record, that is, it replaces the resolution address corresponding to the domain name of the cluster to be destroyed with the IP address of the backup cluster, and clears the cache of the original resolution record (to prevent the client from accessing the old IP because the cache has not expired).

[0042] After the traffic migration command is executed, the real-time traffic of the cluster to be destroyed needs to be continuously monitored to ensure that it drops to a preset threshold. Specifically, by accessing traffic monitoring components within the cluster (such as Prometheus and Grafana), the monitoring dimensions cover all ingress gateways in the cluster (such as NginxIngress), collecting the number of requests per second (QPS), the request source IP, and the request status code (such as 200, 404) for each gateway, to ensure that it can accurately reflect the actual influx of external traffic and eliminate the interference of inter-service call traffic within the cluster (only counting requests from outside the cluster); preset traffic monitoring thresholds (such as "QPS≤5"); and compare the actual QPS with the preset threshold after each round of monitoring.

[0043] When the traffic of the cluster to be destroyed drops to a preset threshold, the gateway configuration is modified to block inbound requests to prevent the remaining small amount of traffic from continuing to access the cluster and causing abnormal data operations. Preferably, the gateway blocking is implemented by calling the NginxIngress configuration interface and attaching the destruction flag header information to the returned response.

[0044] Specifically, determine the ingress gateway type of the cluster to be destroyed (taking NginxIngress as an example), obtain the gateway's configuration management interface. For NginxIngress, the configuration is stored in the Kubernetes ConfigMap resource (such as nginx-ingress-controller-config), so it is necessary to obtain the API operation permissions of the ConfigMap (such as modifying the ConfigMap through the Kubernetes API), and at the same time, identify the core configuration items that need to be modified (such as the request processing rules and response header configuration in the "server" block).

[0045] To generate a blocking configuration for NginxIngress that rejects all new requests and returns a destruction flag, for example, this includes: adding a global rule for "location / " in the ConfigMap, setting "return503ServiceTemporarilyUnavailable", rejecting all inbound requests and returning a 503 status code (informing the client that the service is temporarily unavailable); and adding the response header configuration "add_headerX-Destroy-Tokendestroy-20250115-1430;", using the custom header "X-Destroy-Token" to indicate that the reason for the current request being rejected is "cluster destruction", which facilitates subsequent troubleshooting (e.g., if the client reports a 503 error, this header information can be used to quickly locate the cause).

[0046] By calling the ConfigMap modification interface via the Kubernetes API, the generated blocking configuration is written to the target ConfigMap. After NginxIngressController detects the ConfigMap update, it will automatically reload the configuration (without restarting the controller, ensuring that the configuration takes effect without delay).

[0047] In some embodiments, for S105, preferably, the middleware shutdown includes performing Topic deletion on Kafka, performing cache cleanup and persistence shutdown on Redis, and performing table locking, data export, and persistent volume deletion on MySQL.

[0048] Based on the order of the middleware in the destruction order queue Q, the corresponding middleware's operation and maintenance interface is called one by one, and differentiated data cleanup and persistence shutdown operations are performed in combination with the middleware's data storage characteristics.

[0049] Specifically, if the first middleware instance to be taken offline in queue Q is a Kafka instance, the automated destruction system calls the KafkaOperator operation and maintenance interface to perform offline operations by adjusting configurations and deleting topics. For example, the specific process includes... Call the updateConfig interface of KafkaOperator to set the "delete.topic.enable" configuration item of the Kafka instance to be taken offline to "true"; after the interface is called, wait for the Kafka cluster configuration to be synchronized, and query the configuration value through the "getConfig" interface to confirm that "delete.topic.enable" has been updated to "true".

[0050] Call the `listTopics` interface of `KafkaOperator` to obtain a list of all Topics in the Kafka instance to be taken offline (e.g., [order-topic, log-topic, user-topic]). Call the `deleteTopic` interface to delete each Topic sequentially. The interface request must specify the Topic name and Kafka cluster identifier (to avoid accidentally deleting Topics from other clusters). After each Topic is deleted, use the `getTopicStatus` interface to query the Topic status to confirm that it has been removed from the Kafka cluster (status displays "Deleted") before executing the deletion of the next Topic, preventing interface overload caused by batch deletion.

[0051] When the queue reaches a Redis instance, the automated destruction system performs a full cache cleanup and disables persistence functionality through the Redis operation and maintenance interface (or RedisOperator interface). For example, the specific process includes: Call the Redis FLUSHALL interface (or the RedisOperator's flushAll interface) to clear all database cache data (including all key-value pairs) in the Redis instance. After the interface call, query the current number of keys in the Redis instance using the DBSIZE interface. If it returns "0", the cache cleanup is confirmed to be complete, preventing residual business data from consuming resources or causing data leakage.

[0052] Call the Redis "CONFIGSET" interface (or the RedisOperator "updatePersistence" interface) to modify the Redis persistence configuration. Set "appendonly" (AOF persistence) to "no" to disable AOF log writing; set the "save" configuration (RDB persistence trigger condition) to empty to prevent automatic generation of RDB snapshots; after modifying the configuration, use the "CONFIGGET" interface to query the "appendonly" and "save" configuration values ​​to confirm that the persistence function has been completely disabled, preventing the writing of persistent files when the Redis instance is shut down.

[0053] As the aggregation service in queue Q (a database depended on by multiple business services), MySQL's shutdown is executed according to the logic of ensuring data consistency, exporting and backing up data, and releasing storage resources. For example, it involves executing FLUSHTABLESWITHREADLOCK, mysqldump, and deleting the PVC. The specific process includes... Call the MySQL FLUSHTABLESWITHREADLOCK interface (or through the cloud database MySQL lockInstance operation and maintenance interface) to perform read locks on all tables in the MySQL instance, that is, prohibit any write operations (such as INSERT, UPDATE, DELETE), and only allow read operations, to ensure that the data is not modified during the subsequent data export process and to ensure the consistency of the exported data; after locking the tables; Call the mysqldump interface of MySQL (or the exportData interface of cloud database) to perform a full data export, that is, the exported content includes the table structure, data, indexes and stored procedures of all databases, the exported file format is SQL (to facilitate possible subsequent data recovery), and store the exported file to the preset object storage path (consistent with the storage path of the data backup stage in the aforementioned embodiment, such as the "database-snapshot" directory of the S3 bucket). Call the MySQL UNLOCKTABLES interface to unlock all tables and release database read / write restrictions; then call the Kubernetes API "deletePVC" interface (or the cloud provider's storage service "deleteVolume" interface) to delete the persistent volume (PVC) bound to the MySQL instance. If the PVC's reclamation policy is "Retain" (which retains storage data by default), it needs to be changed to "Delete" through the interface first to ensure that the underlying cloud disk resources (such as AWSEBS, Alibaba Cloud disks) are released synchronously when the PVC is deleted, avoiding storage resource residue; after the PVC is deleted, query through the "getPVCStatus" interface to confirm that the PVC status is "Terminating" and eventually becomes "Deleted", then the MySQL middleware is offline.

[0054] In some embodiments, for S106, by setting the terminationGracePeriodSeconds parameter and combining it with the service mesh listener termination signal, the instance is guaranteed to be released only after the existing requests are completed.

[0055] Specifically, first, configure a service termination grace period to allow time for processing existing requests. For example, set `terminationGracePeriodSeconds=300` for the Deployment. This utilizes Kubernetes' native termination grace period mechanism to provide sufficient time for the service to process received existing requests, preventing request loss due to forced termination. Specific steps include... Based on the generated destruction order queue Q, determine the business services that need to be taken offline (such as "user-service" and "order-service"). Then, query the Deployment resources corresponding to these services through the Kubernetes API (each service usually corresponds to a Deployment, which manages the Pod instances of the service) to obtain the complete configuration information of the Deployment (including the current number of Pods, container images, existing termination grace period settings, etc.). Call the Kubernetes API's Deployment update interface and set the `spec.template.spec.terminationGracePeriodSeconds` field of the target Deployment to 300 seconds. This parameter defines the maximum time Kubernetes waits for a Pod to stop automatically after sending a termination signal (SIGTERM) to it. If the original termination grace period configured for the service is less than 300 seconds (e.g., the default 30 seconds), the update can significantly extend the processing time for existing requests; if the original configuration is greater than or equal to 300 seconds, keep the original configuration unchanged to avoid excessively extending the destruction process time.

[0056] After configuring the termination grace period, the service mesh component listens for termination signals and actively rejects new connections to ensure that only existing requests are processed. For example, the specific process includes... Sending a SIGTERM signal to the Pod of the target service via the Kubernetes API (the first step in triggering the Pod termination process) will cause the servicemesh (such as Istio or Linkerd) to listen for this signal in real time as a Sidecar container deployed within the Pod. When the SIGTERM signal is detected, the servicemesh will immediately enter the mode of refusing new connections and will no longer accept new request forwarding from the service mesh. Servicemesh blocks new requests in two ways: First, it sends an instance offline notification to the service mesh control plane (such as IstioPilot). Upon receiving the notification, the control plane immediately removes the Pod instance from the service's load balancer pool, and subsequent new requests will no longer be scheduled to that Pod. Second, it directly intercepts new requests within the Pod and returns a "503 ServiceUnavailable" response to all new TCP connections or HTTP requests, explicitly informing the client that the current service instance is unavailable and redirecting the request to other normally running Pod instances (if they exist).

[0057] To prevent the registry center from marking offline service instances as available, causing new requests to be mistakenly connected through the service discovery mechanism, the instance is deregistered with the registry center via the PreStop hook. For example, the specific implementation includes... After Kubernetes sends a SIGTERM signal to a Pod, it automatically executes the PreStop hook script pre-defined in the Pod configuration (this script is embedded in the Pod template during service deployment and is associated with the registry's deregistration logic). The PreStop hook is triggered earlier than the actual termination of the Pod, ensuring that the deregistration operation is executed before all existing requests are processed, thus preventing the registry from retaining instance information. The PreStop hook script removes the service instance corresponding to the current Pod from the registry by calling the instance deregistration API of the registry center (such as Nacos, Eureka, Consul). The script carries the unique identifier of the service (such as service name "user-service", instance IP "10.244.1.5", and port "8080") to ensure that the registry center can accurately locate the instance to be deregistered. At the same time, the script carries the authentication information of the registry center (such as APIToken) to prevent unauthorized deregistration operations.

[0058] In some embodiments, for S107, preferably, calling the cloud vendor's API includes performing node emptying, deleting virtual machines, modifying cloud disk recycling policies, and releasing network resources.

[0059] Specifically, by calling cloud vendor resource list query APIs (such as ECS DescribeInstances and EBS DescribeVolumes), information on all target resources associated with the cluster to be destroyed is obtained. The dependencies between resources are then identified, clarifying the cloud disks (EBS volumes, cloud disks) mounted on each virtual machine (EC2 instance, ECS instance), the bound network addresses (public IP, elastic IP), and the security groups to which each network address belongs. Simultaneously, non-target resources are filtered using resource tags (such as "k8s-cluster:prod-01," consistent with the identifier of the cluster to be destroyed), generating a list of resources to be released. This list includes a unique ID for each resource (such as virtual machine ID, cloud disk ID, IP address, security group ID), resource name, and region, ensuring that subsequent API calls only target the intended resources and preventing the accidental deletion of other cluster resources. For releasing virtual machines via cloud vendor APIs, for example, using a virtual machine as an example, the process is executed in the order of Detach node, Drain, DeleteVM. First, preprocessing operations are completed for the virtual machine, and then deletion is performed via the API. This ensures that no business processes remain before the virtual machine is released. For example, the specific process includes... The virtual machine node Detach (removes from the cluster) calls the Nodecordon interface of the Kubernetes API to mark the Kubernetes Node corresponding to the virtual machine to be released as unschedulable (SchedulingDisabled) to prevent new Pods from being scheduled to that node. Then, it calls the cloud vendor's virtual machine status query API (such as DescribeInstances) to confirm that the virtual machine is communicating normally with the Kubernetes cluster before performing the Detach operation. For virtual machines created through cloud vendor container services (such as Alibaba Cloud ACK, AWS EKS), it calls the "RemoveNodeFromCluster" interface of the container service API to remove the virtual machine from the Kubernetes cluster, disconnecting it from the cluster control plane and avoiding the impact on normal nodes in the cluster when deleting virtual machines later.

[0060] The virtual machine node drain (empty existing Pods) calls the Kubernetes API's Nnoderain interface to drain all existing Pods on the virtual machine to be released. The drain operation first sends a SIGTERM signal to the Pods to trigger graceful shutdown. After all Pods are terminated or the termination grace period is reached, the remaining Pods are forcibly deleted. During this process, the number of Pods on the node is monitored in real time through the GetPods interface until the number of Pods is 0, confirming that the node has been drained and there is no residual business load.

[0061] After the nodes are drained, call the cloud provider's virtual machine deletion API (such as ECSDeleteInstance or EC2TerminateInstances). Specify the unique ID of the virtual machine to be deleted (e.g., "i-abc123") in the API request and set deletion protection parameters (e.g., "ForceStop=true" to forcibly terminate running virtual machines). Some cloud providers support batch deletion; multiple virtual machine IDs to be released can be passed to the API in batches to improve efficiency, but it is necessary to ensure that each virtual machine has completed the drain operation. After the API call, monitor the virtual machine status through the virtual machine status query API until the status changes to "Deleted" (e.g., Alibaba Cloud "Deleted" or AWS "Terminated") to confirm that the virtual machine release is complete. When releasing cloud disks by calling cloud vendor APIs, for example, adjusting the cloud disk recycling policy before performing deletion, ensuring that the cloud disk is released without any residue when released with the virtual machine or independently, the specific process is as follows: Call the cloud vendor's cloud disk list query API (such as EBS DescribeVolumes, ECS DescribeDisks) to filter all cloud disks (including system disks and data disks) mounted on the virtual machine to be released based on the virtual machine ID; at the same time, query the recycling policy of each cloud disk (such as AWS EBS's "Delete on Termination" and Alibaba Cloud ECS's "Delete with instance"). If the policy is "Retain", it needs to be changed to "Delete" to avoid the cloud disk remaining after the virtual machine is deleted; For cloud disks with a "Retain" recycling policy, call the cloud vendor's "Cloud Disk Policy Update API" (such as EC2ModifyVolumeAttribute, ECSModifyDiskAttribute) to change their recycling policy to "Delete". For example, when Alibaba Cloud ECS calls ModifyDiskAttribute, set "DeleteWithInstance=true"; when AWS EC2 calls ModifyVolumeAttribute, set "DeleteOnTermination=true". For cloud disks that are deleted along with the virtual machine, if the virtual machine has been successfully deleted, the cloud disk will be automatically released along with the virtual machine. In this case, you only need to check the cloud disk list API to confirm that the cloud disk no longer exists, and there is no need to call the delete API separately. For independently mounted cloud disks (not automatically deleted with the virtual machine), call the cloud vendor's cloud disk deletion API (such as EBSDeleteVolume, ECSDeleteDisk), specify the unique ID of the cloud disk (such as "vol-xyz789"), and set the forced deletion parameter (such as "Force=true", to force deletion regardless of the cloud disk's mounting status).

[0062] For example, when calling cloud vendor APIs to release network addresses (public IPs / elastic IPs), network addresses (such as elastic IPs and public IPs) are critical resources for virtual machines to access the external network. Deleting these addresses via APIs after releasing them from the virtual machine or cloud disk avoids wasting these address resources. The specific process is as follows: Call the cloud vendor's network address query API (such as EC2DescribeAddresses, ECSDescribeEipAddresses), filter by resource tag (such as "k8s-cluster:prod-01") or associated virtual machine ID (deleted virtual machine ID), obtain the list of network addresses to be released, and record the unique ID (such as Elastic IPID "eip-123456"), IP address (such as "103.XX.XX.XX") and association status (such as "unbound" or "associated") of each address; If the network address is still in an associated state (e.g., it was not automatically unbound when the virtual machine was deleted), call the cloud vendor's network address unbinding API (e.g., EC2DisassociateAddress, ECSUnassociateEipAddress), specify the network address ID and the associated resource ID (e.g., the ID of the deleted virtual machine), and remove the binding relationship between the address and the resource; after unbinding, use the network address query API to confirm that the address status has changed to unbound, ensuring that the address can be deleted normally; For unbound network addresses, call the cloud provider's network address deletion API (such as EC2ReleaseAddress, ECSReleaseEipAddress), specifying the network address ID in the API request; some cloud providers have overdue payment protection for Elastic IPs, so you need to confirm that the address has no overdue payments before performing the deletion.

[0063] For example, when calling a cloud vendor's API to release a security group (including rule cleanup), a security group is a network access control boundary for cloud resources. After other resources are released, the security group and its rules need to be deleted to prevent useless security groups from consuming quotas. For example, the specific process is as follows: Call the cloud vendor's security group query API (such as EC2DescribeSecurityGroups, ECSDescribeSecurityGroups) to filter by resource tags (such as "k8s-cluster:prod-01") to obtain a list of security groups to be released, and record the unique ID (such as "sg-789abc"), name and associated resources (such as virtual machines, cloud disks, network addresses) of each security group; at the same time, call the security group associated resource query API (such as DescribeSecurityGroupInstances) to confirm that the security group has no associated active resources (all associated resources have been deleted) to avoid failure when deleting the security group due to the existence of associated resources; Some cloud vendors require that inbound / outbound rules be cleared before deleting a security group. In this case, you need to call the security group rule query API (such as DescribeSecurityGroupRules) to get all rule IDs of the security group (such as "sgr-xyz123"); then call the security group rule deletion API (such as DeleteSecurityGroupRules) to delete all rules in batches or one by one to ensure that no rules remain in the security group. Once the security group has no associated resources and the rules have been cleaned up, call the cloud vendor's security group deletion API (such as EC2DeleteSecurityGroup or ECSDeleteSecurityGroup) and specify the unique ID of the security group. After the API call, monitor the security group status through the security group query API until the status changes to "deleted" or disappears from the list, confirming that the security group has been released.

[0064] Preferably, in some embodiments, the method further includes reconciling the released resources, verifying the differences between the billing data and the local resource list, and triggering an alarm when an anomaly is detected.

[0065] The core of the reconciliation process is data comparison. First, obtain the actual billing data from the cloud vendor (reflecting actual resource consumption) and the local resource list from the system side (reflecting planned resource release). Ensure that the two types of data are complete, accurate, and consistent in time dimension. For example, the specific operation is as follows: Specifically, for example, the Audit-Reconcile component retrieves cloud billing data for the most recent 24 hours. This component calls the billing query API provided by the cloud vendor (such as Alibaba Cloud's "CostManagement" API or AWS's "CostExplorer" API), specifying the unique identifier of the cluster to be destroyed (such as the resource tag "k8s-cluster:prod-01"), and retrieves all resource billing data related to that cluster within the last 24 hours. The billing data typically includes: resource type (such as virtual machine, cloud disk, elastic IP, security group), unique resource ID (such as ECS instance ID "i-abc123", cloud disk ID "vol-xyz789"), billing duration, billing amount, resource status (such as "running" or "released"), and billing generation timestamp. It covers all resource types to be reconciled and can be associated with a local list via resource ID.

[0066] Optionally, due to differences in billing formats among different cloud vendors (such as different field names and data units), the Audit-Reconcile component cleans the raw billing data pulled, for example, by filtering billing records that are irrelevant to the cluster to be destroyed (such as resource billing for other clusters), completing missing fields (such as mapping "resource name" to "resource unique ID"), and unifying the data format (such as unifying the billing amount unit to "yuan" and the timestamp to "yyyy-MM-ddHH:mm:ss"), and finally generating a standardized cloud billing data table; The local resource list is generated in real time during the resource release phase of automated destruction. It contains two types of core data: first, an initial list of resources to be released (cluster-related resources queried through the cloud vendor's API before destruction, recording resource type, unique ID, and planned release time); second, resource release result records (after each resource is released, the actual release time, release status (success / failure), and API response result are recorded). The two types of data are merged to form a complete local resource release list, ensuring that all resources that should be released are covered. After the data preparation is complete, the Audit-Reconcile component performs a two-way comparison: on the one hand, it verifies whether the resources that have been marked for release locally are not billed in the bill (confirming that the resources have been released); on the other hand, it verifies whether the resources that are still billed in the bill are not marked for release in the local list (finding unreleased residual resources). After completing the two-way comparison, the Audit-Reconcile component summarizes all marked differences and performs preliminary screening to exclude false differences caused by cloud vendor billing delays (such as resources that have just been released and billing data has not yet been updated; usually, you need to wait 10-30 minutes and then query and confirm again), and retains the real differences (such as residual resources that are still being billed 1 hour after release and have not been included in the plan). The Audit-Reconcile component calculates the total amount of unmatched billing for the filtered real discrepancies, including two parts: first, the residual amount that has been released locally but is still billed (accumulated based on the real-time billing amount of the resource in the bill); second, the residual amount that has been billed but not released locally (accumulated based on the current billing amount of the resource), ultimately yielding the total amount of unmatched billing.

[0067] As an example, the default alarm threshold is set to >1000 unmatched bills. If the total unmatched billing amount is ≤1000 yuan, it may be due to a minor delay in the cloud vendor's billing or a small amount of residual test resources. No alarm needs to be triggered, but the difference should be recorded in the subsequent reconciliation report for the operation and maintenance personnel to view. If the total unmatched billing amount exceeds 1000 yuan, it indicates that there are a large number of unreleased resources or high-value resources remaining (such as multiple virtual machines continuously billed), and an alarm needs to be triggered.

[0068] Optionally, regardless of whether an alarm is triggered, the Audit-Reconcile component must generate a standardized reconciliation report. As an example, the report contains complete reconciliation information, including but not limited to: Basic reconciliation information includes: cluster identifier to be destroyed, reconciliation time range (last 24 hours), Audit-Reconcile component version, bill retrieval time, and local resource list update time. Data comparison results include: cloud billing data overview (total number of records, number of resource types involved, total billing amount), local resource list overview (total number of records, number of successful releases, number of failed releases), number of items that passed verification, number of items with discrepancies, and total unmatched billing amount. Details of the differences: List all differences, including resource ID, resource type, billing status, local release status, residual billing amount, and preliminary analysis of the reasons for the differences; Supporting materials include screenshots of the cloud vendor's billing query API response (to prove the authenticity of the billing data), screenshots of the API call logs for local resource release (to prove that the release operation has been executed), and the SHA256 checksum of the backup package (the backup package in the data backup process, ensuring backup integrity and traceability).

[0069] Figure 3 An automated destruction device 300 for cloud-native Kubernetes clusters is shown. This device embodiment is similar to... Figure 1 Corresponding to the method embodiment shown, this device can be specifically applied to various electronic devices, specifically including, Trigger module 301 is used to respond to a received destruction command and trigger automated destruction based on preset custom resources; Backup module 302 is used to back up Kubernetes metadata, database snapshots, and container images to object storage; The destruction order queue construction module 303 is used to construct a service dependency directed graph based on the link data collected by distributed tracing, and generate a destruction order queue according to the service call relationship in the directed graph; The external traffic switching module 304 is used to issue traffic migration instructions to switch external traffic to other clusters, and to block ingress requests through gateway configuration when the traffic drops to a preset threshold. The middleware offline module 305 is used to sequentially call the operation and maintenance interfaces of various middleware according to the destruction order queue, perform data cleanup and persistence shutdown, and realize the middleware offline. The service shutdown control module 306 is used to achieve a smooth exit by setting a termination grace period, rejecting new connections, and deregistering the registry instance. The resource release module 307 is used to call the cloud vendor's API to release resources in sequence. The resources include at least virtual machines, cloud disks, network addresses, and security groups.

[0070] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0071] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and smart bands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0072] Figure 4 The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 400 includes a central processing unit 401, which can perform various appropriate actions and processes based on a program stored in a read-only memory 402 or a program loaded from a storage portion 408 into a random access memory 403. Various programs and data required for system operation are also stored in the RAM 403. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output interface 405 is also connected to the bus 404.

[0073] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 407 including cathode ray tubes, liquid crystal displays, LED displays, OLED displays, etc., and speakers, etc.; a storage section 408 including one or more computer-readable media such as hard disks, optical disks, magnetic disks, semiconductor memory, etc.; and a communication section 409 including network interface cards such as LAN cards, modems, etc. The communication section 409 performs communication processing via a network such as the Internet.

[0074] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 401, it performs the functions defined in the methods of this application.

[0075] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0076] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. In this document, a computer-readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0077] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0078] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0079] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0080] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0081] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0082] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or page components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0083] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0085] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0086] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0087] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. An automated destruction method for cloud-native Kubernetes clusters, characterized in that, The methods and steps include the following: In response to receiving a destruction command, it triggers automated destruction based on preset custom resources; Back up Kubernetes metadata, database snapshots, and container images to object storage; A service dependency directed graph is constructed based on the link data collected by distributed tracing, and a destruction order queue is generated according to the service call relationship in the directed graph. Issue traffic migration instructions to switch external traffic to other clusters, and block ingress requests through gateway configuration when traffic drops to a preset threshold; The operation and maintenance interfaces of various middlewares are called sequentially according to the destruction order queue to perform data cleanup and persistence shutdown, thereby taking the middleware offline. Control service shutdown by setting a termination grace period, rejecting new connections, and deregistering registry instances to achieve a smooth exit; Call the cloud vendor's API to release resources in sequence. These resources include at least virtual machines, cloud disks, network addresses, and security groups.

2. The automated destruction method for cloud-native Kubernetes clusters according to claim 1, characterized in that, The service dependency directed graph is constructed based on OpenTelemetry link data, with services as nodes, inter-service call relationships as edges, and the weight of the edge being the real-time request traffic of the current service.

3. The automated destruction method for cloud-native Kubernetes clusters according to claim 1, characterized in that, Gateway blocking is achieved by calling the NginxIngress configuration interface and attaching a destruction header to the returned response.

4. The automated destruction method for cloud-native Kubernetes clusters according to claim 1, characterized in that, The middleware shutdown includes performing Topic deletion on Kafka, cache cleanup and persistence shutdown on Redis, and table locking, data export, and persistent volume deletion on MySQL.

5. The automated destruction method for cloud-native Kubernetes clusters according to claim 1, characterized in that, Calling cloud vendor APIs includes performing node emptying, deleting virtual machines, modifying cloud disk reclamation policies, and releasing network resources.

6. The automated destruction method for cloud-native Kubernetes clusters according to claim 1, characterized in that, It also includes, Reconcile released resources, verify the discrepancies between the billing data and the local resource list, and trigger an alarm when an anomaly is detected.

7. The automated destruction method for cloud-native Kubernetes clusters according to claim 1, characterized in that, The process of generating a destruction order queue includes identifying services without incoming edges and prioritizing their entry into the queue, deleting queued nodes and associated edges and iteratively filtering services with lower priority, and aggregating services / middleware and adding them to the queue.

8. An automated destruction device for cloud-native Kubernetes clusters, characterized in that, include: The trigger module is used to respond to received destruction commands and trigger automated destruction based on preset custom resources; The backup module is used to back up Kubernetes metadata, database snapshots, and container images to object storage; The destruction order queue construction module is used to build a service dependency directed graph based on the link data collected by distributed tracing, and generate a destruction order queue according to the service call relationship in the directed graph; The external traffic switching module is used to issue traffic migration instructions to switch external traffic to other clusters, and to block ingress requests through gateway configuration when the traffic drops to a preset threshold. The middleware offline module is used to sequentially call the operation and maintenance interfaces of various middleware according to the destruction order queue, perform data cleanup and persistence shutdown, and realize the middleware offline. The service shutdown control module is used to achieve a smooth exit by setting a termination grace period, rejecting new connections, and deregistering the registry instance. The resource release module is used to call the cloud vendor's API to release resources sequentially. The resources include at least virtual machines, cloud disks, network addresses, and security groups.

9. An electronic device, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as described in any one of claims 1-7.

11. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7.

Images