Service deployment method and distributed service cluster

Abstract

The embodiment of the application provides a service deployment method and a distributed service cluster, the distributed service cluster comprising a management node, a first working node, a second working node and a storage node, a plurality of types of check containers are deployed on the first working node, and the method comprises the following steps: the management node acquires a service deployment request submitted by a client, acquires a plurality of resource objects configured for a target service from the service deployment request, determines a check container of a corresponding type according to the plurality of resource objects, and sends the plurality of resource objects to the check container of the corresponding type; the plurality of types of check containers check corresponding resource objects to obtain check results; the management node determines an overall check result of the target service according to the check results fed back by the plurality of types of check containers, and when the overall check result is passed, the plurality of resource objects of the target service are stored persistently to the storage node; and the second working node creates a container instance for the target service locally according to the plurality of resource objects of the target service stored in the storage node.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of distributed technology, and in particular to a service deployment method and a distributed service cluster. Background Technology

[0002] With the widespread adoption of containerization and cloud-native technologies, migrating services to the cloud has become a clear trend. Services can be deployed in the cloud via container instances by submitting resource objects containing various configurations, such as container groups, configuration mappings, keys, and storage classes. For the financial industry, payment services, risk control services, and other services can all be deployed in the cloud.

[0003] Currently, when deploying services in the cloud, the security of deployment configurations still relies on manual review. Security personnel need to manually check the configurations in each deployment request against security baselines and compliance requirements to determine if there are any insecure or non-compliant configurations. However, the speed of manual review is difficult to meet the comprehensive requirements of security, efficiency, and scalability in a cloud-native environment. Summary of the Invention

[0004] This invention provides a service deployment method and a distributed service cluster, which can achieve consistent and accurate security verification of complex and massive configurations, thereby improving service deployment efficiency and automation.

[0005] In a first aspect, embodiments of the present invention provide a service deployment method applied to a distributed service cluster, the distributed service cluster including a management node, a first worker node, a second worker node, and a storage node, wherein multiple types of verification containers are deployed on the first worker node, and the method includes: The management node obtains the service deployment request submitted by the client, retrieves multiple resource objects configured for the target service from the service deployment request, determines the corresponding type of verification container based on the multiple resource objects, and sends the multiple resource objects to the corresponding type of verification container; The multi-type verification containers verify the corresponding resource objects and obtain the verification results. The management node determines the overall verification result of the target service based on the verification results fed back by the multiple verification containers. If the overall verification result is passed, the management node persists the multiple resource objects of the target service to the storage node. The second working node creates a container instance for the target service locally based on the multiple resource objects of the target service stored in the storage node.

[0006] Secondly, embodiments of the present invention provide a distributed service cluster, including a management node, a first working node, a second working node, and a storage node, wherein multiple types of verification containers are deployed on the first working node; The management node is used to obtain service deployment requests submitted by clients, obtain multiple resource objects configured for the target service from the service deployment requests, determine the corresponding type of verification container based on the multiple resource objects, and send the multiple resource objects to the corresponding type of verification container. The various verification containers are used to verify the corresponding resource objects and obtain the verification results; The management node is also used to determine the overall verification result of the target service based on the verification results fed back by the multiple verification containers, and if the overall verification result is passed, to persistently store multiple resource objects of the target service to the storage node. The second working node is used to create a container instance for the target service locally based on the multiple resource objects of the target service stored in the storage node.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a service deployment method as described in any embodiment of the present invention.

[0008] Fourthly, the computer-readable storage medium provided in the embodiments of the present invention stores a computer program thereon, which, when executed by a processor, implements the service deployment method as described in any embodiment of the present invention.

[0009] Fifthly, the computer program product provided in the embodiments of the present invention includes a computer program that, when executed by a processor, implements the service deployment method as described in any embodiment of the present invention.

[0010] In this embodiment of the invention, a multi-layered verification process is embedded in the critical path between resource object submission and persistent storage. Any deployment request, regardless of its origin, must be intercepted in real-time by automated verification before being formally accepted by the cluster, eliminating the possibility of insecure configurations leaking into the production environment. All verifications are based on standardized rules, eliminating human error and ensuring the consistency and repeatability of security policy execution. The verification process is fully automated and parallelized, with automatic distribution by management nodes and multiple verification containers working in parallel. The added latency of the verification stage is extremely low, making security verification no longer an obstacle to speed and meeting the fast and reliable deployment requirements pursued by cloud-native technologies. By automating repetitive and patterned review work, it can handle the needs of large-scale service deployment, freeing security experts from heavy daily reviews and reducing the cost of security operations. Attached Figure Description

