Kubernetes-based edge collaborative publishing method and device, and medium

Abstract

The invention discloses a Kubernetes-based edge collaborative publishing method and device and a medium, and the method comprises the steps: receiving an application deployment parameter submitted by a user through an abstraction interaction layer at a cloud center management and control end, and matching a pre-packaged basic mirror image and a starting script from a standardized environment library according to a running environment template to generate a resource declaration file; packaging the resource declaration file and a user code medium into a versioned application medium package, storing the versioned application medium package into a cloud center unified warehouse, and issuing an upgrading instruction to a target edge node through a task scheduling engine; actively polling the cloud center at the target edge node through a node agent to obtain an upgrading instruction, and pulling an incremental medium packet from a unified warehouse of the cloud center to a local cache warehouse according to the upgrading instruction; and calling a pre-integrated standardized environment engine to load a basic mirror image and a starting script in the target version medium of the incremental medium package, executing offline containerization deployment, and collecting a container running state in real time and synchronizing the container running state to a cloud center.

Description

Technical Field

[0001] This application relates to the field of cloud computing and containerized application deployment technology, and in particular to edge collaborative deployment methods, devices and media based on Kubernetes. Background Technology

[0002] In the fields of cloud computing and containerization, Kubernetes has become a core platform for enterprise application deployment, but significant technical bottlenecks still exist in multi-cluster management scenarios. Traditional solutions rely on passive connection modes (such as public network exposure or VPN traversal), which are difficult to adapt to environments with strict network isolation, such as private clouds and government clouds. Edge nodes cannot establish direct communication with the cloud center due to firewall policies or physical isolation restrictions, resulting in the failure of cross-cluster resource collaborative management. Although existing tools attempt to alleviate connectivity issues through reverse proxies or customized consoles, they do not address underlying architectural flaws: when network traversal capabilities are insufficient, proactive management and real-time scheduling between clusters cannot be achieved, hindering application distribution efficiency in multi-cloud / hybrid cloud scenarios.

[0003] Furthermore, the high complexity of the Kubernetes native technology stack raises the operational threshold. Application deployment requires manually writing YAML resource declaration files and manually configuring objects such as Deployment, Service, and Ingress, which is not only cumbersome but also prone to human error leading to environmental discrepancies. Although some management platforms provide graphical interfaces, their functionality is limited to basic resource monitoring and fails to translate the underlying APIs into business-level operation interfaces. Developers still need a deep understanding of professional concepts such as Pod scheduling and probe detection, resulting in high training costs and technical obstacles for small and medium-sized enterprises when implementing containerization technologies. Summary of the Invention

[0004] This application provides an edge collaborative deployment method, device, and medium based on Kubernetes to solve the above-mentioned technical problems.

[0005] On the one hand, embodiments of this application provide an edge collaborative deployment method based on Kubernetes, including:

[0006] The cloud center management terminal receives application deployment parameters submitted by users through an abstract interaction layer, and matches the pre-packaged base image and startup script from the standardized environment library according to the runtime environment template in the application deployment parameters to generate a resource declaration file.

[0007] The resource declaration file and user code media are packaged into a versioned application media package, which is then stored in the unified cloud repository. An upgrade command is then issued to the target edge node through the task scheduling engine. The upgrade command includes the application identifier and the target version number.

[0008] The target edge node actively polls the cloud center through the node agent to obtain the upgrade instruction, and pulls the incremental media package from the unified warehouse of the cloud center to the local cache warehouse according to the upgrade instruction;

[0009] The pre-integrated standardized environment engine is invoked to load the base image and startup script in the target version media of the incremental media package, perform offline containerized deployment, and collect the container running status in real time and synchronize it to the cloud center.

[0010] In one implementation of this application, matching a pre-packaged base image and startup script from a standardized environment library based on the runtime environment template in the application deployment parameters specifically includes:

[0011] Receive the developer's technology stack selection instruction, and match the preset versioned base image template according to the selection instruction;

[0012] Dynamically generate a Dockerfile containing component dependencies and a container startup script, and inject middleware connection parameters into the application container via environment variables.

[0013] In one implementation of this application, generating a resource declaration file specifically includes:

[0014] Map the application name in the application deployment parameters to a combined Deployment and Service tag;

[0015] Convert single-port or multi-port declarations into Service port mapping rules and Ingress routing configurations;

[0016] Based on the preset health check template, automatically fill in the Liveness Probe detection path or Readiness Probe detection path;

[0017] Convert the CPU / memory range of the graphical settings to the container's Requests or Limits parameters.

[0018] In one implementation of this application, before the target edge node actively polls the cloud center to obtain the upgrade instruction through a node agent, the method further includes:

