A chang'an chain network automatic deployment method based on Kubernetes operator

Abstract

The application discloses a Chang'an chain network automatic deployment method based on a Kubernetes Operator, and a core scheme of the method is to define double-layer custom resources (CRD): ChainMakerNetwork is used for declaring chain-level global configuration, and ChainMakerNode is used for declaring node-level configuration; through collaborative work of a node controller and a network controller, the node controller first generates an identity for each node and reports the identity to a resource state field; after the network controller monitors that all dependent items are ready, the network controller aggregates information to generate a global chain configuration file; the scheme mechanism breaks a circular dependency of 'node startup dependent network configuration, and network configuration generation dependent on node identity', realizes one-key and declarative deployment and full life cycle management of the Chang'an chain network in a Kubernetes environment, and greatly improves deployment efficiency, reliability and operation and maintenance automation level.

Description

Technical Field

[0001] This invention relates to the field of automated deployment technology for blockchain infrastructure, and to a method for managing the configuration, deployment, and lifecycle management of Chang'an Chain network nodes using the Kubernetes Operator pattern. It is applicable to containerized deployment scenarios of consortium blockchain platforms, and in particular, to an automated deployment method for the Chang'an Chain network based on Kubernetes Operator. Background Technology

[0002] Blockchain technology, especially consortium blockchains, has demonstrated enormous potential in building trusted cross-organizational collaboration platforms. As a leading domestic consortium blockchain platform, the ease and reliability of its production-level deployment are crucial for ChainMaker. In the cloud-native era, containerized deployment using Kubernetes has become standard practice. However, automated deployment of ChainMaker in a Kubernetes environment still faces significant challenges. Existing deployment methods mainly fall into the following categories: First, manual deployment, requiring administrators to manually write configuration files, distribute certificates, and start services—a cumbersome, error-prone process with extremely high maintenance costs. Second, automated deployment based on shell scripts, while enabling batch operations, lacks declarative management and self-healing capabilities, failing to effectively handle configuration drift and fault recovery. Third, simple containerized deployment, encapsulating node processes into Docker containers, still requires manual intervention for complex dependencies such as network discovery and configuration synchronization between nodes, failing to achieve true automation.

[0003] It's worth noting that other consortium blockchain platforms, such as Hyperledger Fabric, have adopted the Kubernetes Operator model for automated deployment in their fabric-operator project. However, due to fundamental differences in the underlying architecture between Chang'an Chain and Fabric, this model cannot be directly reused. In Fabric's network architecture, nodes are divided into peers and orderers, and the concept of a chain is a channel. In Fabric, node startup and chain networking are decoupled, while Chang'an Chain nodes must have complete network configuration information (such as the identity identifiers of all consensus nodes, root certificates, etc.) before startup. This leads to a unique "circular dependency" problem: generating the global network configuration requires the NodeIDs of all nodes, but the NodeIDs of nodes can only be finally determined after the node starts up, forming a "chicken and egg" circular dependency.

[0004] Furthermore, the configuration of Chang'an Chain comprises two layers: chain-level (bc.yml) and node-level (chainmaker.yml), making its management complex. Existing technologies lack an effective mechanism to coordinate the initialization sequence of multiple nodes and clearly manage this hierarchical configuration relationship. Therefore, the industry urgently needs a Kubernetes automated deployment solution that can adapt to the characteristics of the Chang'an Chain architecture and completely solve the aforementioned problems of circular dependencies, configuration management, and timing coordination. Summary of the Invention

[0005] In view of this, the purpose of this invention is to propose an automated deployment method for the Chang'an Chain network based on Kubernetes Operator that is reliable in implementation, flexible in application, high in performance and strong in maintainability.

[0006] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows:

[0007] An automated deployment method for the Chang'an Chain network based on Kubernetes Operator includes the following steps:

[0008] S01, define a first custom resource ChainMakerNetwork and at least one second custom resource ChainMakerNode, wherein ChainMakerNetwork is used to declare the chain-level global configuration of the blockchain network, and ChainMakerNode is used to declare the node-level configuration of the blockchain node. The ChainMakerNode points to its own ChainMakerNetwork through an association field. The ChainMakerNetwork includes at least a reference to the consensus node set and a reference to the trust root certificate.

[0009] S02, Deploy an Operator in a Kubernetes cluster to reconcile the first custom resource and the second custom resource, the Operator including a network controller and a node controller;

[0010] S03, in response to the creation or modification of the ChainMakerNode, the node controller completes node identity initialization to form a node identity certificate object without relying on the ChainMakerNetwork being in a ready state, and obtains the unique node identifier NodeID based on the node identity certificate object, and writes the NodeID into the status field of the corresponding ChainMakerNode.

[0011] S04, the network controller coordinates the NodeID and the readiness of the root trust certificate of each ChainMakerNode referenced by the ChainMakerNetwork. When the preset dependency conditions are met, it generates a network-level global configuration and writes it into the network-level configuration object, and updates the ChainMakerNetwork to the ready state.

[0012] S05, after the node controller detects that the ChainMakerNetwork is in a ready state, it generates a node-level configuration containing network discovery information and writes it into the node-level configuration object.

[0013] S06, the node controller creates or updates Kubernetes resources for running blockchain node instances, and mounts the network-level configuration object, the node-level configuration object, and the node identity certificate object to start running the blockchain node instance.

[0014] In this scheme S01, there are multiple second custom resources, ChainMakerNode. Each ChainMakerNode is associated with its corresponding ChainMakerNetwork through the networkRef field, and ChainMakerNetwork references multiple ChainMakerNodes in its consensus node list field.

[0015] In S02, the Operator includes the network controller corresponding to ChainMakerNetwork and the node controller corresponding to ChainMakerNode.

[0016] In S03, in response to the creation or modification of ChainMakerNode, the node controller performs node identity initialization without relying on the ChainMakerNetwork to enter the ready state, generates or references the node identity certificate Secret, calculates or extracts the unique node identifier NodeID based on the identity certificate Secret, and writes the NodeID into the status.nodeId field of the corresponding ChainMakerNode.

[0017] In S04, the network controller monitors the multiple ChainMakerNodes referenced by the ChainMakerNetwork and their status information, and performs periodic checks, including: a) whether the status.nodeId of the multiple ChainMakerNodes is ready; b) whether the trust_roots root certificate Secrets referenced in the ChainMakerNetwork exist and can be read; if any check is not satisfied, it waits and retryes; when the check is satisfied, it aggregates the NodeIDs of each node and the root certificate content to generate a global chain configuration file bc.yml, writes the global chain configuration file bc.yml into the global ConfigMap, and updates the status.phase of the ChainMakerNetwork to Ready.

[0018] In S05, after the node controller detects that the status.phase of the ChainMakerNetwork referenced by the networkRef field is Ready, it automatically discovers the Service addresses of each node under the same ChainMakerNetwork based on the Kubernetes API to generate a P2P seeds list, and generates the node configuration file chainmaker.yml in combination with the identity certificate Secret, and writes the node configuration file chainmaker.yml into the node's private ConfigMap.

[0019] In S06, the node controller creates and manages corresponding Kubernetes resources for each ChainMakerNode to deploy blockchain node instances. The Kubernetes resources include PersistentVolumeClaim, Service, and Deployment. Then, the global ConfigMap, the node private ConfigMap, and the identity certificate Secret are mounted in the Pod created by the Deployment, enabling the blockchain node instance to read the global chain configuration file bc.yml and the node configuration file chainmaker.yml to start running.

[0020] As a possible implementation, further, the chain-level global configuration of ChainMakerNetwork in this solution includes at least the chain identifier (chainId), version information, consensus algorithm configuration (consensus), secret reference of trust_roots certificates, virtual machine (VM) configuration parameters, and global parameters for blocks and transactions; wherein, the consensus algorithm configuration (consensus) includes the consensus algorithm type and its parameters, and a reference to the consensus node list (consensus.nodes); the network controller generates the global chain configuration file (bc.yml) based on the chain-level global configuration. The node-level configuration of ChainMakerNode in this solution includes at least the node's organization identifier (orgId), node identity configuration (identity), P2P network configuration (p2p), RPC service configuration (rpc), and storage configuration (storage); wherein, the storage configuration (storage) includes at least the storage engine type, data directory, and the storage class and capacity requirements of the corresponding PersistentVolumeClaim.