[0011] To more clearly illustrate the technical solution 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.

[0012] Figure 1 This is a flowchart illustrating a service deployment method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of an architecture of a distributed service cluster provided in an embodiment of the present invention; Figure 3 This is another flowchart illustrating the service deployment method provided in this embodiment of the invention; Figure 4 This is another schematic diagram of the distributed service cluster provided in the embodiments of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] Figure 1This is a flowchart illustrating a service deployment method provided in an embodiment of the present invention. The service deployment method provided in this embodiment is applicable to scenarios such as deploying payment services and risk control services required by the financial industry on the cloud. The service deployment method provided in this embodiment can be applied to distributed service clusters. The architecture of a distributed service cluster can be as follows: Figure 2 As shown, it includes a management node, a first working node, a second working node, and a storage node. Multiple types of verification containers are deployed on the first working node.

[0016] Figure 2 In this context, the client initiates the service deployment request, which can be a command-line tool used by developers or an automated operations and maintenance platform. The client can submit a service deployment request containing the complete definition of the target service to the management node, which encapsulates multiple resource objects.

[0017] The management node serves as the command center and unified entry point for the distributed service cluster. It receives client requests and parses out multiple resource objects; based on the request content, it triggers a security verification process, distributing the resource objects to the corresponding verification containers; and it aggregates all verification results to make a final decision. This final decision might be: if deployment is allowed, the resource objects are written to the storage node; if deployment is rejected, the request is intercepted and an error is returned.

[0018] The first working node is a type of computing node specifically designed to run security verification workloads. It is physically or logically isolated from the nodes running service containers (i.e., the second working nodes), dedicated solely to security processing, and can be independently optimized for performance and scaled up or down. The first working node may include one or more working nodes. The core of this invention—multi-type verification containers—is deployed and run on the first working node. These multi-type verification containers may include: Basic compliance validation container: Responsible for performing general checks on resource objects, including format validity, syntax correctness, field integrity, and basic naming conventions.

[0019] Native object validation container: Performs in-depth security policy checks on standard resource types built into the container orchestration platform, focusing on dimensions such as runtime security, resource control, and network isolation.

[0020] Extended object validation container: Performs security and compliance validation based on business semantics for user-defined resource types, including structural compliance, business logic validity, and data integrity validation.

[0021] Secondary worker nodes are a type of compute node that runs business service container instances. After the management node's decision is approved, they retrieve the resource object definition of the target service from the storage node and drive the container runtime to create and run the actual service container instance locally. They are the ultimate executor of service deployment. A secondary worker node can include one or more worker nodes.

[0022] Storage nodes are the persistent memory hub of the cluster, storing all state data of the cluster, typically a distributed key-value database cluster. As the endpoint of successful verification and the starting point for container creation, resource objects are only persistently stored here after the management node's decision is approved. Subsequently, the scheduler and controller read the expected state here and drive the second worker nodes to complete the actual deployment. The core security interception point of this invention occurs precisely before the write operation at this location.

[0023] Continue reading Figure 1 The service deployment method in this embodiment may include the following steps: Step 101: The management node obtains the service deployment request submitted by the client, retrieves multiple resource objects configured for the target service from the service deployment request, determines the corresponding type of verification container based on the multiple resource objects, and sends the multiple resource objects to the corresponding type of verification container.

[0024] A service deployment request refers to a standardized operation command initiated by a client, conforming to established interface specifications. This request uses a network protocol as its carrier, and its payload employs a structured data format, fully encapsulating the configuration information and expected state of the service to be deployed. A target service refers to a service unit with clearly defined business functions, encapsulated in a container. In a cloud-native architecture, a target service typically consists of a group of cooperating container instances and their associated configuration, network, and storage resources, forming a logically autonomous, independently deployable, and scalable functional entity. For example, in a banking scenario, a payment routing service, a real-time risk control engine, or a customer information query unit can all be deployed and managed as independent target services.

[0025] Resource objects are a core abstraction in container orchestration platforms, serving as a declarative data model to describe various entities and their configurations within a cluster. Each resource object can contain standard metadata, specification definitions, and status information, adhering to the platform-defined interface architecture. Based on their functional attributes, resource objects can be categorized into the following main types: Workload objects: such as deployment objects, stateful replica sets, etc., are used to define the replica strategy, update mechanism and lifecycle management of containerized applications; Service and network objects: such as service resources and entry resources, used to define service discovery mechanisms, load balancing strategies and network access rules; Configuration and storage objects: such as configuration mappings, key resources, persistent volume declarations, etc., are used to manage application configurations, sensitive data, and persistent storage requirements; Policy and permission objects: such as network policies, namespace roles, resource quotas, etc., are used to define security policies, access control and resource quotas; Custom resource objects: Custom resources are extended through custom resource definitions and are used to carry out configuration requirements for specific business domains.

