Method and system for automatically opening declarative ODA component

Abstract

The invention discloses a declarative ODA component automatic opening method and a declarative ODA component automatic opening system, belongs to the technical field of cloud computing micro-service architecture, and aims to solve the technical problems of how to improve the component automatic deployment degree, reduce the configuration complexity and enhance the flexibility and maintainability of the system. According to the method, a declarative programming normal form is adopted, the expected state of the component is clearly defined, and a Kubernetes platform CRD and an Operator extension mechanism are utilized to automatically configure to meet predetermined requirements, so that automatic opening of the component is realized, an operator is allowed to quickly deploy and update the component, manual intervention is not needed, and the operation and maintenance efficiency and the reliability of the system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing microservice architecture, and specifically to a declarative ODA component automatic activation method and system. Background Art

[0002] With the rapid development of cloud computing and microservice architecture, enterprises' demand for rapid deployment and flexible management of IT resources is increasing day by day. To address this challenge, Open Digital Architecture (ODA) has emerged. It was proposed by the TeleManagement Forum (TMF for short), and its core concept is to promote the decoupling and standardization of applications. Through an open component market, it constructs a diversified and vibrant partner ecosystem for telecom operators and suppliers. As an important international standard organization in the telecom field, TMF has been committed to the innovation and digital transformation of the communication industry. Since the launch of the ODA project, it has received extensive support from multiple communication service providers (CSPs) and technology partners globally. So far, TMF has released 101 OpenAPIs and 65 business component specifications, which cover the operator's B domain (business support system) and O domain (operation support system) software systems, making ODA an important driving force for the digital transformation of the telecom industry.

[0003] However, although ODA provides a standardized description and interaction method for components, in terms of the automatic activation of components, the existing technology has not realized an end-to-end automatic process. This requires developers to write a large number of configuration scripts or manually handle the component activation process during deployment, including but not limited to: component initialization configuration, configuration of OpenAPIs that the component needs to publish and depend on, configuration of the core business metric monitoring panel, and configuration of component function menus and roles.

[0004] How to improve the degree of component automatic deployment, reduce configuration complexity, and enhance the flexibility and maintainability of the system is a technical problem that needs to be solved. Summary of the Invention

[0005] The technical task of the present invention is to address the above deficiencies and provide a declarative ODA component automatic activation method and system to solve the technical problem of how to improve the degree of component automatic deployment, reduce configuration complexity, and enhance the flexibility and maintainability of the system.

[0006] In a first aspect, a declarative ODA component automatic activation method of the present invention includes the following steps:

[0007] ODA Component Model Design: Based on the ODA component specification, integrate the metadata required for end-to-end component provisioning into a declarative YAML file, and declare the core functions and related configurations of the component through the YAML file;

[0008] OAD Component Custom Resource Design: Design custom resources based on the CRD extension mechanism of Kubernetes, define the related attributes and rules of the custom resources through a YAML file, submit the custom resources to Kubernetes through the kubectl command, and access and operate the custom resources through the Kubernetes API;

[0009] OAD Component Control Design: Design a component controller using the Operator extension mechanism of Kubernetes, package the component controller code into a container image, and deploy the container image to the Kubernetes cluster in the form of a Deployment or DaemonSet. The component controller is used to monitor and respond to changes in the status of custom resources to achieve automated lifecycle management of the component and business logic;

[0010] ODA Component Management: Combine the open-source Operator resources in the Kubernetes community to achieve full-process automated management of components from configuration to deployment.

[0011] Preferably, the core functions and related configurations of the component include initialization configuration, API publishing and subscription, function permissions, role setting, business metric monitoring, traffic management, and compliance testing.

[0012] Preferably, the custom resources include Component, API, and Security;

[0013] The related attributes and rules of the custom resources include resource name, version, group, scope, fields of the resource, and validation rules;

[0014] For Component, the scope is understood as choosing the cluster scope or namespace scope as needed. The fields of the resource cover the basic information of the component, API publishing information, security setting information, event notification information, environment dependency information, and management operation information. The basic information of the component includes name and version. The validation rules ensure that the creation and update of Component resource instances comply with preset data model standards, such as validation rules for field types, formats, required fields, etc.;

[0015] For APIs, the scope is understood as selecting an appropriate scope based on the usage scope of the API. The fields of the resource include the name, description, endpoint address, protocol, and the component to which it belongs. The verification rules are used to verify the fields of the API resource instance to ensure the accuracy and integrity of the API information;