[0021] As one possible implementation, the node identity initialization described in this solution further includes one of the following modes:

[0022] (1) Enrollment mode: The node controller creates a one-time Kubernetes Job or initiates a certificate application process to ChainMaker CA via HTTP request to obtain the node signing certificate and TLS certificate and their private key, and writes the obtained certificate and private key into the node identity certificate Secret managed by the Operator;

[0023] (2) secretName mode: The node controller directly references the certificate and private key that the user has pre-generated and stored in the Secret as the node identity certificate Secret.

[0024] As a possible implementation, the node controller in this scheme further extracts or calculates the NodeID based on the TLS certificate in the node identity certificate Secret. The NodeID is a unique identifier of the node calculated based on the TLS certificate, and the NodeID is written into the status.nodeId field of the ChainMakerNode.

[0025] As a possible implementation, further, during the periodic checks, if the status.nodeId of any referenced ChainMakerNode is not ready or any trust_roots root certificate Secret does not exist, the network controller of this solution sets the status.phase of the ChainMakerNetwork to WaitingForDependencies and re-queues the network for the next round of checks after a preset delay. The trust_roots root certificate Secrets in this solution are provided by multiple organizations, and the network controller reads the root certificate content from each Secret referenced by the trust_roots root certificate Secrets and aggregates it into the trust_roots configuration section of the global chain configuration file bc.yml.

[0026] As one possible implementation, the automatic discovery of the node controller in this solution further includes: querying a set of Services with preset network identifier tags via the Kubernetes API, and assembling the cluster DNS address and P2P port of the Service into the P2P seeds list. When generating the node configuration file chainmaker.yml, the node controller in this solution further combines the configuration override ConfigOverride in ChainMakerNode to merge or override the preset template configuration to generate the final node configuration file. The Deployment, Service, PersistentVolumeClaim, ConfigMap, and Secret generated by the node controller for the ChainMakerNode in this solution all establish an ownership relationship with the ChainMakerNode through ownerReferences to achieve automatic cleanup and consistency management throughout the lifecycle of the ChainMakerNode.

[0027] As one possible implementation, the Pod template created by the Deployment in this solution may optionally include a Docker VM container for smart contracts, in addition to the main blockchain container, and simultaneously mount the global ConfigMap, the node private ConfigMap, and the identity certificate Secret via Volume mounting. After the node instance starts running, the node controller in this solution writes runtime information including the Pod IP and Service Endpoints into the status field of the corresponding ChainMakerNode and updates its status.phase to Running.

[0028] As a possible implementation, further, the network controller in this scheme calculates the hash of the spec field of ChainMakerNetwork and compares it with status.lastAppliedSpecHash, creating and monitoring a Kubernetes Job upon initial creation or configuration change; wherein the Kubernetes Job cyclically checks the readiness of status.nodeId and trust_roots root certificate Secret in its Pod, generates the global chain configuration file bc.yml and creates or updates the global ConfigMap after the dependency is satisfied; and in the case of configuration change, the Kubernetes Job generates an on-chain configuration update transaction based on the differences between the old and new configurations and submits it to the blockchain network via gRPC and waits for confirmation.

[0029] By adopting the above technical solution, the beneficial effects of the present invention compared with the prior art include:

[0030] (1) Reduce deployment complexity: In this solution, users only need to declare the desired state of the network and nodes. The system can automatically complete dozens of steps such as certificate generation, configuration file generation, service discovery, and resource creation by loading the algorithm, which reduces the manual deployment that originally took several hours to minutes.

[0031] (2) Improve configuration consistency: This solution ensures that the global configuration is strictly consistent across all nodes through a two-layer CRD model, avoiding problems such as version inconsistency and certificate mismatch that are easy to occur during manual configuration, and reducing the network configuration error rate.

[0032] (3) Enhance system reliability: This solution uses Operator to continuously monitor resource status and automatically handle abnormal situations such as node failure and configuration drift.

[0033] (4) Supports declarative operation and maintenance: This solution can realize operation and maintenance operations such as node expansion, configuration change, and version upgrade by modifying the CRD. All changes have complete audit logs, which conforms to GitOps best practices.

[0034] (5) Improve resource utilization: Each node in this solution runs in an independent Pod to achieve fault domain isolation. At the same time, by utilizing the resource scheduling capabilities of Kubernetes, multiple blockchain networks can be deployed in the same cluster, which greatly improves resource utilization.

[0035] (6) Simplified scalability: The dual-controller architecture involved in this solution has clear responsibilities and is easy to expand. Support for new types of nodes can be added independently or the network controller can be enhanced to support cross-cluster deployment without modifying the core coordination logic. Attached Figure Description

[0036] Figure 1 This is a data interaction diagram of two levels of custom resources defined in this embodiment of the solution;

[0037] Figure 2 This is a schematic diagram illustrating the relationship between the Operator and native K8S resources in this embodiment.

[0038] Figure 3 This embodiment of the solution demonstrates the ownership relationship of various resources and the division of responsibilities among controllers in Solution 1 from the perspective of a Kubernetes cluster.

[0039] Figure 4 In this embodiment of the solution, the NodeID is reported in the status field of the node CRD, thus breaking the interaction pattern that "nodes need network configuration to start".

[0040] Figure 5 This is a schematic diagram of the interaction process in the status reporting coordination mode in this embodiment of the solution;

[0041] Figure 6 This embodiment of the solution describes the coordination relationship between node resources and Job resources in different organizations under the Bootstrap Job mode.

[0042] Figure 7 This is a schematic diagram of the interaction mechanism in the Bootstrap Job mode in this embodiment of the solution;

[0043] Figure 8 This is a schematic diagram of the interaction flow in the Bootstrap Job mode in this embodiment of the solution. Detailed Implementation

[0044] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0045] The following is an explanation of some of the English terms used in this embodiment:

[0046] CRD: CustomResourceDefinition, is the most popular API extension mechanism in Kubernetes. It allows developers to declare new resource types without modifying the core code.

[0047] CR: Custom Resources

[0048] Controller: The controller is a key component in Kubernetes that implements "declarative" APIs and "self-healing" capabilities. It ensures that the system operates as expected by constantly reconcileing the actual state with the expected state.

[0049] Operator: A custom Kubernetes controller that encapsulates domain-specific knowledge (such as creating blockchain nodes and networking) to achieve full lifecycle management of custom resources.

[0050] ChainMaker: Chang'an Chain.

[0051] trust_roots: The trust roots configured in Chang'an Chain are usually the root certificates of organizations participating in the blockchain network.

[0052] Hyperledger Fabric: An open-source blockchain platform designed for enterprise applications.

[0053] peer: A node type in Hyperledger Fabric.

[0054] orderer: A node type in Hyperledger Fabric.

[0055] The technical approach of this solution includes the following:

[0056] 1. Overall Architecture Design

[0057] 1.1 Dual-layer CRD design concept

[0058] This solution adopts a two-layer custom resource definition (CRD) model, which follows the core design principles below:

[0059] (1) Separation of Responsibilities: Chain-level configuration is clearly separated from node-level configuration. The ChainMaker blockchain has two types of configuration files: global chain configuration (bc.yml) and node configuration (chainmaker.yml). The global chain configuration (bc.yml) is completely consistent across all nodes, belonging to the network-shared configuration; the node configuration (chainmaker.yml) only applies to a single node, belonging to the node's private configuration. The two-layer CRD architecture directly maps this configuration hierarchy: the ChainMakerNetwork CRD manages the global chain configuration, and the ChainMakerNode CRD manages the node configuration, ensuring clear configuration management responsibilities.