[0026] Verification containers are the core execution units for implementing security verification functions. They are dedicated workloads with specific verification capabilities, encapsulated using container technology. These containers can be categorized into different types according to their functional responsibilities, forming a modular verification capability system. For example, they can be divided into basic compliance verification containers, native resource verification containers, and extended resource verification containers.

[0027] When the management node receives a service deployment request from a client, it first performs identity authentication and authorization verification on the request. After successful verification, the request payload is deserialized to extract the resource objects contained within. Each resource object can contain fields identifying its type, a version field, and specific configuration content. The management node can categorize the extracted resource objects according to a preset verification classification strategy, construct a verification task distribution plan based on the classification results, and send the resource objects to the corresponding verification containers according to the verification task distribution plan. For example, the verification task distribution plan can be: All resource objects, regardless of their type, must be sent to the basic compliance verification container for general checks.

[0028] The native resource object will also be routed to the native resource validation container.

[0029] Extended resource objects will also be routed to the extended resource validation container.

[0030] Step 102: The multi-type verification container verifies the corresponding resource object and obtains the verification result.

[0031] The corresponding resource objects refer to the subset of resource objects that are precisely routed and assigned to a specific type of verification container by the management node according to the verification classification strategy. The verification result is the structured output of the verification container after performing the predetermined verification process on the resource objects. The verification result may include: Verification status: Indicates whether the specific object or verification dimension has passed the check; Details: When the validation fails, provide a detailed description of the specific rule violated, the path of the violating field, the actual value and the expected value, etc. Verification context: This includes metadata such as verification time, verification container identifier, and application rule version; Recommended measures: Automated remediation suggestions or strategy guidelines for the identified issues.

[0032] Step 103: The management node determines the overall verification result of the target service based on the verification results fed back by the multiple verification containers. If the overall verification result is passed, the multiple resource objects of the target service are persistently stored to the storage node.

[0033] The verification results returned by various verification containers refer to the structured set of verification conclusions returned to the management node by different types of verification units, such as the basic compliance verification container, the native resource verification container, and the extended resource verification container, after completing the inspection of the allocated resource objects. These results can be organized according to the verification container type and resource object identifier to form a complete verification evidence chain.

[0034] The overall verification result refers to the final judgment on the target service deployment request generated by the management node after aggregating the individual results from all verification containers, through a pre-defined decision logic. This conclusion can be the basis for a binary decision (allow / deny), and its generation process may include: Result aggregation: Associates and summarizes multiple validation results from different validation containers by resource object; Strategy assessment: Assess the overall risk level based on predefined security policies (such as veto power or weighted scoring). Conflict resolution: When different verification results are contradictory (such as the basic verification passing but the security verification failing), a preset priority rule is applied to make a decision. Conclusion generation: Generates an overall conclusion that includes the final decision, comprehensive risk assessment level, and detailed supporting evidence.

[0035] Persistent storage to storage nodes refers to the operation whereby, after the management node determines that the overall verification result is passed, writes all resource objects constituting the target service into the cluster's distributed consistent storage system in a transactional manner. This process has the following technical characteristics: Atomicity guarantee: Write operations on multiple resource objects are treated as a single transaction, which either all succeed or all are rolled back, ensuring the consistency of the service definition; Versioning management: Each resource object is stored with a version identifier, supporting subsequent version tracking and rollback operations; High availability: Storage nodes typically employ a multi-replica distributed architecture to ensure data persistence and availability; Access control: Write operations require permission verification, and only authorized system components (such as controllers) can read this data.

[0036] The management node can receive verification results from each verification container via asynchronous callback mechanisms or message queues. It can maintain a verification status table for each service deployment request, updating the status of each resource object across different verification dimensions in real time. Once all verification results are returned, the management node's decision engine initiates the overall evaluation process. When the overall verification result is passed, the management node encapsulates all resource objects of the target service into a storage transaction, ensuring the atomicity of these objects at the storage layer; analyzes the reference relationships between resource objects to ensure the storage order satisfies dependency constraints; writes all resource objects in a transactional manner through the storage node's client interface; after successful writing, the storage node returns a confirmation response; the management node updates its internal state, marks the service deployment request as accepted, and triggers subsequent scheduler monitoring mechanisms.

[0037] Step 104: The second worker node creates a container instance for the target service locally based on the multiple resource objects of the target service stored in the storage node.