[0019] When the target edge node starts up, it loads a pre-installed X.509 certificate, carrying the node hardware fingerprint and certificate signature, and initiates a handshake request to the node trust unit of the cloud center management terminal; the certificate includes a unique node identifier and validity information.

[0020] Receive the access token and session key issued by the cloud center management terminal to establish an encrypted communication channel based on TLS 1.3;

[0021] Maintain heartbeat connection and periodically synchronize node resource usage; automatically attempt to reconnect when connection is interrupted.

[0022] In one implementation of this application, the target edge node actively polls the cloud center through a node agent to obtain the upgrade instruction, and pulls incremental media packages from the unified repository of the cloud center to the local cache repository according to the upgrade instruction, specifically including:

[0023] The target edge node connects to the cloud center through a node proxy, establishes a secure channel through two-way TLS authentication, and polls the task queue of the cloud center based on the secure channel to obtain upgrade instructions;

[0024] The node agent sends a difference analysis request to the cloud center so that the task scheduling engine can check whether the target version medium exists in the local cache repository according to the target version number in the upgrade instruction.

[0025] If not, a segmented download request is initiated to the cloud center, and the image layer data is transmitted in segments using a breakpoint resume mechanism, with verification performed after each segment is transmitted.

[0026] After all chunks have been transferred, the image layer is reassembled locally, and after the overall hash value is successfully verified, the locally reassembled incremental image is written to the local cache repository.

[0027] In one implementation of this application, offline containerized deployment is performed, specifically including:

[0028] The incremental media package in the local cache repository is decompressed to the specified directory, and the environment variables and configuration files are loaded through the preset startup script;

[0029] The container process is started as a non-root user, and the default CPU / memory range is set according to the environment template type.

[0030] In one implementation of this application, the real-time collection of container running status specifically includes:

[0031] Collect the container's standard output logs, store the logs in a structured manner, and associate them with the corresponding application version and node information;

[0032] Real-time collection of container CPU / memory usage, and triggering a tiered alarm strategy to send alarm notifications to preset contacts when resource usage continues to exceed a preset threshold;

[0033] Record container lifecycle events and establish a secure remote debugging channel for the container via the WebShell protocol, allowing authorized users to directly enter the container for diagnostic operations; the lifecycle events include startup, stop, restart, and abnormal exit.

[0034] In one implementation of this application, it further includes:

[0035] The system receives a rollback command from the cloud center and stops all instances of the currently running version, while retaining the media cache of the most recent N versions; the rollback command specifies the target rollback version identifier.

[0036] Load historical version media from the local cache repository and verify the integrity and signature of the historical version media;

[0037] Recreate the historical version environment unit according to the original application deployment parameters, keep the resource configuration unchanged, and synchronize the rollback completion status to the cloud center management terminal to update the node task execution records.

[0038] On the other hand, embodiments of this application also provide an edge collaborative deployment device based on Kubernetes, the device comprising:

[0039] At least one processor;

[0040] And, a memory communicatively connected to the at least one processor;

[0041] The memory stores instructions that can be executed by the at least one processor, which enable the at least one processor to perform the Kubernetes-based edge collaborative deployment method described above.

[0042] On the other hand, this application also provides a non-volatile computer storage medium storing computer-executable instructions, which, when executed, implement the Kubernetes-based edge collaborative deployment method described above.

[0043] This application provides an edge collaborative deployment method, device, and medium based on Kubernetes, which has at least the following beneficial effects:

[0044] By proactively establishing a bidirectional TLS secure channel through node proxies, edge nodes can actively connect to the cloud center. This enables cross-cluster communication in an isolated environment without opening firewall inbound ports, avoiding network policy configuration conflicts and ensuring real-time command issuance and state synchronization. Based on an abstract interaction layer, resource declaration files are automatically generated, directly converting application parameters input by developers into Kubernetes native objects such as Deployment / Service. This eliminates the tedious process of manually writing YAML files and debugging APIs, reducing deployment and configuration time and significantly improving development efficiency. Standardized environment libraries pre-package base images and startup scripts, ensuring that the runtime environment loaded by edge nodes is strictly consistent with that of the cloud center. Edge nodes call the pre-integrated standardized environment engine to perform offline containerized deployment, independently completing image decompression, configuration mounting, and container startup operations without continuous connection to the cloud center. Attached Figure Description

[0045] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0046] Figure 1 A flowchart illustrating the Kubernetes-based edge collaborative deployment method provided in this application embodiment;

[0047] Figure 2 This is a schematic diagram of the internal structure of a Kubernetes-based edge collaborative publishing device provided in an embodiment of this application. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0050] Figure 1 This is a flowchart illustrating the Kubernetes-based edge collaborative deployment method provided in an embodiment of this application.