[0060] (2) Resource isolation: Each node instance runs in an independent Kubernetes Pod, which achieves fault domain isolation. The failure or maintenance operation of a single node will not affect other nodes. At the same time, by utilizing Kubernetes' resource scheduling and quota mechanisms, multiple blockchain networks can be deployed in the same cluster, improving resource utilization.

[0061] (3) Automated Management: The Operator automatically handles complex tasks such as configuration generation, service discovery, and certificate management. Users only need to declare the desired state (e.g., "a blockchain network with 4 consensus nodes is required"), and the system automatically completes all steps from certificate generation, configuration file rendering, service creation to network setup without manual intervention.

[0062] (4) Declarative Operations: All operations and maintenance are implemented by modifying the declarative configuration of the CRD. Node expansion only requires adding ChainMakerNode resources and updating the consensus.nodes list of ChainMakerNetwork; configuration changes only require modifying the corresponding fields, and the Operator automatically performs rolling updates; version upgrades only require modifying the image field. All changes have complete Git history and audit logs, which conforms to GitOps best practices.

[0063] 1.2 The Technical Starting Point for Abstracting the ChainMakerNetwork CRD

[0064] The network architecture of the ChainMaker blockchain dictates the adoption of a two-layer CRD design, unlike some blockchain platforms that use only a single layer of node resources. The considerations for this include the following:

[0065] (1) Requirements for the sharing and consistency of global configuration: The global chain configuration (bc.yml) must be completely consistent across all nodes, including the consensus node list, the list of trust root certificates, block parameters, etc. If each node manages its own independent copy of the chain configuration, the following problems may occur:

[0066] ① Network splitting caused by inconsistent configurations, with different nodes identifying different sets of consensus nodes;

[0067] ② The cost of redundant configuration and maintenance: the same configuration needs to be declared repeatedly in multiple node resources;

[0068] ③ Synchronization difficulties during configuration updates require updating the configuration of all nodes simultaneously and coordinating the restart order. By centrally managing global configurations through the ChainMakerNetwork CRD, a globally shared ConfigMap is generated. All node Pods mount the same ConfigMap, ensuring configuration consistency from the source.

[0069] (2) Unified Management of Trust Roots: The `trust_roots` section in the chain configuration defines the root CA certificates of all participating organizations, which is the foundation for establishing cross-organizational trust. In consortium blockchain scenarios, multiple organizations typically participate, each with its own CA system. Unifying the management of trust root references across all organizations through ChainMakerNetwork facilitates the following three points:

[0070] ① The trust root list is updated uniformly when a new organization joins;

[0071] ② Centralized management of changes during certificate rotation;

[0072] ③ It conforms to the governance model of multi-party collaboration in consortium blockchains, and the network-level configuration is jointly determined by all participants.

[0073] (3) Clarity of the scope of impact of configuration changes: Changes to node configurations (such as log level and RPC port) only affect a single node and can be updated independently on a rolling basis; however, changes to chain configurations (such as consensus algorithm parameters and block size) will affect all nodes, requiring coordination of the update order of all nodes, and may even require a network-wide shutdown for maintenance. Separating the two types of configurations allows for a clear distinction of the scope of impact of changes, enabling a more granular change control strategy.

[0074] (4) Strong coupling between chain networking and node startup: In Hyperledger Fabric, nodes (peers / orderers) can start independently without joining any channel, and chain networking (channel creation) is a business layer operation, decoupled from infrastructure deployment. However, in ChainMaker, nodes must have complete network information (including the NodeIDs and root certificates of all consensus nodes) configured before startup. If the configuration is incomplete, the node will fail to start normally. This strong coupling requires that the global chain configuration must be prepared before node deployment, and the generation of the global chain configuration depends on the identity information of all nodes, forming a chicken-and-egg circular dependency problem.

[0075] Therefore, by abstracting the ChainMakerNetwork CRD separately, the responsibilities of "waiting for all nodes to be identified" and "generating global configuration" can be centralized in the network controller, simplifying the logic of the node controller.

[0076] 1.3 CRD Resource Definition

[0077] Combination Figure 1 As shown, this solution defines two levels of custom resources, including:

[0078] First layer: ChainMakerNetwork CRD (chain level)

[0079] The ChainMakerNetwork CRD (chain-level) represents the global configuration of the entire blockchain network, corresponding to the ChainMaker bc.yml configuration file. The bc.yml configuration file includes: 1. Chain identifier (chainId) and version information; 2. Consensus algorithm configuration (consensus): including consensus algorithm type (TBFT / Raft / DPOS, etc.), block time, timeout parameters, and consensus node list references (referencing ChainMakerNode resources by node name); 3. Secret references for trust root certificates (trust_roots): each organization provides a Secret containing the root CA certificate, and the network controller reads the certificate content from these Secrets and aggregates it into bc.yml; 4. Virtual machine configuration (vm): supports configuration parameters for smart contract execution engines such as Docker VM, Gasm VM, and EVM; 5. Global parameters related to blocks and transactions: such as block size limit, transaction timeout time, gas price, etc.

[0080] Second layer: ChainMakerNode CRD (node ​​level)

[0081] ChainMakerNode CRD (node ​​level) represents a single blockchain node instance, corresponding to the ChainMaker.yml configuration file. The chainmaker.yml configuration file contains:

[0082] 1. The organization identifier (orgId) to which the node belongs: used for access control and certificate issuance;

[0083] 2. Node Identity Configuration: Supports two modes: ① Enrollment mode: The node controller automatically sends a certificate request to ChainMaker CA to obtain the node's signing certificate and TLS certificate; ② SecretName mode: Uses a certificate pre-generated by the user and stored in the Secret, suitable for offline environments or scenarios with strict certificate management processes.

[0084] 3. P2P network configuration (p2p): This includes listening address, listening port, maximum number of connections, seed node address, etc. The node controller will automatically find other nodes in the same network and populate the seed node list through the service discovery mechanism.

[0085] 4. RPC service configuration (RPC): including gRPC port, HTTP port, TLS configuration, rate limiting parameters, etc.

[0086] 5. Storage Configuration: This includes the storage engine type (LevelDB / BadgerDB / MySQL, etc.), data directory, storage class and capacity requirements of persistent volume declarations (PVCs);

[0087] 6. Reference to the ChainMakerNetwork (networkRef): This field establishes the relationship between a node and the network. The node controller obtains the global chain configuration through this reference.

[0088] Regarding the resource reference relationship between two levels of custom resources, this solution includes the following:

[0089] ChainMakerNode references ChainMakerNetwork through the networkRef field, forming a "node → network" attribution reference.

[0090] The `consensus.nodes` field in `ChainMakerNetwork` references the names of multiple `ChainMakerNode`s, forming a reverse reference from "network → node".

[0091] This bidirectional referencing relationship forms a complete resource hierarchy, realizing the design principles of separation of responsibilities and resource isolation. The network controller can find all consensus nodes and read their status.nodeId through the reference list, while the node controller can find the global configuration ConfigMap of its network through networkRef.

[0092] 2. Dual-controller coordination mechanism

[0093] In this solution, each CRD corresponds to an independent Kubernetes Controller, and the two Controllers coordinate through state passing and event listening. Since the ChainMaker node, in addition to its own chainmaker.yml configuration, also strongly depends on a network-shared bc.yml configuration, the two Controllers need to work closely together to achieve network initialization.

[0094] Combination Figure 2 As shown, Figure 2 This demonstrates the relationship between the Operator and native Kubernetes resources.

[0095] in, Figure 2 The relationships within (as shown in the diagram) are explained below:

[0096] 1. CRD → API Server

[0097] CRDs define the schema of custom resources and register them with the Kubernetes API.

[0098] 2. CR → API Server

[0099] Users create Custom Resource instances (such as BlockchainNetwork).

[0100] 3. API Server → Controller