[0038] Creating a container instance for the target service locally refers to the second worker node instantiating and running the corresponding containerized application within its own operating system environment based on the service definition in the storage node. Creating a container instance for the target service involves a multi-stage resource preparation and configuration process, specifically including: Resource scheduling: This refers to the cluster scheduler calculating on which specific second worker node a container instance should be created based on factors such as resource availability, affinity policies, and node constraints.

[0039] Declarative to imperative conversion: Converting declarative resource objects in storage into imperative container execution instructions on nodes.

[0040] Localized configuration application: Based on the specific environment of the node, apply localized settings such as network configuration, storage mounting, and security context.

[0041] Lifecycle management: After startup, continuously monitor the container status to ensure that it runs in the expected state and perform recovery operations in case of anomalies.

[0042] The creation of a container instance marks the transition of the service from the configuration definition phase to the actual operation phase, at which point it begins to provide business functionality.

[0043] In this embodiment, a multi-layered verification process is embedded in the critical path between resource object submission and persistent storage. Any deployment request, regardless of its origin, must be intercepted in real-time by automated verification before being formally accepted by the cluster, eliminating the possibility of insecure configurations leaking into the production environment. All verifications are based on standardized rules, eliminating human bias and ensuring the consistency and repeatability of security policy execution. The verification process is fully automated and parallelized, with automatic distribution by management nodes and multiple verification containers working in parallel. The added latency in the verification stage is extremely low, ensuring that security verification no longer hinders speed and meeting the fast and reliable deployment requirements pursued by cloud-native technologies. By automating repetitive and patterned review work, it can handle the needs of large-scale service deployment, freeing security experts from heavy daily reviews and reducing the cost of security operations.

[0044] Figure 3 This is another flowchart illustrating the service deployment method provided in this embodiment of the invention, which can be applied to... Figure 4 The distributed service cluster shown is an example. Figure 4 As shown, the distributed service cluster includes: a management node, a first worker node, a second worker node, a storage node, and a scheduling node.

[0045] Figure 4The client in the cluster is the request initiator. Service developers or operations personnel submit service deployment requests to the cluster through the client. This request contains all resource objects defining the target service. The management node is the cluster control and coordination center. It receives and parses service deployment requests from clients, routes and distributes resource objects to different verification containers according to their types, aggregates all verification results, makes a final decision (allow / block deployment), and persists the verified service configuration to the storage node. The first worker node is the security verification execution layer, which can include multiple worker nodes, such as worker node 1 with a basic compliance verification container, worker node 2 with a native object verification container, worker node 3 with an extended object verification container, and worker node 4 with a verification configuration container. The verification configuration container is an independent and dedicated rule storage and management service container. As a centralized security policy knowledge base, it provides dynamic, versioned, and hot-updateable verification rules and configuration data for other verification containers (such as the basic compliance verification container, native object verification container, and extended object verification container). The second worker node is the business service carrying layer, and can also include multiple worker nodes, such as worker node 1 deploying container instances of service 1, worker node 2 deploying container instances of service 2, etc. Each worker node can run one or more service instances. Storage nodes are cluster storage devices used to persistently store all verified and valid service resource configurations and cluster state information. Scheduling nodes are resource schedulers that, based on cluster resource conditions (such as computing resources and memory resources) and affinity rules, determine which specific second worker node to allocate a service instance to for execution, and then issue scheduling instructions to the target second worker node to trigger the container creation process.

[0046] This embodiment concretizes multiple types of verification containers into three categories: basic compliance, native objects, and extended objects. It also clarifies the objects (all, native, and extended) and content (basic compliance, deep security, and customized security) to be verified for each category. This three-layer verification architecture enables refined and targeted processing of different types of resource objects.

[0047] The following is combined Figure 4 The distributed service cluster shown further illustrates the service deployment method provided in this embodiment of the invention. (Continue reading...) Figure 3 The method in this embodiment includes: Step 201: The management node obtains the service deployment request submitted by the client and retrieves multiple resource objects configured for the target service from the service deployment request.

[0048] Taking a bank deploying an "interbank payment service" as an example, the management node obtains multiple resource objects configured for the interbank payment service from the service deployment request. Each resource object may include: Metadata: such as name, namespace, tags, etc.; Specification definition: such as specific configuration parameters; Status information: It is currently empty because it has not been created yet.

[0049] The resource objects configured for interbank payment services may include: Deployment object: Describes the number of payment processing container replicas to be run; Service target: Internal access endpoints that provide payment services; Configure the mapping object: including parameters such as transaction timeout settings and single transaction limit; Key object: Encrypted storage of interface keys for connecting to other banking systems; Network policy object: Specifies that only traffic from the internal gateway is allowed to access the network; Persistent volume declaration object: Requests encrypted storage for audit logs; Payment limit policy object: Defines the business rules for the maximum limit of a single transaction for a customer.