[0016] For Security, the scope is understood as determining the scope based on the applicable scope of the security configuration. The fields of the resource include the function menu of the component, security control policies, predefined roles and permissions, and default user settings. The verification rules are used to strictly verify the fields of the Security resource instance to ensure the compliance and effectiveness of the security configuration;

[0017] Correspondingly, after submitting the custom resource to Kubernetes through the kubectl command, Kubernetes allows users to create, query, update, and delete the corresponding custom resource instances through the Kubernetes API. When creating a custom resource instance, Kubernetes performs verification according to the preset data model standards and verification rules, and stores the verified instances in the etcd database.

[0018] Preferably, the component controller includes:

[0019] Component Operator, used to manage the component lifecycle;

[0020] APIOperator, used to publish and subscribe to the OpenAPI of the component;

[0021] Security Operator, used to automatically configure the identity service;

[0022] Test Operator, used to perform compliance tests and update the test results;

[0023] Prometheus Operator, used to configure the component core business monitoring panel;

[0024] Istio Operator, used to configure the component traffic management rules.

[0025] Preferably, combined with the Operator resources open-sourced by the Kubernetes community, the full-process automated management of the component from configuration to deployment is realized, including the following:

[0026] Complete the configuration of the component business monitoring panel through Prometheus Operator to ensure the stable operation of the service;

[0027] Configure traffic management rules through the Isito Operator to optimize traffic scheduling and distribution between services.

[0028] In a second aspect, a declarative ODA component automated provisioning system of the present invention is used to automatically provision an ODA component through a declarative ODA component automated provisioning method as described in any item of the first aspect. The system includes an ODA component model design module, an OAD component custom resource design module, an OAD component control design module, and an ODA component management module;

[0029] The ODA component model design module is used to perform the following: Based on the ODA component specification, integrate the metadata required for end-to-end provisioning of the component into a declarative YAML file, and declare the core functions and related configurations of the component through the YAML file;

[0030] The OAD component custom resource design module is used to perform the following: Design custom resources based on the CRD extension mechanism of Kubernetes, define the related attributes and rules of the custom resources through a YAML file, submit the custom resources to Kubernetes through the kubectl command, and access and operate the custom resources through the Kubernetes API;

[0031] The OAD component control design module is used to perform the following: Design a component controller using the Operator extension mechanism of Kubernetes, package the component controller code into a container image, and deploy the container image to a Kubernetes cluster in the form of a Deployment or DaemonSet. The component controller is used to monitor and respond to changes in the status of custom resources to achieve automated lifecycle management of the component and business logic;

[0032] The ODA component management module is used to perform the following: Combine the open-source Operator resources in the Kubernetes community to achieve full-process automated management of the component from configuration to deployment.

[0033] Preferably, the core functions and related configurations of the component include initialization configuration, API publishing and subscribing, function permissions, role setting, business metric monitoring, traffic management, and compliance testing.

[0034] Preferably, the custom resources include Component, API, and Security;

[0035] The related attributes and rules of the custom resources include resource name, version, group, scope, fields of the resource, and validation rules;

[0036] For a Component, the scope is understood to select either a cluster scope or a namespace scope as needed. The fields of the resource cover the basic information of the component, API publishing information, security setting information, event notification information, environmental dependency information, and management operation information. The basic information of the component includes the name and version. The validation rules ensure that the creation and update of Component resource instances comply with the preset data model standards, such as validation rules for field types, formats, required fields, etc.;

[0037] For an API, the scope is understood to select an appropriate scope according to the usage scope of the API. The fields of the resource include the name, description, endpoint address, protocol, and the component to which the API belongs. The validation rules are used to verify the fields of the API resource instance to ensure the accuracy and integrity of the API information;

[0038] For Security, the scope is understood to determine the scope according to the applicable scope of the security configuration. The fields of the resource include the function menu of the component, security control policies, predefined roles and permissions, and default user settings. The validation rules are used to strictly verify the fields of the Security resource instance to ensure the compliance and effectiveness of the security configuration;

[0039] Correspondingly, after submitting the custom resource to Kubernetes through the kubectl command, Kubernetes allows users to create, query, update, and delete the corresponding custom resource instances through the Kubernetes API. When creating a custom resource instance, Kubernetes performs verification according to the preset data model standards and validation rules, and stores the verified instances in the etcd database.