[0101] The Controller listens for CR events (create / update / delete) through the Informer mechanism.

[0102] 4. Operator Deployment → Operator Pod

[0103] Deployment manages the lifecycle of Operator Pods (self-healing / rolling updates).

[0104] 5. Operator Pod → Controller

[0105] The Controller runs as the core process within a container inside the Operator Pod.

[0106] 6-9. Controller → Managed Resources

[0107] The controller performs the following operations based on the CR's spec:

[0108] (1) Create a business Pod (running a blockchain node);

[0109] (2) Generate a ConfigMap (to store non-sensitive configurations);

[0110] (3) Generate a Secret (to store the TLS certificate / key);

[0111] (4) Create a Service (expose network endpoints).

[0112] 10-11. Business Pod → Config / Secret

[0113] Business Pods mount configurations and keys via volume mounts.

[0114] 12. Business Pod → Service

[0115] A Service exposes a business Pod as a network endpoint accessible both inside and outside the cluster.

[0116] In summary, this implementation plan proposes an automated deployment method for the Chang'an Chain network based on Kubernetes Operator, which includes the following steps:

[0117] S01, define a first custom resource ChainMakerNetwork and multiple second custom resources ChainMakerNode, wherein ChainMakerNetwork is used to declare the chain-level global configuration of the blockchain network, and ChainMakerNode is used to declare the node-level configuration of the blockchain node. Each ChainMakerNode is associated with its corresponding ChainMakerNetwork through the networkRef field. ChainMakerNetwork references multiple ChainMakerNodes in its consensus node list field.

[0118] S02, Deploy the network controller corresponding to ChainMakerNetwork and the node controller corresponding to ChainMakerNode;

[0119] S03, in response to the creation or modification of ChainMakerNode, the node controller performs node identity initialization without relying on the ChainMakerNetwork entering the ready state, generates or references the node identity certificate Secret, calculates or extracts the unique node identifier NodeID based on the identity certificate Secret, and writes the NodeID into the status.nodeId field of the corresponding ChainMakerNode.

[0120] S04, the network controller monitors the multiple ChainMakerNodes referenced by the ChainMakerNetwork and their status information, and performs periodic checks, including: a) whether the status.nodeId of the multiple ChainMakerNodes is ready; b) whether the trust_roots root certificate Secrets referenced in the ChainMakerNetwork exist and can be read; if any check is not satisfied, wait and retry; when the check is satisfied, aggregate the NodeID of each node and the root certificate content to generate a global chain configuration file bc.yml, write the global chain configuration file bc.yml into the global ConfigMap, and update the status.phase of the ChainMakerNetwork to Ready;

[0121] S05, after the node controller detects that the status.phase of the ChainMakerNetwork referenced by the networkRef field is Ready, it automatically discovers the Service address of each node under the same ChainMakerNetwork based on the Kubernetes API to generate a P2P seeds list, and generates the node configuration file chainmaker.yml in combination with the identity certificate Secret, and writes the node configuration file chainmaker.yml into the node's private ConfigMap.

[0122] S06, the node controller creates and manages corresponding Kubernetes resources for each ChainMakerNode to deploy blockchain node instances. The Kubernetes resources include PersistentVolumeClaim, Service, and Deployment. Then, the global ConfigMap, the node private ConfigMap, and the identity certificate Secret are mounted in the Pod created by the Deployment, so that the blockchain node instance reads the global chain configuration file bc.yml and the node configuration file chainmaker.yml to start running.

[0123] In S01 of this scheme, the chain-level global configuration of the ChainMakerNetwork includes at least the chain identifier (chainId), version information, consensus algorithm configuration (consensus), secret reference of the trust root certificate (trust_roots), virtual machine (VM) configuration parameters, and global parameters for blocks and transactions; wherein, the consensus algorithm configuration (consensus) includes the consensus algorithm type and its parameters, and a reference to the consensus node list (consensus.nodes). In S02 of this scheme, the network controller generates the global chain configuration file (bc.yml) based on the chain-level global configuration. In S01 of this scheme, the node-level configuration of the ChainMakerNode includes at least the node's organization identifier (orgId), node identity configuration (identity), P2P network configuration (p2p), RPC service configuration (rpc), and storage configuration (storage); wherein, the storage configuration (storage) includes at least the storage engine type, data directory, and the storage class and capacity requirements of the corresponding PersistentVolumeClaim.

[0124] In this scheme S03, the node identity initialization includes one of the following modes:

[0125] (1) Enrollment mode: The node controller creates a one-time Kubernetes Job or initiates a certificate application process to ChainMaker CA via HTTP request to obtain the node signing certificate and TLS certificate and their private key, and writes the obtained certificate and private key into the node identity certificate Secret managed by the Operator;

[0126] (2) secretName mode: The node controller directly references the certificate and private key that the user has pre-generated and stored in the Secret as the node identity certificate Secret.

[0127] Based on the above, the node controller in this solution extracts or calculates the NodeID based on the TLS certificate in the node identity certificate Secret. The NodeID is a unique identifier of the node calculated based on the TLS certificate, and the NodeID is written into the status.nodeId field of the ChainMakerNode.

[0128] In this scheme S04, during the periodic check process, when the status.nodeId of any referenced ChainMakerNode is not ready or the trust_roots root certificate Secret does not exist, the network controller sets the status.phase of the ChainMakerNetwork to WaitingForDependencies and re-queues the next round of checks after a preset delay.

[0129] In scheme S04, the trust_roots root certificate secrets are provided by multiple organizations. The network controller reads the root certificate content from each secret referenced by the trust_roots root certificate secrets and aggregates it into the trust_roots configuration section of the global chain configuration file bc.yml. In scheme S05, the automatic discovery of the node controller includes: querying a set of Services with preset network identifier tags through the Kubernetes API, and assembling the cluster DNS address and P2P port of the Service into the P2P seeds list.

[0130] In S05 of this solution, when generating the node configuration file chainmaker.yml, the node controller further combines the configuration override ConfigOverride in ChainMakerNode to merge or override the preset template configuration to generate the final node configuration file. In S06 of this solution, the Deployment, Service, PersistentVolumeClaim, ConfigMap, and Secret generated by the node controller for the ChainMakerNode all establish an ownership relationship with the ChainMakerNode through ownerReferences to achieve automatic cleanup and consistency management throughout the lifecycle of the ChainMakerNode. In S06 of this solution, the Pod template created by the Deployment may optionally include a smart contract virtual machine Docker VM container in addition to the main blockchain container, and simultaneously mount the global ConfigMap, the node private ConfigMap, and the identity certificate Secret through the Volume mounting method.

[0131] In this scheme S06, after the node instance starts running, the node controller writes runtime information including Pod IP and ServiceEndpoints into the status field of the corresponding ChainMakerNode and updates its status.phase to Running.

[0132] As a possible implementation, further, the network controller in this scheme calculates the hash of the spec field of ChainMakerNetwork and compares it with status.lastAppliedSpecHash, creating and monitoring a Kubernetes Job upon initial creation or configuration change; wherein the Kubernetes Job cyclically checks the readiness of status.nodeId and trust_roots root certificate Secret in its Pod, generates the global chain configuration file bc.yml and creates or updates the global ConfigMap after the dependency is satisfied; and in the case of configuration change, the Kubernetes Job generates an on-chain configuration update transaction based on the differences between the old and new configurations and submits it to the blockchain network via gRPC and waits for confirmation.

[0133] The advantages of this embodiment include:

[0134] (1) Dependency Inversion Breaking Mechanism: By reporting the node identity identifier in the status.nodeId field of the node CRD, the network controller can obtain the key information required for networking before the node is fully started, thereby breaking the circular dependency.

[0135] (2) Two-layer configuration mapping: The system automatically maps the two-layer CRD model to the two-layer configuration files required by ChainMaker. ChainMakerNetwork generates a global ConfigMap (bc.yml), which is shared by all nodes; ChainMakerNode generates a node-private ConfigMap (chainmaker.yml). Each node Pod mounts both layers of configurations simultaneously through the Volume mounting mechanism.