[0050] Step 202: The management node identifies native resource objects and extended resource objects from multiple resource objects based on a pre-configured resource list.

[0051] The pre-configured resource list is a mapping table stored locally on the management node or in an accessible configuration store. It is used to quickly identify resource types and can exist in the form of a data structure (such as a hash table) or a configuration file. It contains identification information of the standard resource types currently supported by the container orchestration platform.

[0052] The pre-configured resource list can be either a native resource list or an extended resource list. The native resource list contains all native resource types, while the extended resource list contains known extended resource types. When the pre-configured resource list is a native resource list, the management node can identify resource objects belonging to the native resource list as native resource objects and those not belonging to the native resource list as extended resource objects. Conversely, when the pre-configured resource list is an extended resource list, the management node can identify resource objects belonging to the extended resource list as extended resource objects and those not belonging to the extended resource list as native resource objects.

[0053] Native resource objects are objects corresponding to resource types that are natively defined and supported by the container orchestration system. Extended resource objects are objects corresponding to resource types that are created by users through custom resource definitions or introduced by third parties.

[0054] Continuing with the previous example, for the seven resource objects in the interbank payment service, the management node could categorize them as follows: Native resource objects (6): Deployment, Service, Configuration Mapping, Key, Network Policy, Persistent Volume Declaration; Extended resource object (1): Payment limit policy.

[0055] Step 203: The management node determines the verification scope based on real-time conditions. If a full verification is required, proceed to step 204; if a partial verification is required, proceed to step 206.

[0056] Real-time status refers to the dynamically changing cluster state, business context, and external environmental factors perceived by the management node at the moment it receives a service deployment request. This information is not statically configured but rather dynamic data that changes continuously over time and with events. Real-time status can include: System load status: The number of deployment requests currently queued for processing, the resource utilization of the verification container cluster, network latency, and other performance metrics.

[0057] Business time factors: Whether it is a peak business period or a payment system settlement window period, etc., are time-sensitive factors.

[0058] Service importance characteristics: The level of business criticality of the service identified through tags, annotations, or configuration information in the deployment request.

[0059] Security posture information: Are there any recent security vulnerability announcements or other security context?

[0060] The scope of verification refers to the combination strategy of the types of resource objects covered and the depth of verification operations to be performed in the security verification process of this invention. This is a dynamically adjustable decision variable that determines the balance between the strictness of security verification and resource consumption. The scope of verification includes comprehensive verification and partial verification. Comprehensive verification performs full-depth security verification on all resource objects involved in the target service, regardless of their type, including all checks for basic compliance verification, deep security verification of native resources, and customized security verification of extended resources. Partial verification performs security verification only on specific high-risk resource objects in the target service, or performs simplified versions of verification on certain objects. It typically focuses on the most critical security risk points and has a faster processing speed. Comprehensive verification is the highest intensity mode of security verification, suitable for deployment in production environments of core business services, deployments involving sensitive data or high-privilege operations, and mandatory checks for regulatory compliance requirements. Partial verification is an optimized efficiency mode of security verification. By intelligently selecting the most critical verification points, it significantly reduces verification time and resource consumption while ensuring basic security. It is suitable for deployment of non-critical services during periods of high system load, deployment in development and testing environments, and rapid release for emergency fault repairs.

[0061] In one embodiment, the management node can identify the importance level of the target service configuration; if the importance level exceeds a preset level, the management node determines the verification scope to be full verification; if the importance level does not exceed the preset level, the management node determines the verification scope to be partial verification. That is, high-level services trigger full verification, and low-level services trigger partial verification, thereby achieving a precise match between security policies and business value.

[0062] In another embodiment, the management node determines the number of unprocessed service deployment requests; if the number of unprocessed requests does not exceed a preset number, the management node determines the verification scope to be full verification; if the number of unprocessed requests exceeds the preset number, the management node determines the verification scope to be partial verification. That is, full verification is performed when the load is low, and partial verification is performed when the load is high, enabling the verification system to self-adjust according to real-time throughput.

[0063] In practice, the scope of verification can be determined by combining multiple factors. Continuing the previous example, if a bank wants to deploy an interbank payment service, the management node has extracted seven resource objects from the request and completed the classification of native and extended resource objects.

[0064] Assume it is currently Monday morning at 10:30 AM, a peak time for bank transactions. The management node's perception data is as follows: System load: Monitoring shows that the resource utilization of the container cluster is 85%, and 15 service deployment requests are queued.