[0040] Preferably, the component controller includes:

[0041] Component Operator, used to manage the component lifecycle;

[0042] APIOperator, used to publish and subscribe to the OpenAPI of the component;

[0043] Security Operator, used to automatically configure the identity service;

[0044] Test Operator, used to execute compliance tests and update the test results;

[0045] Prometheus Operator, used to configure the core business monitoring panel of the component;

[0046] Istio Operator, used to configure the component traffic management rules.

[0047] Preferably, for the ODA component management module, by integrating the Operator resources open-sourced by the Kubernetes community, the full-process automation management of components from configuration to deployment is realized, including the following operations:

[0048] Complete the configuration of the component business monitoring panel through Prometheus Operator to ensure the stable operation of the service;

[0049] Configure traffic management rules through Isito Operator to optimize the traffic scheduling and allocation between services.

[0050] The declarative ODA component automatic activation method and system of the present invention have the following advantages:

[0051] 1. Based on the ODA component specification, integrate the metadata required for end-to-end component activation into the declarative YAML file, declare the core functions and related configurations of the component through the YAML file, covering each link from component startup to operation, ensuring the comprehensiveness and coherence of the activation process;

[0052] 2. Adopt the declarative programming paradigm, clearly define the expected state of the component, and use the CRD and Operator extension mechanisms of the Kubernetes platform to automatically configure to meet the predetermined requirements, thereby realizing the automatic activation of the component, allowing the operator to quickly deploy and update the component without manual intervention, improving the operation and maintenance efficiency and the reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0054] The present invention will be further described below in conjunction with the drawings.

[0055] Figure 1 It is a flowchart of a declarative ODA component automatic activation method for Embodiment 1;

[0056] Figure 2 It is a timing diagram of declarative ODA component automatic activation in a declarative ODA component automatic activation method for Embodiment 1. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0057] The present invention will be further described below in conjunction with the accompanying drawings and specific embodiments, so that those skilled in the art can better understand the present invention and be able to implement it. However, the embodiments cited do not limit the present invention. Without conflict, the embodiments of the present invention and the technical features in the embodiments can be combined with each other.

[0058] The embodiment of the present invention provides a declarative ODA component automated activation method and system, which are used to solve the technical problems of how to improve the degree of component automated deployment, reduce configuration complexity, and enhance the flexibility and maintainability of the system.

[0059] Embodiment 1:

[0060] A declarative ODA component automated activation method of the present invention includes ODA component model design, OAD component custom resource design, OAD component control design, and ODA component management.

[0061] Step S100, ODA component model design: Based on the ODA component specification, integrate the metadata required for end-to-end activation of the component into a declarative YAML file, and declare the core functions and related configurations of the component through the YAML file.

[0062] Among them, the core functions and related configurations of the component include initialization configuration, API publishing and subscribing, function permissions, role setting, business metric monitoring, traffic management, and compliance testing.

[0063] In this embodiment, step S100 realizes the ODA component model design. The ODA component is a standardized application that supports being interconnected through Open APIs. ODA provides a standard hexagonal metadata description format. With the help of a declarative YAML description file, the core functions of the component can be comprehensively orchestrated, including the Open APIs to be published, the dependent Open APIs, as well as security settings, event notifications, environmental dependencies, and management operations.

[0064] The method disclosed in this embodiment further innovates on the basis of the ODA specification, integrating and incorporating all the key information required for component activation, from initialization configuration to the publishing and subscribing of OpenAPI, to function permissions, role setting, business metric monitoring, traffic management, and component compliance testing, covering each link from the start to the operation of the component, ensuring the comprehensiveness and coherence of the activation process.

[0065] Step S200, OAD component custom resource design: Design custom resources based on the CRD extension mechanism of Kubernetes, define the relevant attributes and rules of the custom resources through a YAML file, submit the custom resources to Kubernetes through the kubectl command, and access and operate the custom resources through the Kubernetes API.