[0136] (3) Automated service discovery: During the deployment phase, the node controller automatically discovers the service addresses of other nodes in the same network through the Kubernetes API and generates a seeds list for the P2P network without the need to manually configure the connection information between nodes.

[0137] (4) State Transmission and Event-Driven Approach: Utilizing Kubernetes' Watch mechanism, the controller automatically monitors state changes of dependent resources. The node controller watches the state updates of the ChainMakerNetwork, the network controller watches the state updates of all referenced ChainMakerNodes, and changes to the global ConfigMap can trigger rolling updates of node Deployments.

[0138] (5) Flexibility in identity management: Supports two identity initialization methods—Enrollment mode (automated certificate application, reducing operational complexity) and SecretName mode (using pre-generated certificates to meet offline deployment and security compliance requirements).

[0139] This solution also proposes two example solutions for the automated deployment of the Chang'an Chain network based on Kubernetes Operator, which can be briefly defined as the status reporting coordination mode (Solution 1) and the Bootstrap Job mode (Solution 2).

[0140] Specifically, the status reporting coordination mode (Scheme 1) may include the following:

[0141] Combination Figure 3 As shown in the diagram, this diagram illustrates the ownership relationships of various resources and the division of responsibilities among controllers in Solution 1 from the perspective of a Kubernetes cluster.

[0142] The ChainMaker Operator Pod runs in the operations namespace "chainmaker-system" and contains a Network Controller and a Node Controller.

[0143] Within the target network namespace (e.g., chain1), Figure 3 The system further divides the network-level resources shared across organizations (ChainMakerNetwork CR, global chain configuration ConfigMap, and root certificate secrets for each organization) and the node regions divided by organization (e.g., Org1 / Org2). Each organization region explicitly marks the node CR, node Pod, corresponding Service, PVC (PersistentVolumeClaim), node-level ConfigMap, and identity secret.

[0144] The Network Controller is responsible for aggregating the NodeIDs and trust roots reported by nodes from various organizations to generate the global chain configuration. The Node Controller performs identity initialization and creates node-level ConfigMaps / PVCs / Services / Deployments for each organization's nodes. Node Pods ultimately run the blockchain node by mounting the global configuration and the organization's private configuration. In the diagram, each Deployment / Service / PVC / ConfigMap / Secret within each org region is derived from the corresponding ChainMakerNode resource and its ownership relationship is established through ownerReferences.

[0145] Combination Figure 4 As shown, the core innovation of this solution is to break the circular dependency that "nodes need network configuration to start, but network configuration requires the NodeIDs of all nodes" by reporting the NodeID in the status field of the node's CRD. The approach can be summarized as follows:

[0146] 1. ChainMakerNode Controller Phase 1 – Identity Initialization and NodeID Reporting

[0147] This phase is the primary task of the node controller. Entering the Ready state without relying on ChainMakerNetwork is key to breaking dependency inversion, and it includes the following steps:

[0148] (1) Obtain core configuration: Obtain the ChainMakerNode CR instance and read the ChainMakerNetwork CR referenced by its networkRef. Key point: At this time, only read the network spec for verification (such as checking whether the orgId is in the network definition), ignore its status field, and avoid dependence on the network status.

[0149] (2) Identity initialization: Check the node's identity configuration and execute the corresponding initialization logic according to different modes, including the following:

[0150] ① Enrollment Mode: Create a one-time Kubernetes Job or initiate the registration process directly with the ChainMaker CA via an HTTP request in the controller logic to obtain the node's signing certificate (sign cert) and TLS certificate (tls cert), as well as the corresponding private key. Upon successful completion, store the obtained certificate, private key, and nodeid file in a newly created Secret managed by the Operator.

[0151] ② secretName mode: Directly use the user-provided secret, which must contain a pre-generated certificate and private key file.

[0152] (3) NodeID Reporting: This is a key step in breaking the dependency cycle. Once the identity secret is ready, the controller reads node.id (NodeID is a unique identifier of the node calculated based on the TLS certificate) from it and updates its own status.nodeId field with the read NodeID value. This operation signals to the ChainMakerNetwork Controller: "This node is ready to be included in the consensus list."

[0153] (4) Status Management: After completing the NodeID reporting, if the ChainMakerNetwork is not yet in the Ready state, the controller will re-queue and wait to enter the second phase.

[0154] 2. ChainMakerNetwork Controller – Dynamic Dependency Coordination

[0155] In this solution, the core responsibility of the network controller is to generate and maintain the global configuration file bc.yml, which corresponds to a ConfigMap. The most crucial aspects of coordinating multi-node networking in the global configuration file bc.yml are the configurations of consensus.nodes and trust_roots, which include the following:

[0156] (1) Verification and initialization: Obtain ChainMakerNetwork CR, perform basic legality verification (such as chainId format, consensus algorithm type, etc.), and set its own status to Initializing or WaitingForDependencies.

[0157] (2) Parallel waiting for all dependencies: In each Reconcile loop, the controller checks whether both types of core dependencies are ready simultaneously. The mechanism includes the following:

[0158] ① Waiting for the NodeID of the consensus node: Traverse the spec.consensus.nodes list and check whether the status.nodeId of all referenced ChainMakerNodes has been filled.

[0159] ② Waiting for the root certificate Secret of the trusted organization: Traverse the spec.trustRoots list and check whether the Secret corresponding to all referenced rootSecretName has been created in the cluster.

[0160] (3) Requeuing mechanism: If any NodeID has not been reported or any trust_roots' Secret does not exist, the controller will not continue execution. It maintains the WaitingForDependencies state and requeues the dependencies, waiting for a period of time (e.g., 5 seconds) before starting a full dependency check again from the beginning. This polling mechanism is simple but very reliable, avoiding complex event subscription and notification logic.

[0161] (4) Final configuration generation and application: The controller will only perform this step when all NodeIDs and all trust_roots Secrets are ready. This includes the following:

[0162] ① Collect the NodeIDs of all consensus nodes and assemble them into the consensus.nodes configuration segment.

[0163] ② Read the contents of the root CA certificate from all the Secrets referenced by trust_roots and assemble them into the trust_roots configuration section.

[0164] ③ Combine the collected information with other configurations in the spec (chainId, vm, crypto, etc.) to form a complete bc.yml file.

[0165] ④ Store this final configuration (bc.yml) in a global ConfigMap (for example, named {network-name}-chain-config).

[0166] ⑤ Update its own status.phase to Ready and send a signal to all ChainMakerNodes: "The network is ready and final deployment can proceed."

[0167] (5) Monitoring and Updates: Continuously monitor the status of the Secret referenced by trustRoots and the ChainMakerNode referenced by consensus.nodes. If any dependency changes (e.g., an organization updates its root certificate, or a consensus node is replaced), the controller can detect the change and execute corresponding operations, such as re-executing the configuration generation steps, updating the global ConfigMap, etc. Kubernetes automatically triggers all Pods that mount the ConfigMap to perform rolling updates (if necessary). Specific operations are beyond the scope of this invention's solution.

[0168] 3. ChainMakerNode Controller Phase Two – Final Deployment

[0169] This phase can only be executed after the ChainMakerNetwork status changes to Ready:

[0170] (1) Waiting for network to be ready: The controller checks the status.phase of the ChainMakerNetwork referenced by networkRef every time it reconciles. Execution continues only when the status is Ready, which ensures that the global ConfigMap containing all NodeIDs and trust_roots is available.

[0171] (2) Service Discovery: The Kubernetes API automatically discovers the service addresses of all other ChainMakerNodes belonging to the same ChainMakerNetwork. Specifically, it queries all services with specific tags (such as chainmaker.org / network={network-name}) and assembles their cluster DNS addresses (such as node1.default.svc.cluster.local: 11301) into a seed list for the P2P network. This automatic service discovery mechanism eliminates the need for manually configuring inter-node connection information.