[0051] The analysis method involved in the embodiments of this application can be implemented by a terminal device or a server, and this application does not impose any special limitations on it. For ease of understanding and description, the following embodiments are all described in detail using a server as an example.

[0052] It should be noted that the server can be a single device or a system composed of multiple devices, i.e., a distributed server. This application does not make any specific limitations on this.

[0053] like Figure 1 As shown in the embodiments of this application, the edge collaborative deployment method based on Kubernetes includes:

[0054] Step 101: Receive application deployment parameters submitted by users through the abstract interaction layer at the cloud center management terminal, and match the pre-packaged base image and startup script from the standardized environment library according to the runtime environment template in the application deployment parameters to generate a resource declaration file.

[0055] In this embodiment, receiving the developer's technology stack selection instruction refers to obtaining the user's technology stack configuration requirements for the application's runtime environment through a visual interface. It is understood that this technology stack selection instruction includes the basic components required for application operation and their version information, such as Java version, web server type, and database driver. For example, when the developer selects the "Spring Boot 2.7 + MySQL 8.0" combination, the system automatically recognizes this as a typical technology stack configuration for a Java application and a relational database.

[0056] It's important to note that the pre-built versioned base image templates are standardized environment units that have undergone rigorous testing and verification. Specifically, each template employs an immutable image design, comprising a base operating system layer, a runtime environment layer, and a pre-configured tools layer. This layered design allows different versions of the environment templates to share the base layer, significantly reducing storage space usage. For example, the "JDK17+Tomcat9" template and the "JDK17+Tomcat10" template can share the same JDK17 base layer, with the web server version differing only at the top layer.

[0057] Dynamically generating a Dockerfile that includes component dependencies refers to the process of automatically building a container image description file based on the selected instructions according to the technology stack. It's important to note that the system maintains a component dependency graph, which can intelligently resolve compatibility constraints between components. For example, when a user selects PostgreSQL 14 as the database, the system will automatically add the corresponding JDBC driver installation instructions to the Dockerfile and set the correct classpath. This automated process eliminates version conflicts that may occur with manual configuration.

[0058] Specifically, the implementation of injecting middleware connection parameters into the application container via environment variables employs an environment-aware design. Understandably, the system analyzes configuration placeholders in the application code, such as `${DB_URL}`, and dynamically injects the actual connection information when the container starts. This design aligns closely with the Twelve Factors of Applications principle, achieving a complete separation of configuration and code. For example, sensitive information such as database connection strings and cache server addresses are not hard-coded into the application package but are provided at runtime via environment variables, improving both security and environmental adaptability.

[0059] In this embodiment, the application name is mapped to a combined label for Deployment and Service, employing a label consistency guarantee mechanism. The system generates a unique identifier for each application and ensures that this identifier appears simultaneously in the Deployment's podTemplate and the Service's selector. For example, the application order-service will be uniformly labeled as "app.kubernetes.io / name=order-service". This standardized labeling strategy enables Kubernetes to correctly associate the various components of the application.

[0060] It's worth noting that converting single-port or multi-port declarations into Service port mapping rules and Ingress routing configurations automates network abstraction. Specifically, the system automatically generates corresponding Kubernetes network resources based on user-defined port types (such as HTTP, TCP, and UDP). For example, when a user opens port 8080 as an HTTP service, the system not only creates the corresponding Service port mapping but also automatically configures Ingress rules, including advanced features like path rewriting and TLS termination. This design allows developers to implement complex service exposure requirements without needing in-depth knowledge of the Kubernetes network model.

[0061] The Liveness Probe or Readiness Probe detection paths are automatically populated based on pre-defined health check templates using a health check strategy library. For example, for Spring Boot applications, the system defaults to configuring " / actuator / health" as the health check endpoint; for Node.js applications, it uses " / health" as the default path. It should be noted that each check template predefines reasonable timeout periods, intervals, and failure thresholds. These parameters have been validated in production environments and accurately reflect the actual health status of the application.

[0062] Specifically, the intelligent conversion of resource quotas is achieved by translating the CPU / memory ranges set graphically into container Requests or Limits parameters. Understandably, the system provides differentiated default value suggestions based on application type; for example, AI inference services will receive more GPU resource quotas, while web applications will prioritize CPU and memory configurations. This conversion not only considers technical parameters but also incorporates resource optimization algorithms to ensure that cluster resource utilization is improved while meeting performance requirements. For instance, when a user sets a "medium" load level, the system automatically calculates the corresponding Requests and Limits values ​​and prioritizes resource allocation for critical business operations when resources are scarce.

[0063] Step 102: Package the resource declaration file and user code media into a versioned application media package, store the versioned application media package in the unified repository of the cloud center, and issue upgrade instructions to the target edge nodes through the task scheduling engine; the upgrade instructions include the application identifier and the target version number.