[0066] Among them, the custom resources include Component, API, and Security. The relevant attributes and rules of the custom resources include resource name, version, group, scope, fields of the resource, and validation rules; for Component, the scope is understood as selecting the cluster scope or namespace scope according to needs, and the fields of the resource cover the basic information of the component, API release information, security settings information, event notification information, environmental dependency information, and management operation information. The basic information of the component includes name and version, and the validation rules ensure that the creation and update of Component resource instances comply with the preset data model standards, such as validation rules for field types, formats, required fields, etc.; for API, the scope is understood as selecting an appropriate scope according to the usage range of the API, and the fields of the resource include the name, description, endpoint address, protocol, and the component to which it belongs. The validation rules are used to verify the fields of the API resource instance to ensure the accuracy and integrity of the API information; for Security, the scope is understood as determining the scope according to the applicable range of the security configuration, and the fields of the resource include the function menu of the component, security control policies, predefined roles and permissions, and default user settings. The validation rules are used to strictly verify the fields of the Security resource instance to ensure the compliance and effectiveness of the security configuration.

[0067] Correspondingly, after submitting the custom resources to Kubernetes through the kubectl command, Kubernetes allows users to create, query, update, and delete the corresponding custom resource instances through the Kubernetes API. When creating a custom resource instance, Kubernetes performs verification according to the preset data model standards and validation rules, and stores the verified instances in the etcd database.

[0068] Kubernetes provides users with a rich variety of resource types, such as resource objects, configuration objects, storage objects, and policy objects. However, in different application scenarios, traditional resource types still cannot meet the needs of users, and they may have some special requirements for the platform. To meet these needs, Kubernetes provides an abstract extended resource - Custom Resource Definition (CRD), and CRD provides us with an interface for rapid registration and use of resources.

[0069] Based on the component data model and the Kubernetes CRD (Custom Resource Definition) extension mechanism, custom resources of Component, API, and Security are designed. The resource names, versions, groups, scopes (cluster or namespace), as well as the fields and validation rules of the resources are defined through YAML. Submitting the CRD definition to Kubernetes via kubectl enables access to and operation on these custom resources through the Kubernetes API. When the platform creates an instance of a custom resource, Kubernetes will perform strict verification according to the preset data model standards and validation rules and store it in the etcd database.

[0070] Step S300, OAD component control design: Design a component controller using the Operator extension mechanism of Kubernetes, and package the component controller code as a container image. Deploy the container image to the Kubernetes cluster in the form of Deployment or DaemonSet. The component controller is used to listen for and respond to changes in the status of custom resources to achieve automated lifecycle management of components and business logic.

[0071] In this embodiment, the component controller includes the following:

[0072] (1) Component Operator, used to manage the component lifecycle;

[0073] (2) API Operator, used to publish and subscribe to the OpenAPI of the component;

[0074] (3) Security Operator, used to automatically configure the identity service;

[0075] (4) Test Operator, used to execute compliance tests and update the test results;

[0076] (5) Prometheus Operator, used to configure the core business monitoring panel of the component;

[0077] (6) Istio Operator, used to configure the component traffic management rules.

[0078] After various custom resources are put into K8S, the Operator needs to be implemented for the resources to take effect. An Operator is a controller used to manage custom resources. By listening to and responding to the status changes of CRs, it automatically executes corresponding operations according to predefined business logics to achieve the lifecycle management of CRs and the automation of business logics. The controller code of the Operator needs to be packaged into a container image and deployed to the Kubernetes cluster in the form of a Deployment or a DaemonSet to run.

[0079] To achieve zero-touch automation activation of ODA components based on events, this embodiment designs multiple component controllers, namely Operators, including the following:

[0080] (1) Component Operator: Manages the component lifecycle and is responsible for parsing metadata such as API publishing, security settings, event notifications, environmental dependencies, and management operations from the ODA component YAML, and automatically triggers corresponding activation actions based on this information.

[0081] (2) API Operator: Manages the lifecycle of OpenAPI, creates independent API resources for each OpenAPI in the core function, security, and management parts of the component. It is responsible for collecting key information such as the name, description, endpoint address, and protocol of the API, and sending this information to the API gateway or service mesh component to complete the registration, publishing, and subscription of the API.

[0082] (3) Security Operator: Responsible for extracting metadata from the ODA component and automatically configuring the identity service in the unified authentication component accordingly. It covers multiple security dimensions such as the function menu, security control policy, predefined roles and permissions, and default user settings of the component.

[0083] (4) Test Operator: Listens to the deployment status of the component, is responsible for collecting key data such as the component name, namespace, HelmChart, etc., and sending this information to the test component for compliance testing, and finally updates the test results to the component information.