[0065] Business hours: The payment system's daytime clearing window is from 9:00 to 17:00, during which the transaction volume is huge.

[0066] Service characteristics: The service tag identified from the request is of the highest critical level and belongs to the core payment system.

[0067] The decision engine of the management node applies preset rules: Rule 1: Core payment services must be fully validated at all times; Rule 2: During peak business hours, partial validation may be enabled for non-core services. However, this service is a core service.

[0068] The management node determines the verification scope to be a full verification based on the above rules.

[0069] Step 204: The management node sends multiple resource objects to the basic compliance verification container, sends the native resource objects to the native object verification container, and sends the extended resource objects to the extended object verification container.

[0070] This means that a full verification must be performed.

[0071] Step 205: The basic compliance verification container performs basic compliance verification on multiple resource objects to obtain the basic compliance verification result; the native object verification container performs deep security verification on native resource objects to obtain the deep security verification result; and the extended object verification container performs customized security verification on extended resource objects to obtain the customized security verification result.

[0072] The basic compliance verification container is a containerized service that performs basic format and compliance checks on resource objects. It can obtain verification configurations from the verification configuration container to perform basic compliance verifications. The verification content of basic compliance checks may include at least one of the following: Syntax compliance: Verify the correctness of the configuration file format, including indentation, bracket matching, and special character escaping.

[0073] Field integrity: Check that each resource object contains the required metadata fields.

[0074] Naming conventions: Verify whether the resource name conforms to the agreed naming pattern according to the verification standard.

[0075] Tag / Annotation Basic Check: Ensure that resource objects contain the necessary business tags (such as department, environment, service level).

[0076] The basic compliance verification result is a structured conclusion generated by the basic compliance verification container after completing the check, reflecting the compliance status of resource objects at the basic specification level.

[0077] The native object verification container is a containerized service specifically designed to perform platform-level deep security checks on native built-in resource types. Based on the type of the native resource object, the native object verification container retrieves the corresponding native resource security verification configuration from the verification configuration container, and performs deep security verification on the native resource object according to the native resource security verification configuration. The verification content may include at least one of the following: Validation of container security context: to verify whether the container is configured to prohibit running in privileged mode and prohibit running as the root user.

[0078] Verification of resource quotas and limits: to verify whether computing and memory usage limits have been set.

[0079] Verification of network exposure configurations: to verify whether container ports and service exposure methods comply with the principle of minimal openness.

[0080] Verification of storage volume configuration: to verify whether sensitive data is stored on an encrypted storage volume.

[0081] The deep security verification result is a detailed security assessment conclusion generated by the native object verification container after completing a deep check, reflecting the risk status of resource objects at the platform security level.

[0082] The Extended Object Validation Container is a containerized service specifically designed to perform business-level compliance checks on user-defined resource types. Based on the type of the extended resource object, the Extended Object Validation Container retrieves the corresponding structural definition pattern and business security configuration from the validation configuration container. Based on the structural definition pattern, the Extended Object Validation Container verifies the structural compliance of the extended resource object. Based on the business security configuration, it verifies the compliance of the business parameters and operational logic defined within the extended resource object. Structural compliance verifies whether the structure of the extended resource object conforms to its custom resource definition pattern; business parameter compliance primarily ensures that the values ​​of business data fields are within reasonable ranges; and operational logic compliance primarily checks whether the logic in the business rules is correct, complete, and consistent. The customized security validation result is a business compliance assessment conclusion generated by the Extended Object Validation Container after completing the business checks, reflecting the status of the custom business resource in terms of regulatory compliance and business risk.

[0083] Step 206: The management node sends the extended resource object to the extended object verification container.

[0084] This means that partial verification needs to be performed.

[0085] Step 207: The extended object verification container performs customized security verification on the extended resource object and obtains the customized security verification result.

[0086] Step 208: The management node determines the overall verification result of the target service based on the verification result fed back by the verification container. If the overall verification result is passed, the multiple resource objects of the target service are persistently stored to the storage node.

[0087] The overall verification result of the target service is the final security judgment on the entire service deployment request generated by the management node after collecting and analyzing the individual results returned by all verification containers, applying preset decision logic. The overall verification result of the target service can be determined as passed if all individual results are passed. Alternatively, voting mechanisms, weighted scoring mechanisms, etc., can be used to process individual results to determine the overall verification result of the target service.

[0088] Continuing with the previous example, assuming that the basic compliance verification results of the seven resource objects of the interbank payment service are all passed, the deep security verification results of the six native resource objects are also passed, and the customized security verification result of the one extended resource object is also passed, then the overall verification result of the target service is determined to be passed.