[0064] In this embodiment, the versioned application media package adopts a layered storage structure design. This structure includes a metadata layer, a configuration layer, and a code layer, enabling efficient organization and storage of application components. For example, the system uses a differential construction mechanism, packaging only the changed content through file hash comparison. It should be noted that this design significantly reduces the media package size, making it particularly suitable for application scenarios with frequent updates.

[0065] The cloud center's unified repository employs a content-addressable storage mechanism, where each file is uniquely identified by a cryptographic hash value. This design avoids duplicate storage while ensuring the immutability of the content. It's worth noting that the task scheduling engine selects matching target nodes based on edge node tags, generating upgrade instructions containing the application ID and target version number. This tag-matching mechanism enables precise application distribution, meeting the differentiated deployment needs of various edge nodes.

[0066] In this embodiment, receiving the rollback command from the cloud center is achieved through the command processing module of the node agent. It is understood that the rollback command is encapsulated in JSON format, containing key fields such as targetVersion (target rollback version), rollbackReason (rollback reason code), and timestamp (command generation timestamp). For example, when the cloud center detects a serious failure in a new version of the application, the operations console generates a rollback command and sends it to the target edge node through an established TLS secure channel. It should be noted that this command transmission employs at-least-once reliable transmission semantics to ensure that the command is ultimately delivered even under network fluctuations.

[0067] Specifically, the process of stopping all instances of the currently running version employs a graceful termination strategy. In this embodiment, the node agent first sends a stop request to the Kubernetes API, triggering a pre-defined preStop hook to perform cleanup operations, and then forcibly terminates the container after existing requests have been processed. This design avoids request interruptions or data inconsistencies during rollback. For example, for stateful services such as database applications, the system ensures that the current transaction is completed before stopping the instance. It should be noted that all stopped instances enter a "stopped but retained" state, with the retention time configured according to a policy, such as a default retention of 2 hours, to provide a context for possible fault diagnosis.

[0068] In this embodiment, retaining the media cache of the most recent N versions is achieved through intelligent cache management using a version garbage collector (VersionGC). It is understood that the value of N is dynamically adjusted based on the application type; critical business systems retain more versions (e.g., 5), while ordinary applications retain fewer versions (e.g., 3). For example, cache cleanup uses the LRU (Least Recently Used) algorithm, but ensures that at least one stable version is retained as a rollback baseline. It should be noted that the media cache not only includes the application package itself but also saves the corresponding deployment parameters and runtime logs, forming a complete version snapshot. This design makes rollback not only a code-level restoration but also a restoration of the complete runtime environment.

[0069] Specifically, the process of loading historical version media from the local cache repository employs a Content-Addressable Storage (CAS) mechanism. Understandably, each version media package is uniquely identified by a SHA-256 hash value and stored in / cache / repo / <hash>In the isolated directory / . For example, during loading, the system first checks the integrity flag file of the target version directory to verify that all shards are complete and usable. It should be noted that for container images using tiered storage, the system loads each layer in parallel, using memory mapping technology to accelerate the reading of large files. During the loading process, checksums are calculated in real time and compared with the metadata in the version manifest to ensure that the media has not been tampered with.

[0070] In this embodiment, a dual verification mechanism is employed to verify the integrity and signature of historical version media. Integrity verification is achieved by comparing the hash value of the actual file with the record in the version manifest, while digital signature verification uses a certificate issued by the cloud center. For example, the system maintains a trusted certificate chain, and only media packages signed with a valid private key can pass verification. It should be noted that the verification process is conducted in an isolated sandbox environment to prevent malicious code execution. Specifically, container images use the Docker Notary signing scheme, while ordinary application packages use PGP signing, ensuring that all types of media are appropriately protected.

[0071] Specifically, recreating the historical version environment unit according to the original deployment parameters achieves precise configuration rollback. It's understandable that each version, upon initial deployment, stores its complete deployment parameters (including resource limits, environment variables, health check configurations, etc.) in an immutable form in the `metadata.json` file. For example, during rollback, the system precisely restores key parameters such as CPU quotas and memory limits, ensuring resource allocation is completely consistent with historical versions. It should be noted that for deprecated configuration items, the system performs compatibility conversion, such as automatically adapting older Ingress configurations to the current cluster's Ingress Controller version.

[0072] In this embodiment, the state synchronization mechanism adopts an eventual consistency model. It is understood that after completing the rollback operation, the node agent generates a state update containing a detailed rollback report and uploads it to the cloud center via batch processing. For example, the report includes key indicators such as a version comparison before and after the rollback, a list of resource changes, and health check results. It should be noted that even if the network is temporarily unavailable, the report will be persistently stored locally and automatically synchronized once the connection is restored. Upon receiving the report, the cloud center updates the global deployment view and marks the rolled-back node with a special identifier on the operations and maintenance console to prevent accidental operations. This closed-loop design ensures the observability and traceability of the state in a distributed environment.