[0084] Step S400, ODA component management: Integrate the Operator resources open-sourced by the Kubernetes community to achieve full-process automated management of the component from configuration to deployment.

[0085] In step S400 of this embodiment, the Operator provided by the Kubernetes community is fully utilized to achieve in-depth governance of component services, including: configuring the component business monitoring panel through the Prometheus Operator to ensure the stable operation of the service; configuring traffic management rules through the Istio Operator to optimize traffic scheduling and distribution among services.

[0086] Based on the method disclosed in this embodiment, taking the need of an operator to launch the ProductCatalog component as an example, the zero-touch automated activation of the ODA component is introduced as follows:

[0087] (1) First, the operator obtains the component Helm Chart installation package provided by the vendor, and makes necessary adjustments to the metadata attribute values in the Chart according to specific deployment requirements. Subsequently, the ProductCatalog component is deployed through Helm commands or the Canvas platform.

[0088] (2) After the deployment is executed, an application corresponding to the component will be created in the Kubernetes environment, and the relevant container services will be started. At the same time, the system will automatically create a Kubernetes custom resource object representing the ODA component, that is, the ProductCatalog Component, and its initial state is set to "In-Progress".

[0089] (3) The Kubernetes Operator continuously monitors the creation of ODA CRD objects. Once a new Component object is detected, the ComponentOperator will automatically parse the component metadata information, and create the required resource objects and trigger the corresponding activation actions based on this information, such as creating API resources for the OpenApis that the component needs to publish and depend on, creating monitoring API resources for component business metric monitoring, creating Istio resources for traffic management in the component, and creating Security resources for component function permission definition.

[0090] (4) When the Security Operator detects a Security resource of the Function type, it will collect the function name, parent menu, serial number, link, and parameter information of the component, and complete the function definition in the unified authentication component. For a Security resource of the Role type, the Operator will collect the role name, function name, and member user information, and complete the role definition in the unified authentication component, and create a component administrator user at the same time.

[0091] (5) When the API Operator detects the addition of a newly exposed OpenAPI, it will collect the detailed information of the API, such as the internal access address, security authentication protocol, etc., and send these APIs to the API gateway. The API gateway will register and open the APIs externally, and update the access address feedback by the API gateway to the API CRD object. For Dependent OpenAPI resources, the API Operator will send the component authentication information and the name of the dependent OpenAPI to the API gateway to complete the subscription of the interface;

[0092] (6) When the API Operator detects the addition of a Metrics API resource, it will collect the name, port, and interface path information of the API and submit them to the Prometheus component to complete the configuration of the component business monitoring panel;

[0093] (7) For Istio CRDs, the Operator will automatically configure the traffic management rules of Istio, such as Gateway, VirtualService, DestinationRule, etc., to achieve intelligent routing and load balancing of traffic;

[0094] (8) After all the creation actions are completed, the system will update the component status to "Complete", indicating that the component activation process has been fully executed;

[0095] (9) After the Test Operator detects that the component status is updated to "Complete", it will integrate key data such as the component name, namespace, and Helm Chart, and send this information to the test component for compliance testing. Finally, the test results will be updated to the component information.

[0096] The method of this embodiment simplifies the deployment and management process of ODA components through the declarative programming paradigm, improves the degree of automation, reduces the configuration complexity, and enhances the flexibility and maintainability of the system.

[0097] Embodiment 2:

[0098] A declarative ODA component automatic activation system of the present invention includes an ODA component model design module, an OAD component custom resource design module, an OAD component control design module, and an ODA component management module.

[0099] The ODA component model design module is used to perform the following: Based on the ODA component specification, integrate the metadata required for end-to-end activation of the component into a declarative YAML file, and declare the core functions and related configurations of the component through the YAML file.

[0100] Among them, the core functions and related configurations of the component include initialization configuration, API publishing and subscription, function permissions, role setting, business metric monitoring, traffic management, and compliance testing.

[0101] In this embodiment, the ODA component model design module implements the ODA component model design. The ODA component is a standardized application that supports interconnection through Open APIs. ODA provides a standard hexagonal metadata description format. With the help of a declarative YAML description file, the core functions of the component can be comprehensively orchestrated, including the Open APIs to be published, the dependent Open APIs, as well as security settings, event notifications, environmental dependencies, and management operations.