[0172] (3) Node configuration generation: Read the certificate and key of this node from the identity secret, combine the service discovery results, the user's configuration override in ChainMakerNode CR and other information to generate the final chainmaker.yml content, and create the node's private ConfigMap (e.g., named {node-name}-config).

[0173] (4) Kubernetes Resource Creation: Create the Kubernetes native resources required by the node in sequence, including: ① PersistentVolumeClaim (PVC): Used for persistent storage of blockchain data. ② Service: Exposes the node's P2P port and RPC port for other nodes to connect and clients to access. ③ Deployment: Manages the lifecycle of the node Pod. The Deployment Pod template contains the main blockchain container and an optional smart contract virtual machine container (Docker VM), which are mounted simultaneously through the Volume mounting mechanism: node private ConfigMap ({node-name}-config, containing chainmaker.yml); global ConfigMap ({network-name}-chain-config, containing bc.yml); identity certificate Secret ({node-name}-identity, containing signing certificate, TLS certificate and private key). ④ Ingress (optional): Configures the external access entry for the node's RPC service.

[0174] (5) Status Update and Change Response: Write runtime information such as Pod IP and Service Endpoints to the status field and update status.phase to Running. At the same time, the controller continuously monitors for changes in the global ConfigMap({network-name}-chain-config). Once a change is detected (via the Kubernetes Watch mechanism), perform the necessary operations.

[0175] In summary, combined with Figure 5 As shown, in the status reporting coordination mode, the operational logic of this deployment method can be summarized in the following steps:

[0176] S01: Operations personnel create a ChainMakerNetwork CR and several ChainMakerNode CRs using kubectl or GitOps systems, apply them to the Kubernetes API Server, and register the desired network-level and node-level states.

[0177] S02: The ChainmakerNode Controller listens for ChainMakerNode CR creation or modification events, reads key information such as networkRef and identity, completes node identity initialization according to enrollment or secretName mode, and generates or references the node identity certificate Secret.

[0178] S03: The ChainmakerNode Controller extracts the NodeID from the identity Secret, writes it to the status.nodeId field of the corresponding ChainMakerNode, and marks the node status as waiting for network readiness, forming a "node ready" signal to the Network Controller.

[0179] S04: The Network Controller listens to the ChainMakerNetwork CR and all ChainMakerNodes it references. Upon detecting a new network or configuration change, it enters the Initializing / WaitingForDependencies state and begins periodic dependency checks.

[0180] S05: In each round of checks, the Network Controller traverses the consensus.nodes and trustRoots lists, verifying that the status.nodeId of all nodes is populated and that all trust root secrets exist; if there are unready dependencies, it maintains the WaitingForDependencies state and re-queues them after a preset delay.

[0181] S06: When all NodeIDs and trust root dependencies meet the conditions, the Network Controller aggregates the chain-level parameters to generate the complete bc.yml content, creates or updates the global ConfigMap({network-name}-chain-config), and updates the status.phase of ChainMakerNetwork to Ready.

[0182] S07: After the ChainmakerNode Controller detects that the status of its ChainMakerNetwork has changed to Ready, it performs service discovery for each node, generates the ConfigMap corresponding to the node's private configuration chainmaker.yml, and creates Kubernetes resources such as PVC, Service, and Deployment in sequence.

[0183] S08: The Pod created by the node Deployment mounts the global ConfigMap, node ConfigMap, identity Secret, and persistent volume to start the ChainMaker node; the node controller (ChainmakerNode Controller) writes runtime information to ChainMakerNode.status, and subsequently triggers rolling updates based on changes to ChainMakerNetwork or ConfigMap to ensure that the actual state is consistent with the expected state.

[0184] The core implementation logic of the above scheme (Scheme 1) in the algorithm code is shown in Table 1 and Table 2 below.

[0185] Table 1. Algorithm 1: ChainMakerNetwork Controller Coordination Algorithm

[0186]

[0187] Algorithm 1 implements the core coordination logic of the ChainMakerNetwork Controller. Lines 6-23 perform dependency checks, iterating through all consensus nodes and root certificates. If any dependency is not ready, the status is updated to "waiting" and the node is requeued. Lines 25-29, after all dependencies are ready, aggregate information to generate a global chain configuration and create a ConfigMap. Lines 31-34 update the network status to "Ready," notifying the node controller that deployment can continue. The key to this algorithm is that it achieves dynamic aggregation of dependencies through polling checks, avoiding complex event listening logic.

[0188] Table 2 Algorithm 2: Two-Phase Coordination Algorithm for ChainMakerNode Controller

[0189]

[0190] This algorithm implements a two-phase coordination logic for the node controller. Lines 5-16 are Phase 1, which performs identity initialization and reports the NodeID to the status field. This is a crucial step in breaking circular dependencies. Lines 18-21 are Phase 2's waiting logic, which only continues execution when the network status becomes Ready. Lines 23-30 create all Kubernetes resources for the node and update the node status to Running. The algorithm achieves phase switching by re-queuing via a return statement and automatically triggers the next coordination using Kubernetes' Watch mechanism, eliminating the need for complex state machine management.

[0191] For the Bootstrap Job pattern (Option 2), it can include the following:

[0192] Combination Figure 6 As shown, Scheme 2 refines the coordination relationship between node resources and Job resources under different organizations, building upon Scheme 1. Within the chain1 namespace, the diagram distinguishes between cross-organization shared network-level configurations and trust roots (ChainMakerNetwork CR, global chain configuration ConfigMap, and organization root certificate secrets), independent network-level control Job areas (Bootstrap / ConfigUpdate Jobs and their Pods), and node areas divided by organization (Org1 / Org2). Each organization area contains the organization's ChainMakerNode CR, node identity secret, node-level ConfigMap, PVC, Service, Deployment, and node Pod. The Network Controller generates global chain configurations and updates on-chain configurations by creating and monitoring the Bootstrap Job / Config Update Job. The NodeController performs identity initialization and Kubernetes native resource creation for each organization's nodes, while the ConfigUpdate Job updates the network configuration.

[0193] Solution 1 breaks dependencies through NodeID reporting, but the two controllers still need to repeatedly depend on each other's state during network initialization, which introduces complexity. Solution 2 uses a Kubernetes Job to handle network initialization and configuration updates as an alternative. Its core idea is to extract the complex, time-dependent, one-time network bootstrapping and configuration update logic from the continuous coordination loop of the two controllers and encapsulate it into a dedicated, one-time Kubernetes Job. This simplifies the core controller's responsibilities, allowing it to focus more on long-term state monitoring and declarative goal alignment. Specifically, it includes the following:

[0194] 1. The ChainMaker Network Controller is transformed into a Job Lifecycle Manager.

[0195] In Option 2, the network controller no longer directly executes the complex logic of dependency waiting and configuration generation, but instead acts as a Job manager, which includes the following:

[0196] (1) Role change: from "global coordinator" to "job lifecycle manager", with responsibilities greatly simplified.

[0197] (2) Monitor spec changes: Calculate the hash value of the spec field of ChainMakerNetwork CR and compare it with the status.lastAppliedSpecHash field to determine whether a change has occurred.

[0198] (3) Job type decision: Determine which type of job to start based on the changes, including: ① If status.lastAppliedSpecHash is empty, it means it is the first creation, start bootstrap-job to perform network initialization. ② If the spec hash value changes, it means the user has modified the network configuration, start config-update-job to perform configuration changes.

[0199] (4) Job parameter passing: The network configuration (such as the list of consensus.nodes and the list of trustRoots) is passed to the Job Pod through environment variables or ConfigMap, and the Job program performs the corresponding operations accordingly.

[0200] (5) Monitor Job status: Utilize Kubernetes' Watch mechanism to monitor the execution status of the Job. In this solution, the Job has three final states: Successed, Failed, and Unknown.

[0201] ① If the job succeeds, update ChainMakerNetwork's status.phase to Ready and update status.lastAppliedSpecHash to the current hash value.