[0073] Step 103: At the target edge node, actively poll the cloud center through the node agent to obtain upgrade instructions, and pull incremental media packages from the unified repository of the cloud center to the local cache repository according to the upgrade instructions.

[0074] In this embodiment, the pre-installed X.509 certificate refers to the digital identity credential issued by the cloud center CA during the registration phase of the edge node. It is understood that this certificate is constructed using a PKI system and contains key fields such as a unique node identifier, public key information, and validity period. For example, the Subject DN field of the certificate encodes the organizational unit and geographical location information to which the node belongs, such as "OU=FactoryA,L=Shanghai". This design allows the certificate itself to carry rich node metadata.

[0075] It's important to note that node hardware fingerprints are unique identifiers generated by collecting the hardware characteristics of edge nodes. Specifically, the system combines immutable hardware features such as CPU serial number, motherboard information, and network card MAC address, using a hash algorithm to generate a fingerprint value. Understandably, this hardware-level binding mechanism effectively prevents the unauthorized copying and abuse of certificates. For example, even if an attacker obtains the certificate file, they cannot successfully use it on other devices because the hardware fingerprint cannot be matched.

[0076] In this embodiment, the mutual TLS authentication uses the mTLS (Mutual TLS) protocol to implement mutual authentication. For example, during the handshake process, not only does the cloud center verify the validity of the node certificate, but the node also verifies the cloud center server's certificate, forming a two-way trust chain. It should be noted that this design is particularly suitable for zero-trust security architectures, ensuring that the identities of both communicating parties are rigorously verified. Specifically, the system adopts the latest features of the TLS 1.3 protocol, such as one-round-trip handshake (1-RTT) and forward security, optimizing connection establishment efficiency while ensuring security.

[0077] Specifically, the issuance of access tokens and session keys adopts the OAuth 2.0 client credential model. Understandably, after certificate authentication, a node obtains a short-lived access token and a session key for data encryption. It should be noted that access tokens typically have a validity period of only a few hours. This temporary credential mechanism significantly reduces the risk of credential leakage; even if the token is intercepted, its validity period is very limited. The token contains fine-grained access control information, such as allowed API endpoints and operation permissions, implementing the principle of least privilege.

[0078] It's important to note that the heartbeat connection and automatic reconnection mechanism employ an exponential backoff algorithm. When a connection interruption is detected, the node agent immediately attempts to reconnect; if this fails, the waiting time gradually increases until the maximum interval is reached. This intelligent retry strategy avoids resource waste caused by frequent reconnections while ensuring a rapid response after network recovery. In addition to maintaining connection activity, heartbeat messages also carry metadata such as node resource usage and task execution status, providing the cloud center with a real-time monitoring view.

[0079] In this embodiment, the bidirectional TLS authentication for establishing a secure channel has been optimized at the application layer. It is understood that, to accommodate frequent polling operations, the system implements a session ticket mechanism on top of TLS session recovery, allowing reconnection after a short-term disconnection to skip the complete handshake process. For example, the node agent maintains a session cache pool and establishes independent encrypted channels to different cloud center service endpoints, achieving network isolation and load balancing.

[0080] It's important to note that the difference analysis request employs a content-addressed version comparison algorithm. Specifically, the node agent submits the Merkle tree hash value of the current local version to the cloud center, which quickly identifies the file blocks that need updating by comparing the hash trees. Understandably, this design makes the computational overhead of difference analysis proportional to the scope of the change, rather than the overall data size, making it particularly suitable for incremental updates in large-scale applications. For example, when only a specific configuration file of the application is modified, the system only needs to transmit the differing portion of that file, rather than the entire application package.

[0081] In this embodiment, the fragmented download and breakpoint resume mechanism employs a recoverable HTTP transport protocol. For example, each data block is assigned a unique block ID and checksum, and the metadata of received blocks is recorded in persistent storage during transmission. It should be noted that this design ensures that even if a node unexpectedly restarts, downloading can resume from the point of interruption, avoiding duplicate transmissions of completed portions. Specifically, the system supports multi-threaded parallel downloading, dynamically adjusting the fragment size and concurrency based on network quality to maximize bandwidth utilization while ensuring transmission reliability.