[0102] Based on the ODA specification of this embodiment, further innovation is carried out. The key information required for component activation, from initialization configuration to OpenAPI publishing and subscription, to function permissions, role setting, business metric monitoring, traffic management, and component compliance testing, is all integrated and incorporated into the data description file, covering each link from component startup to operation, ensuring the comprehensiveness and coherence of the activation process.

[0103] The OAD component custom resource design module is used to perform the following: design custom resources based on the CRD extension mechanism of Kubernetes, define the relevant attributes and rules of the custom resources through a YAML file, submit the custom resources to Kubernetes through the kubectl command, and access and operate the custom resources through the Kubernetes API.

[0104] Among them, custom resources include Component, API, and Security. The relevant attributes and rules of custom resources include resource name, version, group, scope, fields of the resource, and validation rules. For Component, the scope is understood as choosing the cluster scope or namespace scope as needed. The fields of the resource cover the basic information of the component, API release information, security settings information, event notification information, environmental dependency information, and management operation information. The basic information of the component includes name and version. The validation rules ensure that the creation and update of Component resource instances comply with the preset data model standards, such as validation rules for field types, formats, required fields, etc. For API, the scope is understood as choosing an appropriate scope according to the usage scope of the API. The fields of the resource include the name, description, endpoint address, protocol, and the component to which the API belongs. The validation rules are used to validate the fields of API resource instances to ensure the accuracy and integrity of API information. For Security, the scope is understood as determining the scope according to the applicable scope of the security configuration. The fields of the resource include the function menu of the component, security control policies, predefined roles and permissions, and default user settings. The validation rules are used to strictly validate the fields of Security resource instances to ensure the compliance and effectiveness of the security configuration.

[0105] Correspondingly, after submitting custom resources to Kubernetes through the kubectl command, Kubernetes allows users to create, query, update, and delete corresponding custom resource instances through the Kubernetes API. When creating a custom resource instance, Kubernetes performs validation according to the preset data model standards and validation rules, and stores the validated instances in the etcd database.

[0106] Kubernetes provides users with a rich variety of resource types, such as resource objects, configuration objects, storage objects, and policy objects. However, in different application scenarios, traditional resource types still cannot meet user needs, and they may have some special requirements for the platform. To meet these needs, Kubernetes provides an abstract extended resource - Custom Resource Definition (CRD), and CRD provides us with an interface for rapid registration and use of resources.

[0107] Based on the component data model and the Kubernetes CRD (Custom Resource Definition) extension mechanism, Component, API, and Security custom resources are designed. The resource names, versions, groups, scopes (cluster or namespace), as well as the fields and validation rules of the resources are defined through YAML. Submitting the CRD definition to Kubernetes via kubectl enables access to and operation on these custom resources through the Kubernetes API. When the platform creates an instance of a custom resource, Kubernetes will perform strict verification according to the preset data model standards and validation rules and store it in the etcd database.

[0108] The OAD component control design module is used to perform the following: Design a component controller using the Operator extension mechanism of Kubernetes, package the component controller code into a container image, and deploy the container image in the Kubernetes cluster in the form of a Deployment or DaemonSet. The component controller is used to listen for and respond to changes in the status of custom resources to achieve automated lifecycle management of components and business logic.

[0109] In this embodiment, the component controller includes the following:

[0110] (1) Component Operator, used to manage the component lifecycle;

[0111] (2) API Operator, used to publish and subscribe to the OpenAPI of the component;

[0112] (3) Security Operator, used to automatically configure the identity service;

[0113] (4) Test Operator, used to perform compliance tests and update the test results;

[0114] (5) Prometheus Operator, used to configure the component core business monitoring panel;

[0115] (6) Istio Operator, used to configure the component traffic management rules.

[0116] After various custom resources are put into K8S, the implementation of the Operator is required for the resources to take effect. An Operator is a controller used to manage custom resources. By listening to and responding to the status changes of CRs, it automatically executes corresponding operations according to predefined business logics to achieve the lifecycle management of CRs and the automation of business logics. The controller code of the Operator needs to be packaged into a container image and deployed to the Kubernetes cluster in the form of a Deployment or DaemonSet for running.

[0117] To achieve zero-touch automation activation of ODA components based on events, this embodiment designs multiple component controllers, namely Operators, including the following:

[0118] (1) Component Operator: Manages the component lifecycle, and is responsible for parsing metadata such as API publishing, security settings, event notifications, environmental dependencies, and management operations from the ODA component YAML, and automatically triggers corresponding activation actions based on this information;

[0119] (2) API Operator: Manages the lifecycle of OpenAPI, and creates independent API resources for each OpenAPI in the core function, security, and management parts of the component. It is responsible for collecting key information such as the name, description, endpoint address, and protocol of the API, and sending this information to the API gateway or service mesh component to complete the registration, publishing, and subscription of the API.

[0120] (3) Security Operator: Responsible for extracting metadata from the ODA component and automatically configuring the identity service in the unified authentication component accordingly. It covers multiple security dimensions such as the function menu, security control policies, predefined roles and permissions, and default user settings of the component.

[0121] (4) Test Operator: Listens to the deployment status of the component, is responsible for collecting key data such as the component name, namespace, HelmChart, etc., and sending this information to the test component for compliance testing, and finally updates the test results to the component information.

[0122] The ODA component management module is used to perform the following: Combining the Operator resources open-sourced by the Kubernetes community to achieve full-process automated management of the component from configuration to deployment.

[0123] In this embodiment, the ODA component management module utilizes the Operator provided by the Kubernetes community to achieve in-depth governance of component services, including: configuring the component business monitoring panel through the Prometheus Operator to ensure the stable operation of the service; and configuring traffic management rules through the Isito Operator to optimize the traffic scheduling and allocation between services.

[0124] The system of this embodiment can implement the declarative ODA component automated activation according to the method disclosed in Embodiment 1.

[0125] The above has introduced in detail the declarative ODA component automated activation method and system provided by the present invention. Specific examples are used herein to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. At the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A declarative ODA component automatic activation method, characterized in that: The steps include: ODA component model design: Based on the ODA component specification, the metadata required for end-to-end component activation is integrated into a declarative YAML file, and the core functions and related configurations of the component are declared through the YAML file; OAD component custom resource design: Design custom resources based on Kubernetes' CRD extension mechanism, define the relevant properties and rules of the custom resources through YAML files, submit the custom resources to Kubernetes through the kubectl command, and access and operate the custom resources through the Kubernetes API; OAD component control design: Utilize the Operator extension mechanism of Kubernetes to design a component controller, package the component controller code into a container image, and deploy the container image to the Kubernetes cluster in the form of Deployment or DaemonSet. The component controller is used to monitor and respond to the status changes of custom resources to achieve lifecycle management of components and automation of business logic. ODA component management: Combined with the open source Operator resources of the Kubernetes community, it realizes the full process automated management of components from configuration to deployment.

2. The declarative ODA component automatic activation method according to claim 1, characterized in that: The core functions and related configurations of the components include initial configuration, API publishing and subscription, functional permissions, role setting, business indicator monitoring, traffic management and compliance testing.

3. The declarative ODA component automatic activation method according to claim 1, characterized in that: Custom resources include Component, API, and Security; The related properties and rules of custom resources include resource name, version, group, scope, resource fields and validation rules; For Component, the scope is understood as selecting cluster scope or namespace scope as needed. The fields of the resource cover the basic information of the component, API publishing information, security setting information, event notification information, environment dependency information, and management operation information. The basic information of the component includes the name and version. The validation rules ensure that the creation and update of the Component resource instance conform to the preset data model standards, such as the validation rules of the field type, format, and required items. For API, scope means selecting an appropriate scope according to the scope of API usage. The fields of resources include the name, description, endpoint address, protocol, and component of the API. Validation rules are used to verify the fields of API resource instances to ensure the accuracy and completeness of API information. For Security, the scope is understood as determining the scope according to the applicable scope of the security configuration. The fields of the resource include the component's function menu, security control policy, predefined roles and permissions, and default user settings. The validation rules are used to strictly verify the fields of the Security resource instance to ensure the compliance and effectiveness of the security configuration. Correspondingly, after submitting custom resources to Kubernetes through the kubectl command, Kubernetes allows users to create, query, update, and delete corresponding custom resource instances through the Kubernetes API. When creating a custom resource instance, Kubernetes verifies it according to the preset data model standards and validation rules, and stores the verified instances in the etcd database.