[0202] ② If the job fails, keep status.phase as Failed, record the reason for failure, and the user can fix the configuration and try again.

[0203] ③ Supports a retry mechanism for jobs, which can automatically retry a limited number of times for temporary errors (such as network timeouts).

[0204] 2. The Bootstrap Job performs a one-time online genealogy tutorial.

[0205] The Bootstrap Job is a specially designed, one-time run Kubernetes Job that encapsulates all the logic for network initialization, including the following:

[0206] (1) Role positioning: As a network creation bootstrap program, it is responsible for the complete process of waiting for dependencies to be ready, aggregating information, and generating configuration.

[0207] (2) Execution environment: It runs in an independent Job Pod, isolated from the controller Pod, and has independent computing resource quotas and failure retry policies.

[0208] (3) Core Logic: The steps executed within the Job Pod include: ① Querying all referenced ChainMakerNode resources via the Kubernetes API and checking their status.nodeId field. ② Querying all referenced Secret resources via the Kubernetes API and verifying their existence. ③ If any dependency is not ready, waiting for a period of time (e.g., 5 seconds) before rechecking, forming a loop waiting logic. ④ Once all NodeIDs and all Secrets are ready, aggregating all information: collecting the NodeID list, reading certificate content, and combining other configuration parameters. ⑤ Generating the complete bc.yml configuration file content. ⑥ Creating a global ConfigMap (e.g., {network-name}-chain-config) via the Kubernetes API and storing bc.yml in it. ⑦ The Job exits successfully, returning a status code of 0.

[0209] (4) Advantages: Complex waiting logic is encapsulated in an independent program. When it fails, you can check the logs of the Job Pod for debugging. Job management is inherently idempotent (you can safely clean up and retry after failure).

[0210] 3. Config Update Job handles network configuration changes.

[0211] When a user modifies the ChainMakerNetwork spec, the Config Update Job is responsible for synchronizing the changes to the chain, which includes:

[0212] (1) Role positioning: As a configuration update executor, it is responsible for translating the configuration changes in the CRD into configuration update transactions on the chain.

[0213] (2) Receiving Change Differences: When starting a Job, the network controller passes the difference information between the old and new configurations to the Job through environment variables or ConfigMap. For example, if a user adds a node in consensus.nodes, the difference information will identify the ID of the newly added node.

[0214] (3) Generate configuration update transactions: The Job program integrates the logic of the CMC (ChainMaker Client) tool to generate corresponding on-chain configuration update transactions based on the difference information. This is equivalent to executing commands such as `cmc chainconfigconsensusnodeadd` or `cmc chainconfig consensusnodeupdate`.

[0215] (4) Submitting transactions to the chain: Submit the generated transactions to any available node in the blockchain network through the gRPC interface.

[0216] (5) Wait for on-chain confirmation: Poll the transaction status until the transaction is packaged into a block and receives sufficient confirmation. This ensures that the configuration changes have taken effect on-chain.

[0217] (6) Optional creation / update of ConfigMap: New nodes must use the original bc.yml global configuration. Therefore, after a successful on-chain update, a global ConfigMap (e.g., {network-name}-chain-config-last) can be created / updated synchronously to reflect the latest state.

[0218] (7) Job exit: Returns status code 0 on success, and returns a non-zero status code and records error information on failure.

[0219] 4. The responsibilities of the ChainMakerNode Controller remain unchanged.

[0220] The responsibilities of the node controller are exactly the same as in Scheme 1, including the following:

[0221] (1) First stage: Perform identity initialization and report the NodeID to the status.nodeId field.

[0222] (2) Second stage: wait for the ChainMakerNetwork status to become Ready, and then create the final resources of the node (PVC, Service, Deployment, etc.).

[0223] In summary, combined with Figure 7 , Figure 8 As shown, in Bootstrap Job mode, the execution logic of this deployment method can be summarized in the following steps:

[0224] S01: Operations personnel create or update ChainMakerNetwork CR and multiple ChainMakerNode CR to register the desired state of the blockchain network and nodes in the Kubernetes cluster.

[0225] S02: The Node Controller (ChainmakerNode Controller) is the same as in Scheme 1. First, it performs identity initialization on each ChainMakerNode, creates or references the node identity Secret, and writes the NodeID to the ChainMakerNode.status.nodeId field.

[0226] S03: The Network Controller listens to the ChainMakerNetwork CR, calculates its spec hash value and compares it with status.lastAppliedSpecHash; upon detecting the first creation or configuration change, it creates a Bootstrap Job or Config Update Job resource respectively, and marks the network status as waiting for the Job to complete.

[0227] S04: Kubernetes schedules the Bootstrap Job Pod to start. The Job program loops within the Pod, querying the ChainMakerNode resources and the Secrets referenced by trustRoots of all consensus nodes through the Kubernetes API until all NodeIDs and root certificates are ready.

[0228] S05: The Bootstrap Job aggregates the NodeID, certificate, and other chain-level parameters to generate a complete bc.yml configuration, creates a global ConfigMap({network-name}-chain-config), and exits with a successful status.

[0229] S06: After the Network Controller detects that the Bootstrap Job has succeeded, it updates ChainMakerNetwork.status.phase to Ready and records the current spec hash to the status.lastAppliedSpecHash field, indicating that the configuration has been correctly applied.

[0230] S07: The Node Controller listens to the Ready state of its ChainMakerNetwork and generates node-level ConfigMaps, PVCs, Services, and Deployments for each node. After the node Pod starts, it mounts the global configuration and the node's private configuration and enters the Running state.

[0231] S08: When ChainMakerNetwork.spec changes, the Network Controller creates a Config Update Job. The Job Pod constructs an on-chain configuration update transaction based on the differences between the old and new configurations and submits it to the blockchain network. After the on-chain update is completed, the global ConfigMap can be updated synchronously.

[0232] The core implementation logic of the above scheme (Scheme 2) in the algorithm code is shown in Table 3 below.

[0233] Table 3 Algorithm 3: Network Controller Job Management Algorithm

[0234]

[0235] Algorithm 3 implements the Job management logic of the Network Controller in Scheme 2. Lines 5-12 detect the first creation and start the Bootstrap Job to perform network initialization; lines 14-19 detect a Spec change and start the ConfigUpdate Job to perform configuration updates; lines 21-27 monitor the execution status of the Job (taking Bootstrap as an example), and update the network status to Ready upon success. This algorithm decouples complex dependency waiting and configuration generation logic from the controller and encapsulates it into independent Job programs, greatly simplifying the controller's responsibilities and improving the system's maintainability and testability.

[0236] In this embodiment, Scheme 2 has the following advantages over Scheme 1:

[0237] (1) Simplify controller logic: The logic of each component is very cohesive and simple. The network controller only manages the Job lifecycle and does not involve complex dependency waiting logic, which reduces code complexity and enhances maintainability.

[0238] (2) Decoupling controller logic: There is no longer a complex "wait-notify" loop between controllers. Instead, they communicate through the native Job state of Kubernetes, decoupling their logical dependencies.

[0239] (3) Facilitates testing and debugging: The complex logic of bootstrapping and updating is encapsulated in an independent program, which can be developed, tested and debugged independently. When troubleshooting, you can directly view the logs of the Job Pod.

[0240] (4) Idempotency guarantee: Job management is inherently idempotent. If it fails, the controller can safely clean up and retry without causing side effects.

[0241] The disadvantages of Option 2 include the following:

[0242] (1) Additional maintenance required: The container images of the two programs, bootstrap and config-update, need to be developed and maintained separately.

[0243] (2) Troubleshooting link growth: When troubleshooting initialization issues, in addition to checking the controller logs, it is also necessary to check the Job Pod logs to check for link growth.

[0244] (3) Startup delay: Compared to execution directly in the controller, the scheduling of Jobs and the startup of Pods will introduce a small delay (usually a few seconds to tens of seconds).