[0082] Specifically, the image layer reassembly and hash verification process adopts the OCI standard format for container images. Understandably, each downloaded fragment is temporarily stored in a temporary area. After all fragments are received, the system reassembles them according to the hierarchical structure described in the image manifest. After reassembly, the system calculates the hash value of the overall content and compares it with the checksum provided by the cloud center to ensure image integrity. This end-to-end verification mechanism effectively defends against the risk of data tampering during transmission. Only images that pass verification are officially written to the local cache repository, and the version index is updated.

[0083] It's important to note that the local cache repository employs a copy-on-write storage strategy. When a new version image is written, the system shares the unchanged image layer with the old version, storing only the differences. This design significantly reduces storage space usage while supporting the concurrent retention of multiple versions. The cache repository also implements an automatic garbage collection mechanism, automatically cleaning up expired images according to a preset retention policy (e.g., retaining the three most recent versions) to prevent unlimited growth of storage space. Repository access is abstracted through a unified storage interface, supporting various backend implementations such as file systems and object storage, adapting to different edge node storage environments.

[0084] Step 104: Call the pre-integrated standardized environment engine to load the base image and startup script in the target version media of the incremental media package, perform offline containerization deployment, and collect the container running status in real time and synchronize it to the cloud center.

[0085] In this embodiment, the incremental media package decompression to the specified directory employs an atomic operation design. It is understood that the system first completes all decompression and verification operations in a temporary working directory, and then switches to the target directory via an atomic rename after confirmation. For example, the decompression process uses memory mapping technology to accelerate large file processing while maintaining low memory usage. It should be noted that the specified directory follows the OCI standard layout, containing subdirectories such as blobs and manifests, ensuring seamless integration with the container runtime.

[0086] Specifically, the pre-built startup script loads environment variables and configuration files to implement dynamic configuration injection. In this embodiment, the startup script parses the config.json file in the media package and merges the declared environment variables according to priority: first, it loads the default values ​​preset by the template, then it overrides application-specific custom values, and finally it injects dynamically generated values ​​(such as database connection strings) at runtime. It can be understood that this layered configuration mechanism ensures both the consistency of basic configurations and meets the differentiated needs of different environments. For example, the startup script of a Java application intelligently identifies JVM memory parameters and automatically calculates a reasonable heap size configuration based on container resource limitations.

[0087] It's important to note that starting container processes as a non-root user is achieved through a multi-layered security strategy. Specifically, the system first creates a dedicated running user, such as `appuser`, during the image build phase. Then, it sets `securityContext.runAsNonRoot=true` in the Kubernetes Pod configuration. Finally, it forcibly switches the user identity in the container startup script. This defense-in-depth design effectively adheres to the principle of least privilege, making it difficult to escalate privileges even if the application has vulnerabilities. For example, for operations requiring special permissions, such as binding privileged ports, the system uses the Linux Capabilities mechanism for precise authorization, rather than directly using root privileges.

[0088] In this embodiment, an intelligent resource allocation algorithm is used to set the default CPU / memory range based on the environment template type. It can be understood that the system maintains a resource preset library, providing optimized configurations for different types of application templates. For example, AI inference templates will receive more CPU quotas and GPU resources, while Web service templates will focus on memory allocation and concurrent connection limits. It should be noted that these default values ​​are not fixed; the system will dynamically adjust them based on the actual resource status of the nodes and historical operating metrics, improving resource utilization while ensuring performance. Specifically, resource limits are globally applied through Kubernetes' LimitRange mechanism, ensuring that no container can over-consume resources.

[0089] In this embodiment, a multi-pipeline architecture is used to collect standard output logs from the container. This means the system simultaneously captures stdout and stderr streams, analyzes them through different processing pipelines, stores stdout logs in the Elasticsearch cluster after structured parsing, and triggers real-time alerts for stderr error streams. For example, stack traces from Java applications are specially processed to automatically extract exception types and key lines of code for quick problem localization. It should be noted that each log entry is appended with rich metadata, including application version, node ID, container name, etc., supporting multi-dimensional log retrieval and analysis.

[0090] Specifically, structured storage is implemented based on a unified log schema. In this embodiment, all log events are converted to JSON format, containing standard fields such as timestamp, logLevel, and message, as well as application-specific business fields. Understandably, the system automatically identifies common log formats (such as Log4j, JSON logs, etc.) and performs appropriate parsing and field mapping. For example, Actuator logs from a Spring Boot application will be parsed into independent monitoring metrics, rather than ordinary text logs. This structured processing allows log data to be directly used for business analysis, not just for troubleshooting.

[0091] It's important to note that real-time CPU / memory usage monitoring employs an adaptive sampling strategy. Specifically, the system dynamically adjusts the sampling frequency based on resource load, normally sampling once per minute, and automatically escalating to second-level monitoring when resource pressure is detected. This intelligent sampling reduces system overhead while ensuring granular monitoring during critical periods. For example, the collected metrics are exposed through Prometheus's Exporter mode, ensuring compatibility with mainstream Kubernetes monitoring systems. All metrics are tagged with the application version, supporting performance comparisons by version.