4. The declarative ODA component automatic activation method according to claim 1, characterized in that: The component controller comprises: Component Operator, used to manage component lifecycle; APIOperator, used to publish and subscribe to components’ OpenAPI; Security Operator, which is used to automatically configure identity services; Test Operator, which performs compliance tests and updates test results; Prometheus Operator, used for configuring the component core business monitoring panel; Istio Operator, used to configure component traffic management rules.

5. The declarative ODA component automatic activation method according to claim 4, characterized in that: Combined with the open source Operator resources of the Kubernetes community, the full process of component automation management from configuration to deployment is realized, including the following: Complete the configuration of the component business monitoring panel through Prometheus Operator to ensure the stable operation of the service; Configure traffic management rules through Istio Operator to optimize traffic scheduling and distribution between services.

6. A declarative ODA component automatic activation system, characterized in that: Used to automatically activate ODA components through a declarative ODA component automatic activation method as described in any one of claims 1 to 5, the system includes an ODA component model design module, an ODA component custom resource design module, an ODA component control design module and an ODA component management module; The ODA component model design module is used to perform the following: Based on the ODA component specification, integrate the metadata required for end-to-end component provisioning into a declarative YAML file, and declare the core functions and related configurations of the component through the YAML file; The OAD component custom resource design module is used to perform the following: design custom resources based on the CRD extension mechanism of Kubernetes, define the relevant attributes and rules of the custom resources through YAML files, submit the custom resources to Kubernetes through the kubectl command, and access and operate the custom resources through the Kubernetes API; The OAD component control design module is used to perform the following: design a component controller using the Operator extension mechanism of Kubernetes, and package the component controller code into a container image, and deploy the container image to the Kubernetes cluster in the form of Deployment or DaemonSet for operation. The component controller is used to monitor and respond to the status changes of custom resources to achieve lifecycle management of components and automation of business logic; The ODA component management module is used to perform the following: Combined with the open source Operator resources of the Kubernetes community, it realizes the full process automated management of components from configuration to deployment.

7. The declarative ODA component automatic activation system according to claim 6, characterized in that: The core functions and related configurations of the components include initial configuration, API publishing and subscription, functional permissions, role setting, business indicator monitoring, traffic management and compliance testing.

8. The declarative ODA component automatic activation system according to claim 6, characterized in that: Custom resources include Component, API, and Security; The related properties and rules of custom resources include resource name, version, group, scope, resource fields and validation rules; For Component, the scope is understood as selecting cluster scope or namespace scope as needed. The fields of the resource cover the basic information of the component, API publishing information, security setting information, event notification information, environment dependency information, and management operation information. The basic information of the component includes the name and version. The validation rules ensure that the creation and update of the Component resource instance conform to the preset data model standards, such as the validation rules of the field type, format, and required items. For API, scope means selecting an appropriate scope according to the scope of API usage. The fields of resources include the name, description, endpoint address, protocol, and component of the API. Validation rules are used to verify the fields of API resource instances to ensure the accuracy and completeness of API information. For Security, the scope is understood as determining the scope according to the applicable scope of the security configuration. The fields of the resource include the component's function menu, security control policy, predefined roles and permissions, and default user settings. The validation rules are used to strictly verify the fields of the Security resource instance to ensure the compliance and effectiveness of the security configuration. Correspondingly, after submitting custom resources to Kubernetes through the kubectl command, Kubernetes allows users to create, query, update, and delete corresponding custom resource instances through the Kubernetes API. When creating a custom resource instance, Kubernetes verifies it according to the preset data model standards and validation rules, and stores the verified instances in the etcd database.

9. The declarative ODA component automatic activation system according to claim 6, characterized in that: The component controller comprises: Component Operator, used to manage component lifecycle; APIOperator, used to publish and subscribe to components’ OpenAPI; Security Operator, which is used to automatically configure identity services; Test Operator, which performs compliance tests and updates test results; Prometheus Operator, used for configuring the component core business monitoring panel; Istio Operator, used to configure component traffic management rules.

10. The declarative ODA component automatic activation system according to claim 9, characterized in that: For the ODA component management module, combined with the open source Operator resources of the Kubernetes community, the full process of component automation management from configuration to deployment is implemented, including the following operations: Complete the configuration of the component business monitoring panel through Prometheus Operator to ensure the stable operation of the service; Configure traffic management rules through Istio Operator to optimize traffic scheduling and distribution between services.

Images