[0245] Taking all factors into consideration, Scheme 1 proposed in this embodiment is suitable for scenarios that prioritize performance and simple deployment, while Scheme 2 is suitable for large-scale production environments that prioritize system maintainability and clear responsibilities.

Claims

1. An automated deployment method for the Chang'an Chain network based on Kubernetes Operator, characterized in that, It includes the following steps: S01, define a first custom resource ChainMakerNetwork and at least one second custom resource ChainMakerNode, wherein ChainMakerNetwork is used to declare the chain-level global configuration of the blockchain network, and ChainMakerNode is used to declare the node-level configuration of the blockchain node. The ChainMakerNode points to its own ChainMakerNetwork through an association field. The ChainMakerNetwork includes at least a reference to the consensus node set and a reference to the trust root certificate. S02, Deploy an Operator in a Kubernetes cluster to reconcile the first custom resource and the second custom resource, the Operator including a network controller and a node controller; S03, in response to the creation or modification of the ChainMakerNode, the node controller performs node identity initialization to form a node identity certificate object, obtains the unique node identifier NodeID based on the node identity certificate object, and writes the NodeID into the status field of the corresponding ChainMakerNode. S04, the network controller coordinates the NodeID and the readiness of the root trust certificate of each ChainMakerNode referenced by the ChainMakerNetwork. When the preset dependency conditions are met, it generates a network-level global configuration and writes it into the network-level configuration object, and updates the ChainMakerNetwork to the ready state. S05, after the node controller detects that the ChainMakerNetwork is in a ready state, it generates a node-level configuration containing network discovery information and writes it into the node-level configuration object. S06, the node controller creates or updates Kubernetes resources for running blockchain node instances, and mounts the network-level configuration object, the node-level configuration object, and the node identity certificate object to start running the blockchain node instance.

2. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator according to claim 1, characterized in that, In S01, there are multiple second custom resources ChainMakerNode. Each ChainMakerNode is associated with its corresponding ChainMakerNetwork through the networkRef field. ChainMakerNetwork references multiple ChainMakerNodes in its consensus node list field. In S02, the Operator includes the network controller corresponding to ChainMakerNetwork and the node controller corresponding to ChainMakerNode; In S03, in response to the creation or modification of ChainMakerNode, the node controller performs node identity initialization without relying on the ChainMakerNetwork entering the ready state, generates or references the node identity certificate Secret, calculates or extracts the unique node identifier NodeID based on the identity certificate Secret, and writes the NodeID into the status.nodeId field of the corresponding ChainMakerNode. In S04, the network controller monitors the multiple ChainMakerNodes referenced by the ChainMakerNetwork and their status information, and performs periodic checks, including: a) whether the status.nodeId of the multiple ChainMakerNodes is ready; b) whether the trust_roots root certificate Secrets referenced in the ChainMakerNetwork exist and can be read; if any check is not satisfied, it waits and retryes; when the check is satisfied, it aggregates the NodeIDs of each node and the root certificate content to generate a global chain configuration file bc.yml, writes the global chain configuration file bc.yml into the global ConfigMap, and updates the status.phase of the ChainMakerNetwork to Ready; In S05, after the node controller detects that the status.phase of the ChainMakerNetwork referenced by the networkRef field is Ready, it automatically discovers the Service address of each node under the same ChainMakerNetwork based on the Kubernetes API to generate a P2P seeds list, and generates the node configuration file chainmaker.yml in combination with the identity certificate Secret, and writes the node configuration file chainmaker.yml into the node's private ConfigMap. In S06, the node controller creates and manages corresponding Kubernetes resources for each ChainMakerNode to deploy blockchain node instances. The Kubernetes resources include PersistentVolumeClaim, Service, and Deployment. Then, the global ConfigMap, the node private ConfigMap, and the identity certificate Secret are mounted in the Pod created by the Deployment, enabling the blockchain node instance to read the global chain configuration file bc.yml and the node configuration file chainmaker.yml to start running.

3. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 1 or 2, characterized in that, The chain-level global configuration of the ChainMakerNetwork includes at least the chain identifier (chainId), version information, consensus algorithm configuration (consensus), secret reference of the trust root certificate (trust_roots), virtual machine (vm) configuration parameters, and global parameters for blocks and transactions. The consensus algorithm configuration (consensus) includes the consensus algorithm type and its parameters, and a reference to the consensus node list (consensus.nodes). The network controller generates a global chain configuration file (bc.yml) based on the chain-level global configuration. The node-level configuration of the ChainMakerNode includes at least the organization identifier (orgId) to which the node belongs, the node identity configuration (identity), the P2P network configuration (p2p), the RPC service configuration (rpc), and the storage configuration (storage); wherein, the storage configuration (storage) includes at least the storage engine type, the data directory, and the storage class and capacity requirements of the corresponding PersistentVolumeClaim.

4. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 2, characterized in that, The node identity initialization includes one of the following modes: (1) Enrollment mode: The node controller creates a one-time Kubernetes Job or initiates a certificate application process to ChainMaker CA via HTTP request to obtain the node signing certificate and TLS certificate and their private key, and writes the obtained certificate and private key into the node identity certificate Secret managed by the Operator; (2) secretName mode: The node controller directly references the certificate and private key that the user has pre-generated and stored in the Secret as the node identity certificate Secret.

5. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 2, characterized in that, The node controller extracts or calculates the NodeID based on the TLS certificate in the node identity certificate Secret. The NodeID is a unique identifier of the node calculated based on the TLS certificate, and writes the NodeID into the status.nodeId field of the ChainMakerNode.

6. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 2, characterized in that, During the periodic check, if the status.nodeId of any referenced ChainMakerNode is not ready or any trust_roots root certificate Secret does not exist, the network controller sets the status.phase of the ChainMakerNetwork to WaitingForDependencies and re-queues the next round of checks after a preset delay. The trust_roots root certificate secrets are provided by multiple organizations. The network controller reads the root certificate content from each secret referenced by the trust_roots root certificate secrets and aggregates it into the trust_roots configuration section of the global chain configuration file bc.yml.

7. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 2, characterized in that, The automatic discovery of the node controller includes: querying a set of Services with preset network identifiers via the Kubernetes API, and assembling the cluster DNS address and P2P port of the Service into the P2P seeds list; When generating the node configuration file chainmaker.yml, the node controller further combines the configuration override ConfigOverride in ChainMakerNode to merge or override the preset template configuration before generating the final node configuration file.

8. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 2, characterized in that, The Deployment, Service, PersistentVolumeClaim, ConfigMap, and Secret generated by the node controller from the ChainMakerNode all establish an ownership relationship with the ChainMakerNode through ownerReferences, so as to realize automatic cleanup and consistency management throughout the life cycle of the ChainMakerNode.

9. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 2, characterized in that, In addition to the main blockchain container, the Pod template created by the Deployment also includes a smart contract virtual machine DockerVM container, and simultaneously mounts the global ConfigMap, the node private ConfigMap and the identity certificate Secret via the Volume mounting method. After a node instance starts running, the node controller writes runtime information, including Pod IP and Service Endpoints, into the status field of the corresponding ChainMakerNode and updates its status.phase to Running.

10. The automated deployment method for the Chang'an Chain network based on Kubernetes Operator as described in claim 2, characterized in that, The network controller creates and monitors a Kubernetes Job upon initial creation or configuration change by calculating the hash of the `spec` field of the `ChainMakerNetwork` and comparing it with `status.lastAppliedSpecHash`. The Kubernetes Job then iteratively checks the readiness of the `status.nodeId` and the `trust_roots` root certificate secret within its Pod. Once the dependency is satisfied, it generates the global chain configuration file `bc.yml` and creates or updates the global `ConfigMap`. Furthermore, in configuration change scenarios, the Kubernetes Job generates an on-chain configuration update transaction based on the differences between the old and new configurations and submits it to the blockchain network via gRPC, awaiting confirmation.

Images