[0092] In this embodiment, a tiered alarm strategy enables intelligent fault response. The system defines multiple alarm thresholds and corresponding handling measures: a primary threshold triggers automatic capacity expansion, an intermediate threshold notifies the on-duty engineer, and a high threshold initiates an automatic rollback process. For example, memory usage alarms are analyzed in conjunction with OOM Killer events to avoid false alarms. It should be noted that alarm notifications support multi-channel distribution, including email, SMS, and enterprise IM, and follow on-duty rotation rules to ensure timely response. Specifically, the alarm engine uses a state machine model to accurately distinguish between momentary fluctuations and persistent anomalies, reducing unnecessary alarm interference.

[0093] Specifically, the WebShell remote debugging channel employs multi-layered security controls. Understandably, the system protects against security risks in four dimensions: first, it strictly controls access permissions based on RBAC; second, it establishes an SSH tunnel to encrypt all transmitted data; third, it records complete session audit logs; and finally, it restricts the execution of high-risk commands. For example, debugging sessions require two-factor authentication: first, logging into the console via enterprise SSO, and then connecting to the container using a temporary token. It should be noted that the system automatically identifies sensitive operations (such as file downloads and database queries), triggering additional approval processes or data anonymization. This design effectively prevents security risks while ensuring operational convenience.

[0094] It's important to note that container lifecycle events are recorded using an event sourcing model. This means the system not only records the final state of events but also retains a complete sequence of changes. For example, the entire process of a container from creation to termination is recorded as an ordered event stream, including key nodes such as Created, Started, HealthCheckPassed, and Stopped. This design supports precise time-travel debugging, allowing for backtracking to the container's state at any point in time. All events are distributed in real-time via a message bus, facilitating correlation processing by other systems (such as billing and auditing services).

[0095] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide an edge collaborative deployment device based on Kubernetes, the structure of which is as follows: Figure 2 As shown.

[0096] Figure 2 This is a schematic diagram of the internal structure of a Kubernetes-based edge collaborative publishing device provided in an embodiment of this application. Figure 2 As shown, the device includes:

[0097] At least one processor;

[0098] And, a memory that is communicatively connected to at least one processor;

[0099] The memory stores instructions that can be executed by at least one processor, and the instructions, when executed by at least one processor, enable at least one processor to:

[0100] The cloud center management terminal receives application deployment parameters submitted by users through the abstract interaction layer, and matches the pre-packaged base image and startup script from the standardized environment library according to the runtime environment template in the application deployment parameters to generate a resource declaration file;

[0101] The resource declaration file and user code media are packaged into a versioned application media package, which is then stored in the unified cloud repository. An upgrade command is then issued to the target edge node through the task scheduling engine. The upgrade command includes the application identifier and the target version number.

[0102] At the target edge node, the node agent actively polls the cloud center to obtain upgrade instructions, and according to the upgrade instructions, pulls incremental media packages from the unified repository of the cloud center to the local cache repository.

[0103] The pre-integrated standardized environment engine loads the base image and startup script from the target version of the incremental media package, performs offline containerized deployment, and collects the container running status in real time and synchronizes it to the cloud center.

[0104] This application also provides a non-volatile computer storage medium storing computer-executable instructions, which, when executed, can:

[0105] The cloud center management terminal receives application deployment parameters submitted by users through the abstract interaction layer, and matches the pre-packaged base image and startup script from the standardized environment library according to the runtime environment template in the application deployment parameters to generate a resource declaration file;

[0106] The resource declaration file and user code media are packaged into a versioned application media package, which is then stored in the unified cloud repository. An upgrade command is then issued to the target edge node through the task scheduling engine. The upgrade command includes the application identifier and the target version number.

[0107] At the target edge node, the node agent actively polls the cloud center to obtain upgrade instructions, and according to the upgrade instructions, pulls incremental media packages from the unified repository of the cloud center to the local cache repository.

[0108] The pre-integrated standardized environment engine loads the base image and startup script from the target version of the incremental media package, performs offline containerized deployment, and collects the container running status in real time and synchronizes it to the cloud center.

[0109] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0110] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0111] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0112] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0113] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0114] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0115] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0116] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0117] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0118] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0119] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.< / hash>

Claims