[0089] Step 209: The scheduling node responds to the multiple resource objects of the target service stored in the storage node and sends scheduling instructions to the second working node.

[0090] A scheduling instruction is a binding command sent by a scheduling node to a specific worker node, explicitly indicating which container instance should run on which node. The instruction content may include: container instance identifier, node identifier, scheduling timestamp, scheduling basis, etc.

[0091] Step 210: The second worker node responds to the scheduling instruction and creates a container instance for the target service locally based on the multiple resource objects of the target service stored in the storage node.

[0092] Following the previous example, assuming that all seven resource objects of the interbank payment service have passed all security checks and have been successfully written to the storage node, a container instance can be created and started on the second working node determined by the scheduling node, thereby realizing the deployment of the interbank payment service.

[0093] In this embodiment, a multi-layered verification process is embedded in the critical path between resource object submission and persistent storage. Any deployment request, regardless of its origin, must be intercepted in real-time by automated verification before being formally accepted by the cluster, eliminating the possibility of insecure configurations leaking into the production environment. All verifications are based on standardized rules, eliminating human bias and ensuring the consistency and repeatability of security policy execution. The verification process is fully automated and parallelized, with automatic distribution by management nodes and multiple verification containers working in parallel. The added latency in the verification stage is extremely low, ensuring that security verification no longer hinders speed and meeting the fast and reliable deployment requirements pursued by cloud-native technologies. By automating repetitive and patterned review work, it can handle the needs of large-scale service deployment, freeing security experts from heavy daily reviews and reducing the cost of security operations.

[0094] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer system 500 suitable for implementing an electronic device in the embodiments of the present invention. The electronic device can be any device in a distributed service cluster. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0095] like Figure 5 As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the computer system 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0096] The following components are connected to I / O interface 505: input section 506 including keyboard, mouse, etc.; output section 507 including cathode ray tube, liquid crystal display, etc., and speakers, etc.; storage section 508 including hard disk, etc.; and communication section 509 including network interface card, such as modem, etc. Communication section 509 performs communication processing via a network such as the Internet. Drive 510 is also connected to I / O interface 505 as needed. Removable media 511, such as disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 510 as needed so that computer programs read from them can be installed into storage section 508 as needed.

[0097] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention 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 flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined above in the system of this invention.

[0098] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, etc., or any suitable combination thereof.

[0099] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0100] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, enable the device to perform the service deployment method provided in the embodiments of the present invention.

[0101] The technical solution of this invention embeds a multi-layered verification process into the critical path between resource object submission and persistent storage. Any deployment request, regardless of its origin, must be intercepted in real-time through automated verification before being formally accepted by the cluster, eliminating the possibility of insecure configurations leaking into the production environment. All verifications are based on standardized rules, eliminating human error and ensuring the consistency and repeatability of security policy execution. The verification process is fully automated and parallelized, with automatic distribution by management nodes and multiple verification containers working in parallel. For compliant deployment requests, the added latency is extremely low, making security verification no longer a speed obstacle and meeting the fast and reliable deployment requirements pursued by cloud-native technologies. By automating repetitive and patterned review work, it can handle the needs of large-scale service deployment, freeing security experts from heavy daily reviews and reducing the cost of security operations.

[0102] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the service deployment method provided in any embodiment of this invention.

[0103] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming 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 local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0104] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0105] It should be noted that the collection, use, storage, sharing, and transfer of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations, and require notification to the user and obtaining the user's consent or authorization. Where applicable, user personal information has undergone de-identification and / or anonymization and / or encryption technical processing. In addition, a corresponding operation entry is provided for the user to choose to agree to or reject the automated decision result; if the user chooses to reject, the process proceeds to the expert decision-making process.

[0106] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A service deployment method, characterized in that, Applied to a distributed service cluster, the distributed service cluster includes a management node, a first worker node, a second worker node, and a storage node, wherein multiple types of verification containers are deployed on the first worker node, the method includes: The management node obtains the service deployment request submitted by the client, retrieves multiple resource objects configured for the target service from the service deployment request, determines the corresponding type of verification container based on the multiple resource objects, and sends the multiple resource objects to the corresponding type of verification container; The multi-type verification containers verify the corresponding resource objects and obtain the verification results. The management node determines the overall verification result of the target service based on the verification results fed back by the multiple verification containers. If the overall verification result is passed, the management node persists the multiple resource objects of the target service to the storage node. The second working node creates a container instance for the target service locally based on the multiple resource objects of the target service stored in the storage node.

2. The method according to claim 1, characterized in that, The various types of verification containers include basic compliance verification containers, native object verification containers, and extended object verification containers; The management node determines a corresponding type of verification container based on the multiple resource objects, and sends the multiple resource objects to the corresponding type of verification container, including: The management node identifies native resource objects and extended resource objects from the plurality of resource objects, sends the plurality of resource objects to the basic compliance verification container, sends the native resource objects to the native object verification container, and sends the extended resource objects to the extended object verification container; Correspondingly, the multi-type verification containers verify the corresponding resource objects to obtain verification results, including: The basic compliance verification container performs basic compliance verification on the multiple resource objects to obtain basic compliance verification results; the native object verification container performs deep security verification on the native resource objects to obtain deep security verification results; and the extended object verification container performs customized security verification on the extended resource objects to obtain customized security verification results.

3. The method according to claim 2, characterized in that, The management node identifies native resource objects and extended resource objects from the plurality of resource objects, including: The management node identifies native resource objects and extended resource objects from the multiple resource objects based on a pre-configured resource list. When the pre-configured resource list is the native resource list, the management node determines the resource objects belonging to the native resource list among the multiple resource objects as native resource objects, and determines the resource objects not belonging to the native resource list as extended resource objects; When the pre-configured resource list is an extended resource list, the management node determines the resource objects belonging to the extended resource list as extended resource objects and the resource objects not belonging to the extended resource list as native resource objects.

4. The method according to claim 2, characterized in that, Before the management node sends the multiple resource objects to the basic compliance verification container, sends the native resource objects to the native object verification container, and sends the extended resource objects to the extended object verification container, the process further includes: The management node determines the verification range based on real-time conditions. When the verification scope is a comprehensive verification, the management node sends the multiple resource objects to the basic compliance verification container, sends the native resource objects to the native object verification container, and sends the extended resource objects to the extended object verification container.

5. The method according to claim 4, characterized in that, After the management node determines the verification range based on real-time conditions, it also includes: When the verification range is partial verification, the management node sends the extended resource object to the extended object verification container.

6. The method according to claim 4 or 5, characterized in that, The management node determines the verification range based on real-time conditions, including: The management node is identified as the importance level configured for the target service. If the importance level exceeds a preset level, the management node determines that the verification scope is a full verification. If the importance level does not exceed a preset level, the management node determines that the verification range is partial verification.

7. The method according to claim 4 or 5, characterized in that, The management node determines the verification range based on real-time conditions, including: The management node determines the number of unprocessed service deployment requests; If the number of unprocessed items does not exceed a preset number, the management node determines that the verification scope is a full verification. If the number of unprocessed items exceeds a preset number, the management node determines that the verification range is a partial verification.

8. The method according to claim 2, wherein a verification configuration container is further deployed on the first working node, and the native object verification container performs deep security verification on the native resource object, including: The native object verification container obtains the corresponding native resource security verification configuration from the verification configuration container according to the type of the native resource object, and performs deep security verification on the native resource object according to the native resource security verification configuration. The deep security verification includes at least one of the following: Validation of container security context; Verification of resource quotas and restrictions; Verification of network-exposed configurations; Verification of storage volume configuration.

9. The method according to claim 2, wherein a verification configuration container is further deployed on the first working node, and the extended object verification container performs customized security verification on the extended resource object, including: The extended object verification container obtains the corresponding structure definition pattern and business security configuration from the verification configuration container according to the type of the extended resource object; The extended object verification container verifies the structural conformity of the extended resource object based on the structure definition pattern; The extended object verification container verifies the compliance of the business parameters and operational logic defined in the extended resource object based on the business security configuration.

10. The method according to claim 1, characterized in that, The distributed service cluster further includes a scheduling node. The second worker node creates a container instance locally for the target service based on multiple resource objects of the target service stored in the storage node, including: The scheduling node responds to the multiple resource objects of the target service stored in the storage node and sends a scheduling instruction to the second working node; The second working node responds to the scheduling instruction and creates a container instance for the target service locally based on the multiple resource objects of the target service stored in the storage node.

11. A distributed service cluster, characterized in that, It includes a management node, a first working node, a second working node, and a storage node, with multiple types of verification containers deployed on the first working node; The management node is used to obtain service deployment requests submitted by clients, obtain multiple resource objects configured for the target service from the service deployment requests, determine the corresponding type of verification container based on the multiple resource objects, and send the multiple resource objects to the corresponding type of verification container. The various verification containers are used to verify the corresponding resource objects and obtain the verification results; The management node is also used to determine the overall verification result of the target service based on the verification results fed back by the multiple verification containers, and if the overall verification result is passed, to persistently store multiple resource objects of the target service to the storage node. The second working node is used to create a container instance for the target service locally based on the multiple resource objects of the target service stored in the storage node.

Images