1. A Kubernetes-based edge collaborative deployment method, characterized in that, The method includes: The cloud center management terminal receives application deployment parameters submitted by users through an abstract interaction layer, and matches the pre-packaged base image and startup script from the standardized environment library according to the runtime environment template in the application deployment parameters to generate a resource declaration file. The resource declaration file and user code media are packaged into a versioned application media package, which is then stored in the unified cloud repository. An upgrade command is then issued to the target edge node through the task scheduling engine. The upgrade command includes the application identifier and the target version number. The target edge node actively polls the cloud center through the node agent to obtain the upgrade instruction, and pulls the incremental media package from the unified warehouse of the cloud center to the local cache warehouse according to the upgrade instruction; The pre-integrated standardized environment engine is invoked to load the base image and the startup script in the target version of the incremental media package, execute offline containerized deployment, and collect the container running status in real time and synchronize it to the cloud center.

2. The edge collaborative deployment method based on Kubernetes according to claim 1, characterized in that, Based on the runtime environment template in the application deployment parameters, a pre-packaged base image and startup script are matched from the standardized environment library, specifically including: Receive the developer's technology stack selection instruction, and match the preset versioned base image template according to the selection instruction; Dynamically generate a Dockerfile containing component dependencies and a container startup script, and inject middleware connection parameters into the application container via environment variables.

3. The edge collaborative deployment method based on Kubernetes according to claim 1, characterized in that, Generate a resource declaration file, specifically including: Map the application name in the application deployment parameters to a combined Deployment and Service tag; Convert single-port or multi-port declarations into Service port mapping rules and Ingress routing configurations; Based on the preset health check template, automatically fill in the Liveness Probe detection path or Readiness Probe detection path; Convert the CPU / memory range of the graphical settings to the container's Requests or Limits parameters.

4. The edge collaborative deployment method based on Kubernetes according to claim 1, characterized in that, Before the target edge node actively polls the cloud center to obtain the upgrade instruction through the node agent, the method further includes: When the target edge node starts up, it loads a pre-configured X.509 certificate, carrying the node hardware fingerprint and certificate signature, and initiates a handshake request to the node trust unit of the cloud center management terminal; the certificate includes a unique node identifier and validity information. Receive the access token and session key issued by the cloud center management terminal to establish an encrypted communication channel based on TLS 1.3; Maintain heartbeat connection and periodically synchronize node resource usage; automatically attempt to reconnect when connection is interrupted.

5. The edge collaborative deployment method based on Kubernetes according to claim 1, characterized in that, The target edge node actively polls the cloud center through its node agent to obtain the upgrade instruction, and according to the upgrade instruction, pulls incremental media packages from the unified repository of the cloud center to the local cache repository, specifically including: The target edge node connects to the cloud center through a node proxy, establishes a secure channel through two-way TLS authentication, and polls the task queue of the cloud center based on the secure channel to obtain upgrade instructions; The node agent sends a difference analysis request to the cloud center so that the task scheduling engine can check whether the target version medium exists in the local cache repository according to the target version number in the upgrade instruction. If not, a segmented download request is initiated to the cloud center, and the image layer data is transmitted in segments using a breakpoint resume mechanism, with verification performed after each segment is transmitted. After all chunks have been transferred, the image layer is reassembled locally, and after the overall hash value is successfully verified, the locally reassembled incremental image is written to the local cache repository.

6. The edge collaborative deployment method based on Kubernetes according to claim 1, characterized in that, Performing offline containerized deployment specifically includes: The incremental media package in the local cache repository is decompressed to the specified directory, and the environment variables and configuration files are loaded through the preset startup script; The container process is started as a non-root user, and the default CPU / memory range is set according to the environment template type.

7. The edge collaborative deployment method based on Kubernetes according to claim 1, characterized in that, Real-time collection of container running status, specifically including: Collect the container's standard output logs, store the logs in a structured manner, and associate them with the corresponding application version and node information; Real-time collection of container CPU / memory usage, and triggering a tiered alarm strategy to send alarm notifications to preset contacts when resource usage continues to exceed a preset threshold; Record container lifecycle events and establish a secure remote debugging channel for the container via the WebShell protocol, allowing authorized users to directly enter the container for diagnostic operations; the lifecycle events include startup, stop, restart, and abnormal exit.

8. The edge collaborative deployment method based on Kubernetes according to claim 1, characterized in that, The method further includes: Receive the rollback command from the cloud center and stop all instances of the currently running version, while retaining the media cache of the most recent N versions; the rollback command specifies the target rollback version identifier; Load historical version media from the local cache repository and verify the integrity and signature of the historical version media; Recreate the historical version environment unit according to the original application deployment parameters, keep the resource configuration unchanged, and synchronize the rollback completion status to the cloud center management terminal to update the node task execution records.

9. An edge collaborative deployment device based on Kubernetes, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the Kubernetes-based edge collaborative deployment method as described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, the Kubernetes-based edge collaborative deployment method as described in any one of claims 1-8 is implemented.

Images