Compatibility testing methods, apparatus, computer-readable storage media, and program products

By performing precise compatibility checks between the container platform and the application, compatibility issues between the container platform and complex container applications are resolved, ensuring the stability and security of the deployment and upgrade process.

CN120578452BActive Publication Date: 2025-10-31XIAN RUIXIN TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202511093469.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-08-06
Publication Date
2025-10-31
Estimated Expiration
2045-08-06

AI Technical Summary

Technical Problem

The lack of an effective compatibility dependency checking mechanism between container platforms and complex container applications may lead to compatibility issues during deployment or upgrade operations, affecting system stability and data security.

Method used

By acquiring the capabilities and resources provided by the container platform and the dependencies required by container applications, precise compatibility checks are performed, including the breakdown of baseline information at the cluster and node levels. Task Pods are then created using the Virtual Network Function Manager and Container Infrastructure Service Manager to ensure the accuracy and stability of the check results.

Benefits of technology

It avoids compatibility issues caused by mismatches during container application deployment or upgrades, improves the accuracy and efficiency of checks, and ensures system stability and security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120578452B_ABST
    Figure CN120578452B_ABST
Patent Text Reader

Abstract

This application provides a compatibility checking method, apparatus, computer-readable storage medium, and program product, relating to the field of computer technology. The method includes: acquiring container platform-provided capability resources and container application dependency requirement resources; the container platform-provided capability resources include baseline capability information of the container platform, and the container application dependency requirement resources include baseline dependency requirement information of the container application; checking whether the container application dependency requirement resources meet compatibility conditions based on the container platform-provided capability resources, and writing a first check result into the container application dependency requirement resources; or, checking whether the container platform-provided capability resources meet compatibility conditions based on the container application dependency requirement resources, and writing a second check result into the container platform-provided capability resources. This application can avoid compatibility issues between complex container applications and container platforms.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a compatibility checking method, apparatus, computer-readable storage medium, and program product. Background Technology

[0002] Network functions virtualization (NFV) is a network architecture that uses virtualization technology to decouple traditional network functions into software modules and deploy them on general-purpose servers.

[0003] Container platforms are used to manage and orchestrate containerized applications, providing a standardized packaging and deployment environment for network function software modules in NFV. By packaging network functions into container images, they can be quickly deployed and migrated across different servers, effectively shortening the time to market for network functions.

[0004] However, in related technologies, there is a lack of effective mechanisms for checking compatibility dependencies between complex container applications and container platforms before deployment or upgrade operations are carried out. This can easily lead to compatibility issues between complex container applications and container platforms, which may adversely affect the stable operation of the system and data security. Summary of the Invention

[0005] This application provides a compatibility checking method, apparatus, computer-readable storage medium, and program product that can avoid compatibility issues between complex container applications and container platforms.

[0006] In a first aspect, a compatibility checking method is provided. This compatibility checking method can be performed by a communication device, or it can be performed by a chip (or chip system) or other functional modules, and this application does not limit it.

[0007] For example, in some embodiments, the compatibility check method may include:

[0008] Obtain the container platform's provided capability resources and container application dependency requirements resources; the container platform's provided capability resources include the container platform's capability baseline information, and the container application dependency requirements resources include the container application's dependency requirements baseline information.

[0009] Based on the capabilities and resources provided by the container platform, check whether the container application dependency requirements meet the compatibility conditions, and write the first check result into the container application dependency requirements.

[0010] Alternatively, based on the aforementioned container application dependency requirements, check whether the container platform provides the capability resources that meet the compatibility conditions, and write the second check result into the container platform provides the capability resources.

[0011] The compatibility checking method provided in this application, by obtaining the capability resources provided by the container platform and the dependency requirements of the container application, can perform a compatibility check on the dependency requirement baseline information of the container application based on the capability baseline information of the container platform before the container application is deployed or upgraded. This can avoid compatibility problems caused by mismatch during the deployment or upgrade of the container application. Alternatively, before the container platform is upgraded, a compatibility check can be performed on the capability baseline information of the container platform based on the dependency requirement baseline information of the container application. This can also avoid compatibility problems caused by mismatch during the upgrade of the container platform.

[0012] In one possible implementation, the aforementioned capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the aforementioned cluster-level capability baseline information includes cluster label and / or cluster version number information; the aforementioned node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0013] In the above implementation, by subdividing the container platform's capability baseline information into cluster-level capability baseline information and node-level capability baseline information, the assessment of the container platform's resource capabilities becomes more accurate and comprehensive, which helps improve the accuracy of compatibility checks.

[0014] In one possible implementation, the aforementioned dependency requirement baseline information includes cluster-level dependency requirement baseline information and node-level dependency requirement baseline information; the aforementioned cluster-level dependency requirement baseline information includes cluster label and / or cluster version number information; the aforementioned node-level dependency requirement baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0015] In the above implementation, by subdividing the dependency requirements baseline information of container applications into cluster-level dependency requirements baseline information and node-level dependency requirements baseline information, the dependency requirements of container applications can be accurately controlled in a comprehensive and multi-layered manner, avoiding the problem of inaccurate compatibility checks due to ignoring dependency requirements at a certain level.

[0016] In one possible implementation, the aforementioned container application dependency resource also includes the container application's dependency name, thereby enabling quick and accurate location of specific dependencies.

[0017] In one possible implementation, the aforementioned container application dependency resources are established by the virtualized network function manager (VNFM) before the container application is deployed or upgraded.

[0018] In the above implementation, VNFM establishes the container application dependency requirements resources before the container application is deployed or upgraded. This can provide a basis for compatibility checks before the container application is deployed or upgraded, and avoid compatibility issues caused by mismatches during the container application deployment or upgrade process.

[0019] In one possible implementation, the above method also includes:

[0020] Create the container group (Pod) corresponding to the first task. The first task is created by VNFM and is used to obtain the results of the first check mentioned above. The command parameters of the Pod include the dependency requirements name of the container application.

[0021] In the above implementation, by creating a Pod corresponding to the first task, it can be ensured that the first task can run stably and efficiently, and accurately obtain the required inspection results.

[0022] In one possible implementation, the container platform-provided capability resources mentioned above also include the container platform-provided capability name, thereby enabling quick and accurate location of specific container platform-provided capabilities.

[0023] In one possible implementation, the aforementioned container platform provides the necessary resources, which are established by the container infrastructure service cluster management (CCM) before the container platform is upgraded.

[0024] In the above implementation, CCM establishes the container platform's capability resources before the container platform upgrade, which can provide a basis for compatibility checks before the container platform upgrade and avoid compatibility issues caused by mismatches during the container platform upgrade process.

[0025] In one possible implementation, the above method also includes:

[0026] Create the Pod corresponding to the second task. The second task is created by CCM and is used to obtain the second check result. The command parameters of the Pod include the name of the capability provided by the container platform.

[0027] In the above implementation, by creating a Pod corresponding to the second task, it can be ensured that the second task can run stably and efficiently, and accurately obtain the required inspection results.

[0028] In one possible implementation, the container application mentioned above includes a cloud native network function (CNF).

[0029] The above implementation method can avoid compatibility issues caused by incorrect compatibility during CNF deployment or upgrade.

[0030] Secondly, a compatibility checking method is provided, which can be performed by a communication device, or by a chip (or chip system) or other functional modules, without limitation.

[0031] For example, in some embodiments, the compatibility check method may include:

[0032] Send a request message to the Container Infrastructure Service Management (CISM); the request message includes container application dependency requirements resources or container platform provided capability resources. Container application dependency requirements resources include the container application's dependency requirements baseline information, and container platform provided capability resources include the container platform's capability baseline information.

[0033] Establish the first task, which is used to obtain the first check result. The first check result is obtained by checking whether the container application's dependency requirements meet the compatibility conditions based on the capabilities and resources provided by the container platform.

[0034] Alternatively, a second task can be established to obtain a second check result, which is obtained by checking whether the container platform provides the necessary resources based on the container application's resource dependencies to ensure compatibility.

[0035] In one possible implementation, the above method also includes:

[0036] Receive the first check result sent from the container infrastructure service (CIS) node, and determine whether to deploy or upgrade the container application based on the first check result; the first check result is obtained by the CIS node by running the Pod corresponding to the first task.

[0037] Alternatively, the system can receive a second check result from the CIS node and determine whether to upgrade the container platform based on the second check result; the second check result is obtained by the CIS node by running the Pod corresponding to the second task.

[0038] In one possible implementation, the capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the cluster-level capability baseline information includes cluster label and / or cluster version number information; the node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0039] In one possible implementation, the aforementioned dependency requirement baseline information includes cluster-level dependency requirement baseline information and node-level dependency requirement baseline information; the cluster-level dependency requirement baseline information includes cluster label and / or cluster version number information; the node-level dependency requirement baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0040] In one possible implementation, the aforementioned container application dependency resource also includes the container application's dependency name.

[0041] In one possible implementation, the aforementioned container application dependency requirements resources are established before the container application is deployed or upgraded.

[0042] In one possible implementation, the container platform provides capability resources that also include container platform-provided capability names.

[0043] In one possible implementation, the aforementioned container platform provides the necessary resources before the container platform is upgraded.

[0044] In one possible implementation, the container application mentioned above includes CNF.

[0045] Thirdly, a communication device is provided. The communication device includes a module for performing the compatibility check method as provided in the first aspect, or includes a module for performing the compatibility check method as provided in the second aspect.

[0046] Fourthly, a communication device is provided, comprising one or more processors for executing a computer program (also referred to as code or instructions) in memory, such that the communication device implements the compatibility checking method described in the first or second aspect.

[0047] Optionally, the communication device further includes a memory for storing computer programs and data. The memory is coupled to the processor, and when the processor executes the computer program stored in the memory, it can implement the compatibility checking method described in the first or second aspect.

[0048] Optionally, the communication device further includes a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0049] Fifthly, a chip system is provided, the chip system including at least one processor for supporting the implementation of the compatibility checking method described in the first or second aspect above.

[0050] In one possible implementation, the chip system also includes a memory for storing computer programs and data, which may be located inside or outside the processor.

[0051] In one possible implementation, the chip system can be composed of chips or may include chips and other discrete devices.

[0052] In one possible implementation, the chip system also includes a power supply circuit for supplying power to the chip system.

[0053] In a sixth aspect, a computer-readable storage medium is provided, including a computer program that, when run on a computer, causes the computer to implement the compatibility checking method described in the first or second aspect.

[0054] In a seventh aspect, a computer program product is provided, comprising: a computer program that, when run, causes a computer to perform the compatibility checking method described in the first or second aspect.

[0055] Eighthly, a communication system is provided, including a communication device for performing the compatibility checking method described in the first aspect, and a communication device for performing the compatibility checking method described in the second aspect.

[0056] The second to eighth aspects of this application have similar beneficial effects to the first aspect of this application and the corresponding feasible implementation methods, and will not be described again. Attached Figure Description

[0057] Figure 1 This is a schematic diagram of a standard architecture for network functions virtualization (NFV) provided in an embodiment of this application;

[0058] Figure 2 This is a schematic diagram of an NFV architecture extension provided in an embodiment of this application;

[0059] Figure 3 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 1 ;

[0060] Figure 4 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 2 ;

[0061] Figure 5 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 3 ;

[0062] Figure 6 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 4 ;

[0063] Figure 7 This is a schematic block diagram of a communication device provided in the embodiments of this application;

[0064] Figure 8 This is a schematic block diagram of another communication device provided in the embodiments of this application;

[0065] Figure 9 This is a schematic block diagram of yet another communication device provided in the embodiments of this application. Detailed Implementation

[0066] The technical solution provided in this application will now be described with reference to the accompanying drawings.

[0067] To facilitate understanding of the embodiments of this application, the following points will be explained first:

[0068] First, in the embodiments of this application, the indication includes explicit indication (also known as direct indication) and implicit indication (also known as indirect indication). Explicit indication information A refers to including information A; implicit indication information A refers to indicating information A through the correspondence between information A and information B, and direct indication information B. The correspondence between information A and information B can be predefined, pre-stored, or pre-configured; alternatively, it can refer to indicating information A through information B and preset rules.

[0069] Second, in the embodiments of this application, information C is used to determine information D, which includes determining information D based solely on information C, as well as determining it based on information C and other information. Furthermore, the use of information C to determine information D can also include indirect determination, such as when information D is determined based on information E, and information E is determined based on information C.

[0070] Third, in the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates an "or" relationship between the preceding and following related objects, but it does not exclude the possibility of indicating an "and" relationship. The specific meaning can be understood in conjunction with the context. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Here, a, b, and c can be single or multiple.

[0071] To better understand the technical solutions provided in the embodiments of this application, some technical terms involved in the embodiments of this application will be briefly explained below.

[0072] 1. Network Functions Virtualization (NFV)

[0073] NFV is a network architecture that decouples traditional network functions into software modules using virtualization technology and deploys them on general-purpose servers. For example, based on modern information technology (IT) virtualization technology, a new network product environment can be provided, helping to reduce costs and improve network resource utilization. NFV has the following characteristics:

[0074] Hardware / software decoupling, also known as layered decoupling, refers to the separation of upper-layer virtualized network function (VNF) software from lower-layer general-purpose hardware through the virtualization of computing, storage, and network resources. This means that the software no longer depends on specific hardware devices, improving system flexibility and scalability.

[0075] Computational virtualization: Virtualizing computer resources such as the central processing unit (CPU) and memory, providing standard input / output interfaces for these resources. Multiple virtual machines can be virtualized and run on a single physical machine, thereby improving the utilization of computer hardware resources. For example, in a data center, computational virtualization technology can allocate the resources of a high-performance server to multiple virtual machines, each running different network functions, avoiding idle hardware resources.

[0076] Storage virtualization: Virtualizing different storage devices masks differences in capabilities and interface protocols, transforming various storage resources into a unified, managed data storage resource. This simplifies storage management and improves the utilization efficiency of storage resources. For example, enterprises can integrate storage devices of different brands and models into a virtual storage pool and dynamically allocate storage space according to demand.

[0077] Network virtualization: Utilizing virtual switches to provide Layer 2 networking capabilities for virtual machines on physical machines, enabling internal network communication between virtual machines and external network access. This makes network configuration more flexible and allows for rapid adaptation to different business needs. For example, in a cloud computing environment, virtual networks can be dynamically created based on user requests, providing users with an isolated network environment.

[0078] For example, refer to Figure 1 , Figure 1 This is a schematic diagram of an NFV standard architecture provided in an embodiment of this application.

[0079] In some implementations, the operations support system (OSS) and business support system (BSS) are responsible for network operations and business management, including functions such as billing, customer management, and service activation. They can interact with the network functions virtualization orchestrator (NFVO) to automate the deployment and management of network services.

[0080] NFVO is the core component of NFV management and orchestration, responsible for global resource and service orchestration. It can receive service requests from OSS / BSS and, based on resource availability and policies, coordinate components such as the element management system (EMS) and the virtualized network function manager (VNFM) to achieve global orchestration and resource allocation for network services.

[0081] EMS is used to manage and monitor specific virtualized network function (VNF) instances, and is responsible for VNF configuration, fault management, and performance monitoring.

[0082] VNF stands for Virtual Network Function, such as virtual firewalls and virtual routers. Each VNF consists of an application (APP), a container group (Pod), a container infrastructure service (CIS), etc., and runs on a virtual machine (VM).

[0083] VNFM is responsible for the lifecycle management of individual VNFs, including instantiation, configuration, scaling, and termination. It interacts directly with VNFs and coordinates resource allocation with the Virtualized Infrastructure Manager (VIM) through Container Infrastructure Service Management (CISM).

[0084] Container Infrastructure Services Cluster Management (CCM) can be responsible for the provision of CISM and CIS.

[0085] CISM can automatically discover hardware resources such as computing, storage, and networking within the infrastructure site, providing basic data for subsequent resource allocation and container deployment.

[0086] VIM is responsible for managing and controlling virtualization infrastructure resources, including compute, storage, and network resources. It receives resource requests from VNFM and allocates the corresponding resources.

[0087] Physical Infrastructure Manager (PIM) is used to manage physical infrastructure, such as servers, storage devices, and network devices.

[0088] The virtualization layer (Hypervisor) is used to create and manage virtual machines, abstracting physical resources into virtual resources for use by VNFs.

[0089] Servers / storage devices / network devices are used to provide physical computing, networking, and storage resources.

[0090] 2. Open Container Initiative (OCI)

[0091] OCI is a key standardization organization in the field of container technology. Its core goal is to develop unified standards around container formats and runtimes, achieve compatibility and interoperability of containers across different platforms and tools, and promote the standardized development of the container technology ecosystem.

[0092] The OCI standard mainly includes two core specifications:

[0093] (1) Container runtime specification (OCI runtime specification, OCI RS): specifies the behavior standards of container runtime to ensure that containers can run safely and consistently in different environments.

[0094] (2) Container Image Specification (OCI IS): Standardizes the format and content of container images to ensure that images are portable across different image repositories and runtime environments.

[0095] The OCI standard addresses the fragmentation of the container technology ecosystem by defining unified specifications for container images and runtimes, providing fundamental guarantees for cross-platform migration, security, and reliability of containers. Its core value lies in promoting the standardization and openness of container technology, making it one of the core technologies of modern cloud-native architectures.

[0096] Kubernetes (K8s) is an open-source container orchestration platform used to automate the deployment, scaling, and management of containerized applications.

[0097] Among related technologies, the Kubernetes-based container platform can be used to manage and orchestrate containerized applications, providing a standardized packaging and deployment environment for network function software modules in NFV.

[0098] However, in related technologies, there is a lack of effective mechanisms for checking compatibility dependencies between complex container applications and container platforms before deployment or upgrade operations are carried out. This can easily lead to compatibility issues between complex container applications and container platforms, which may adversely affect the stable operation of the system and data security.

[0099] For example, the container image compatibility specifications and tools currently adopted by the OCI standard and the Kubernetes community are a pre-run compatibility check mechanism based on feature flags and attributes. This mechanism associates the runtime compatibility dependencies of cloud native function (CNF) containers with the container platform with specific images, and relies on running node feature discovering (NFD) tools on the nodes to check whether the feature dependencies between the image and the node environment are met. This mechanism has the following problems:

[0100] (1) When the runtime dependency requirements of the container image are also affected by the specific container application orchestration parameters, the current mechanism has difficulty in distinguishing and handling them.

[0101] (2) CNF generally contains many container services, and many corresponding container images are associated with the container services. The current mechanism cannot perform compatibility runtime dependency checks as a whole before CNF is deployed or upgraded. Checking based on each image is more complicated.

[0102] (2) The NFD tool's inspection method depends on the runtime environment and does not support checking the compatibility of already running container applications before the container platform is upgraded.

[0103] To address the aforementioned technical issues, this application provides a compatibility checking method that can prevent compatibility problems between complex container applications and container platforms.

[0104] For example, the above methods can be used to check compatibility issues before the deployment or upgrade of cloud native functions (CNFs), and / or to check compatibility issues of the container platform with the runtime environment before the upgrade.

[0105] Specifically, before deploying or upgrading CNF, by obtaining CNF's runtime dependencies on the container platform, the container platform can quickly check the dependency satisfaction status of CNF through a dependency checking mechanism, thus avoiding compatibility issues caused by incorrect compatibility during CNF deployment or upgrade.

[0106] Before upgrading a container platform, by comprehensively obtaining the requirements of the container platform's supported runtime environment, the container platform can quickly check the dependency satisfaction of CNFs already running in the container platform through a dependency checking mechanism, thus avoiding compatibility issues caused by incorrect compatibility during the container platform upgrade process.

[0107] The technical solutions provided in this application will be described in detail below through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other, and the same or similar content will not be described again in different embodiments.

[0108] For example, refer to Figure 2 , Figure 2 This is a schematic diagram of an NFV architecture extension provided in an embodiment of this application.

[0109] In some embodiments, CISM interfaces IF1 and IF2 can be extended. Wherein:

[0110] Interface IF1 is a declarative CNF dependency requirement interface, which can be used to describe the baseline information of CNF (user) dependency requirements to container platform (provider), including but not limited to: CNF dependency requirement name, cluster-level dependency requirement baseline information and node-level dependency requirement baseline information.

[0111] Optionally, the baseline information for the above cluster-level dependencies includes, but is not limited to: cluster label, Kubernetes version number, and CoreDNS version number; the baseline information for the above node-level dependencies includes, but is not limited to: node label, operating system (OS) kernel version number, and container engine information.

[0112] CoreDNS is a component in the Kubernetes cluster responsible for domain name system (DNS) resolution, which can support the resolution of custom service domain names within the cluster and domain names outside the cluster.

[0113] Interface IF2 provides a capability interface for declarative container platforms, which describes the capability baseline information provided by the container platform (provider) to all CNFs (users), including but not limited to: the capability name provided by the container platform, the capability baseline information provided at the cluster level, and the capability baseline information provided at the node level.

[0114] Optionally, the cluster-level capability baseline information provided above includes, but is not limited to: cluster label, Kubernetes version number, and CoreDNS version number; the node-level capability baseline information provided above includes, but is not limited to: node label, OS kernel version number, and container engine.

[0115] For example, refer to Figure 3 , Figure 3 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 1 .

[0116] In this embodiment of the application, the compatibility check method can be applied to check the compatibility of container applications before deployment or upgrade.

[0117] Optionally, the container application mentioned above can be CNF.

[0118] For example, the above compatibility check method may include:

[0119] S301 and CISM obtain the capabilities and resources provided by the container platform.

[0120] In some implementations, a dependency check controller can be added to CISM to collect cluster-level capability baseline information of the container platform, and to collect node-level capability baseline information of the container platform through the CIS of each node.

[0121] Optionally, the above cluster-level capability baseline information includes cluster label and / or cluster version number information.

[0122] Cluster tags can be used to identify key-value pairs of cluster attributes, purposes, or management categories; cluster version number information can reflect the technology stack version of core components in the cluster.

[0123] For example, the cluster version information mentioned above includes, but is not limited to, Kubernetes version information, Core DNS version information, etc.

[0124] Optionally, the above node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0125] Among them, the node labels mentioned above can be used to describe the attributes, purpose or management classification of the node; the node version number information can reflect the technology stack version of the key software components running on the node; the container engine information can be used to describe information such as the container runtime interface (CRI).

[0126] Optionally, the node version number information mentioned above may include the node's OS kernel version number information.

[0127] In some implementations, the aforementioned dependency check controller can establish container platform provision capability resources based on the collected container platform capability baseline information and save them to CISM's internal database.

[0128] S302, VFNM establishes resource requirements for container application dependencies.

[0129] Optionally, the aforementioned container application dependency requirements resources may include baseline dependency requirements information for the container application. This baseline dependency requirements information may include cluster-level and node-level dependency requirements baseline information.

[0130] Optionally, the above cluster-level dependency requires the baseline information to include the cluster label and / or cluster version number.

[0131] For example, the cluster version number information mentioned above may include the Kubernetes version number, Core DNS version number, etc.

[0132] Optionally, the above node-level dependency requirements baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0133] For example, the node version number information mentioned above may include the OS kernel version number.

[0134] When the container application mentioned above is a CNF, the container application's dependency resources can be called CNF dependency resources. VFNM can create CNF dependency resources in the pre-install hook or pre-upgrade hook during the CNF deployment or upgrade phase.

[0135] In some implementations, the container application dependency resource may further include the container application's dependency name. For example, the CNF dependency resource may carry the CNF dependency name.

[0136] For example, taking the container application mentioned above as CNF, the establishment of the resources required by the CNF dependencies can be implemented as follows:

[0137] apiVersion: v1

[0138] kind: CNFRequires

[0139] metadata:

[0140] CRName: string # Derived from the "CNF dependency requirement name" parameter

[0141] spec:

[0142] ClusterRequires:

[0143] ClusterLabel: string # Derived from the "Cluster Label" parameter of "Cluster-level Dependency Requirements Baseline".

[0144] KubernetesVer: string # The "Kubernetes version number" parameter derived from the "Cluster-level Dependency Requirements Baseline".

[0145] CoreDNSVer: string # The "CoreDNS version number" parameter derived from the "Cluster-level Dependency Requirements Baseline".

[0146]

[0147] NodeRequires:

[0148] NodeLabel: string # Derived from the "node label" parameter of "node-level dependency requirements baseline".

[0149] OSKernelVer: string # The "OS kernel version number" parameter derived from "node-level dependency baseline requirements".

[0150] ContainerEngine: string # The "container engine" parameter derived from "node-level dependency baseline requirements".

[0151]

[0152] S303, VFNM sends a request message to CISM; the request message includes the container application's dependency on the required resources.

[0153] In some implementations, when CISM receives a request message, it can parse the request message to obtain the aforementioned container application dependency resources and save them to an internal database.

[0154] In some implementations, after saving the container application dependency resource requirements, CISM can return the container application dependency resource requirement creation request result to VFNM.

[0155] S304. CISM checks whether the container application dependency requirements meet the compatibility conditions based on the capabilities provided by the container platform, and writes the first check result into the container application dependency requirements.

[0156] In some implementations, the new dependency check controller in CISM can detect new container application dependency requirements through List-Watch, obtain the cluster-level dependency requirement baseline and the node-level dependency requirement baseline from the container application dependency requirement resource, and check them one by one based on the cluster-level capability baseline and the node-level capability baseline provided by the container platform to determine whether the compatibility conditions are met.

[0157] Specifically, when the above-mentioned cluster-level capability baseline is compatible with the above-mentioned cluster-level dependency requirement baseline, and the above-mentioned node-level capability baseline is compatible with the above-mentioned node-level dependency requirement baseline, it can be determined that the above-mentioned container application dependency requirement resources meet the compatibility conditions.

[0158] For example, taking the Kubernetes version number as an example, when the Kubernetes version number in the container platform's capability resources is greater than or equal to the Kubernetes version number in the container application dependency requirements resources, it can be determined that the Kubernetes version number in the container application dependency requirements resources meets the compatibility conditions.

[0159] In some implementations, the Status field of the container application dependency resource can be updated based on the inspection results. For example, if the container application dependency resource meets the compatibility requirements, "Passed" can be written to the Status field of the corresponding container application dependency resource; otherwise, "Failed" can be written to the Status field, and the names of the dependency requirements that do not meet the compatibility requirements (there can be one or more) can be recorded in the Status field.

[0160] List-Watch is a resource monitoring method provided by the Container Infrastructure Server Manager. The List operation retrieves all data for a specified resource, while the Watch operation detects resource change events in real time. By continuously executing the List operation, the latest status of the resource can be obtained, while the Watch operation can detect dynamic changes to the resource.

[0161] In this embodiment of the application, by obtaining the capability resources provided by the container platform and the dependency requirements of the container application, a compatibility check can be performed on the dependency requirements baseline information of the container application based on the capability baseline information of the container platform before the container application is deployed or upgraded. This can avoid compatibility problems caused by mismatch during the deployment or upgrade of the container application.

[0162] For example, refer to Figure 4 , Figure 4 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 2 .

[0163] In this embodiment of the application, the compatibility check method can be applied to check the compatibility of container applications before deployment or upgrade.

[0164] For example, the above compatibility check method may include:

[0165] S401 and CISM obtain the capabilities and resources provided by the container platform.

[0166] S402, VFNM establishes resource requirements for container application dependencies.

[0167] S403, VFNM sends a request message to CISM; the request message includes the resource requirements of the aforementioned container application dependencies.

[0168] S404 and CISM check whether the container application dependency requirements meet the compatibility conditions based on the capabilities provided by the container platform, and write the first check result into the container application dependency requirements.

[0169] It should be noted that the content described in steps S401 to S404 above is consistent with the content described in steps S301 to S304 in the above embodiments. For details, please refer to the content described in the above embodiments, which will not be repeated here.

[0170] S405, VFNM establish the first job.

[0171] The first job mentioned above is used to obtain the first check result mentioned above.

[0172] In some implementations, VFNM can create a first job in the pre-install hook or pre-upgrade hook corresponding to the deployment or upgrade phase of the container application to obtain the resource check results of the container application dependency requirements. The first job carries the corresponding container application dependency requirement resource name (e.g., carried in command parameters or environment variables).

[0173] For example, taking the container application mentioned above as CNF as an example, the following implementation method can be referenced:

[0174] apiVersion: batch / v1

[0175] kind: Job

[0176] metadata:

[0177] name: string # The name of the job

[0178] spec:

[0179] template:

[0180] spec:

[0181] containers:

[0182] - name: string # The name of the job

[0183] image: string # The container image name of the Job

[0184] command: string # Command line information executed by the Job, including the name of the corresponding CNF dependency resource.

[0185] restartPolicy: Never#Job corresponds to the Pod container restart policy. Never indicates that terminated containers will not be automatically restarted.

[0186]

[0187] Job is a task implementation method in the industry based on Kubernetes container platforms. Job means a one-time task that stops after it is completed.

[0188] S406, CISM creates the Pod corresponding to the first Job.

[0189] In some implementations, when the existing Job controller of CISM detects a new Job resource through List-Watch, it can create a Pod resource to obtain the first check result based on the parameters of the first Job, and set the corresponding CNF dependency requirement name parameter into the command parameters.

[0190] In Kubernetes, a Pod is the smallest unit of scheduling and management, containing one or more containers that share network and storage resources.

[0191] In some implementations, CISM can also save the corresponding Pod resources to an internal database.

[0192] For example, when the CISM scheduler detects a new Pod resource through List-Watch, it can schedule the new Pod resource to one of the physical nodes of the container platform according to the existing scheduling policy, fill in the corresponding physical node information in the node label (nodeName) of the new Pod resource, and save it to the internal database.

[0193] In some implementations, the first job can create one or more Pods and continue to retry the execution of Pods until a specified number of Pods successfully terminate. As each Pod successfully terminates, the first job records the number of successfully completed Pods; when the number of successfully completed Pods reaches a specified success threshold, the task (i.e., the first job) ends.

[0194] Optionally, the first job can be deleted after it finishes. Deleting the first job will clear all Pods created by it; suspending the first job will delete all active Pods of the first job until the first job is resumed.

[0195] S407 and CIS use the List-Watch mechanism to detect the Pod corresponding to the first Job.

[0196] S408 and CIS run the first job corresponding to the Pod and read the first check result from the container application dependency requirements resources.

[0197] For example, CIS runs the Pod corresponding to the first Job and reads the check results from the Status field of the corresponding CNF dependency resource from CISM based on the CNF dependency name parameter.

[0198] S409, CIS sends the first check result read by VFNM.

[0199] In some implementations, VFNM can obtain the first check result from CIS feedback. If the check result in the Status field is Passed, it returns a success indication message in the Status field of the first Job; otherwise, it returns a failure indication message in the Status field of the first Job and records the name of the unmet dependency requirement (which can be one or more) in the Reason field of the first Job.

[0200] For example, the following implementation method can be referred to: [

[0202] {

[0203] "lastProbeTime": "xxxx-xx-xxT02:01:00Z",

[0204] "lastTransitionTime": "xxxx-xx-xxT02:01:00Z",

[0205] "message": "Job has reached the specified backoff limit",

[0206] "reason": "BackoffLimitExceeded",

[0207] "status": "True",

[0208] type: "Failed"

[0209] } ]

[0211] Based on the first check results obtained, S410 and VFNM determine whether to continue deploying or upgrading the aforementioned container applications.

[0212] In some implementations, if the Status field in the first check result is “Passed”, the deployment or upgrade of the container application can continue; otherwise, the deployment or upgrade of the container application is aborted.

[0213] In this embodiment of the application, during the deployment or upgrade of container applications, by establishing a Pod corresponding to the first task, it can be ensured that the first task can run stably and efficiently, and accurately obtain the required inspection results.

[0214] For example, refer to Figure 5 , Figure 5 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 3 .

[0215] In this embodiment of the application, the compatibility check method can be applied to check the baseline compliance of all container applications' dependencies before upgrading the container platform.

[0216] For example, the above compatibility check method may include:

[0217] S501, CISM obtains the resources required by container application dependencies.

[0218] In some implementations, the aforementioned container application dependency resources may be dependency resources established by the container application during the deployment or upgrade phase.

[0219] Optionally, the aforementioned container application dependency requirements resources may include baseline dependency requirements information for the container application. This baseline dependency requirements information includes cluster-level and node-level baseline dependency requirements information.

[0220] Optionally, the above cluster-level dependency requires the baseline information to include the cluster label and / or cluster version number.

[0221] For example, the cluster version number information mentioned above may include the Kubernetes version number, Core DNS version number, etc.

[0222] Optionally, the above node-level dependency requirements baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0223] For example, the node version number information mentioned above may include the OS kernel version number.

[0224] In some implementations, the container application dependency resource may further include the container application's dependency name. For example, the CNF dependency resource may carry the CNF dependency name.

[0225] S502 and CCM establish a container platform to provide capability resources.

[0226] In some implementations, CCM can create a new version of container platform provisioning capabilities in the pre-upgrade hook during the container platform upgrade phase. These container platform provisioning capabilities may include cluster-level capability baseline information and node-level capability baseline information.

[0227] Optionally, the above cluster-level capability baseline information includes cluster label and / or cluster version number information.

[0228] For example, the cluster version information mentioned above includes Kubernetes version information, Core DNS version information, etc.

[0229] Optionally, the above node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0230] For example, the node version number information mentioned above may include the node's OS kernel version number information.

[0231] In some implementations, the container platform providing capability resources may also include the container platform providing capability name.

[0232] For example, the establishment of capability resources provided by the container platform can be implemented in the following way:

[0233] apiVersion: v1

[0234] kind: CaaSProvides

[0235] metadata:

[0236] CPName: string # Derived from the "Container Platform Capability Name" parameter

[0237] spec:

[0238] ClusterProvides:

[0239] ClusterLabel: string # Derived from the "Cluster Label" parameter in "Cluster-level Capability Baseline".

[0240] KubernetesVer: string # The "Kubernetes version number" parameter derived from the "Cluster-level Capability Baseline".

[0241] CoreDNSVer: string # The "CoreDNS version number" parameter derived from the "Cluster-level Capability Baseline".

[0242]

[0243] NodeProvides:

[0244] NodeLabel: string # Derived from the "Node Label" parameter of "Node-level Capability Baseline".

[0245] OSKernelVer: string # Derived from the "OS kernel version number" parameter of the "node-level capability baseline".

[0246] ContainerEngine: string # The "container engine" parameter derived from the "node-level capability baseline".

[0247]

[0248] S503 and CCM send a request message to CISM; the request message includes the capability resources provided by the aforementioned container platform.

[0249] In some implementations, when CISM receives a request message, it can parse the request message to obtain the capability resources provided by the container platform and save them to its internal database.

[0250] In some implementations, after saving the container platform-provided capability resources, CISM can return the container platform-provided capability resource establishment request result to CCM.

[0251] S504 and CISM check whether the container platform provides capability resources that meet the compatibility conditions based on the container application's dependency requirements, and write the second check result into the container platform's capability resources.

[0252] In some implementations, the newly added dependency check controller in CISM can detect newly added container platform provision capability resources through List-Watch. Based on the cluster-level dependency requirement baseline and node-level dependency requirement baseline of container application dependency requirements resources, it performs dependency checks on the newly established cluster-level provision capability baseline and node-level provision capability baseline of container platform provision capability resources one by one to determine whether the compatibility conditions are met.

[0253] Specifically, if the above-mentioned cluster-level capability baseline is compatible with the above-mentioned cluster-level dependency requirement baseline, and the above-mentioned node-level capability baseline is compatible with the above-mentioned node-level dependency requirement baseline, it can be determined that the capability resources provided by the above-mentioned container platform meet the compatibility conditions.

[0254] For example, taking the Kubernetes version number as an example, when the Kubernetes version number in the container platform's capability resources is greater than or equal to the Kubernetes version number in the container application's dependency requirements resources, it can be determined that the Kubernetes version number in the container platform's capability resources meets the compatibility conditions.

[0255] In some implementations, the Status field of the container platform-provided capability resource can be updated based on the inspection results. For example, if the container platform-provided capability resource meets the compatibility conditions, "Passed" can be written to the Status field of the corresponding container platform-provided capability resource; otherwise, "Failed" can be written to the Status field, and the name of the unmet dependency requirement and the corresponding dependency requirement baseline (which can be one or more) can be recorded in the Status field.

[0256] In this embodiment of the application, by obtaining the capability resources provided by the container platform and the dependency requirements of the container application, a compatibility check can be performed on the capability baseline information of the container platform based on the dependency requirements baseline information of the container application before the container platform is upgraded. This can avoid compatibility problems caused by mismatch during the container platform upgrade process.

[0257] For example, refer to Figure 6 , Figure 6 This is a flowchart illustrating a compatibility checking method provided in the embodiments of this application. Figure 4 .

[0258] In this embodiment of the application, the compatibility check method can be applied to check the baseline of the container platform's dependent interfaces before the deployment or upgrade of container applications.

[0259] For example, the above compatibility check method may include:

[0260] S601, CISM obtains the resources required by container application dependencies.

[0261] S602 and CCM establish a container platform to provide capability resources.

[0262] S603 and CCM send a request message to CISM; the request message includes the capability resources provided by the aforementioned container platform.

[0263] S604 and CISM check whether the container platform provides capability resources that meet the compatibility conditions based on the container application's dependency requirements, and write the second check result into the container platform's capability resources.

[0264] It should be noted that the content described in steps S601 to S604 above is consistent with the content described in steps S501 to S504 in the above embodiments. For details, please refer to the content described in the above embodiments, which will not be repeated here.

[0265] S605, CCM establish a second job.

[0266] The second job mentioned above is used to obtain the second check result.

[0267] In some implementations, CCM can create a second job in the pre-install hook or pre-upgrade hook corresponding to the container platform upgrade phase to obtain the check results of the container platform's provided capability resources. The second job carries the name of the corresponding container platform's provided capability resources (e.g., carried in command parameters or environment variables).

[0268] For example, the following implementation method can be referred to:

[0269] apiVersion: batch / v1

[0270] kind: Job

[0271] metadata:

[0272] name: string # The name of the job

[0273] spec:

[0274] template:

[0275] spec:

[0276] containers:

[0277] - name: string # The name of the job

[0278] image: string # The container image name of the Job

[0279] command: string # Command line information executed by the job, carrying the corresponding container platform's capabilities and resources.

[0280] restartPolicy: Never#Job corresponds to the Pod container restart policy. Never indicates that terminated containers will not be automatically restarted.

[0281]

[0282] S606, CISM creates the Pod corresponding to the second Job.

[0283] In some implementations, when the existing Job controller of CISM detects a new Job resource through List-Watch, it can create a Pod resource for obtaining the second check result based on the parameters of the second Job, and set the corresponding container platform-provided capability resource name parameter into the command parameters.

[0284] In some implementations, CISM can also save the corresponding Pod resources to an internal database.

[0285] For example, when the CISM scheduler detects a new Pod resource through List-Watch, it can schedule the new Pod resource to one of the physical nodes of the container platform according to the existing scheduling policy, fill in the corresponding physical node information in the node name (nodeName) of the new Pod resource, and save it to the internal database.

[0286] S607 and CIS use the List-Watch mechanism to detect the Pod corresponding to the second Job.

[0287] S608 and CIS run the Pod corresponding to the second Job and read the second check result from the resource provided by the container platform.

[0288] For example, CIS runs the Pod corresponding to the second Job and reads the check results from the Status field of the corresponding container platform-provided capability resource from CISM based on the container platform-provided capability resource name parameter.

[0289] S609, CIS reports the second inspection result it has read to CCM.

[0290] In some implementations, the CCM can obtain the second check result fed back by the CIS. If the check result in the Status field is Passed, a success indication message is returned in the Status field of the second Job. Otherwise, a failure indication message is returned in the Status field of the second Job, and the name of the unmet dependency requirement (which can be one or more) is recorded in the Reason field of the second Job.

[0291] Based on the second check result obtained, S610 and CCM determine whether to continue upgrading the container platform.

[0292] In some implementations, if the Status field in the second check result is "Passed", the container platform upgrade can continue; otherwise, the container platform upgrade is aborted.

[0293] In this embodiment of the application, during the container platform upgrade process, by creating a Pod corresponding to the second task, it can be ensured that the second task can run stably and efficiently, and accurately obtain the required inspection results.

[0294] The compatibility checking method provided in the embodiments of this application has been described in detail above with reference to several accompanying drawings. The communication device provided in the embodiments of this application will now be described with reference to the accompanying drawings.

[0295] like Figure 7 As shown, Figure 7 This is a schematic block diagram of a communication device provided in an embodiment of this application. The communication device 70 includes an acquisition module 701 and an inspection module 702.

[0296] For example, the acquisition module 701 is used for:

[0297] Obtain the container platform's provided capability resources and container application dependency requirements resources; the container platform's provided capability resources include the container platform's capability baseline information, and the container application dependency requirements resources include the container application's dependency requirements baseline information.

[0298] The inspection module 702 is used for:

[0299] Based on the capabilities and resources provided by the container platform, check whether the container application's dependency requirements meet the compatibility conditions, and write the first check result into the container application's dependency requirements.

[0300] Alternatively, based on the resource requirements of the container application, check whether the container platform provides the capability resources that meet the compatibility conditions, and write the second check result into the container platform's capability resources.

[0301] In one possible implementation, the aforementioned capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the aforementioned cluster-level capability baseline information includes cluster label and / or cluster version number information; the aforementioned node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0302] In one possible implementation, the aforementioned dependency requirement baseline information includes cluster-level dependency requirement baseline information and node-level dependency requirement baseline information; the aforementioned cluster-level dependency requirement baseline information includes cluster label and / or cluster version number information; the aforementioned node-level dependency requirement baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0303] In one possible implementation, the aforementioned container application dependency resource also includes the container application's dependency name.

[0304] In one possible implementation, the aforementioned container application dependency requirements are established by VNFM before the container application is deployed or upgraded.

[0305] In one possible implementation, the above apparatus further includes a processing module for: establishing a container group Pod corresponding to the first task, wherein the first task is established by VNFM and the first task is used to obtain the first check result; the command parameters of the Pod include the dependency requirement name of the container application.

[0306] In one possible implementation, the container platform provides capability resources that also include container platform-provided capability names.

[0307] In one possible implementation, the container platform provides the capabilities and resources that CCM established before the container platform upgrade.

[0308] In one possible implementation, the above-mentioned device further includes a processing module for: establishing a Pod corresponding to the second task, wherein the second task is established by CCM and is used to obtain the second check result; the command parameters of the Pod include the name of the capability provided by the container platform.

[0309] In one possible implementation, the container application mentioned above includes CNF.

[0310] like Figure 8 As shown, Figure 8 This is a schematic block diagram of another communication device provided in the embodiments of this application. The communication device 80 includes a transceiver module 801 and a processing module 802.

[0311] For example, the transceiver module 801 is used for:

[0312] Send a request message to CISM; the request message includes container application dependency requirements resources or container platform provided capability resources. Container application dependency requirements resources include the container application's dependency requirement baseline information, and container platform provided capability resources include the container platform's capability baseline information.

[0313] Processing module 802 is used for:

[0314] Establish the first task, which is used to obtain the first check result. The first check result is obtained by checking whether the container application's dependency requirements meet the compatibility conditions based on the container platform's provided capabilities and resources.

[0315] Alternatively, a second task can be established to obtain a second check result, which is obtained by checking whether the container platform provides the necessary resources based on the container application's resource dependencies to ensure compatibility.

[0316] In one possible implementation, the transceiver module 801 is also used for:

[0317] Receive the first check result sent from the CIS node, and determine whether to deploy or upgrade the container application based on the first check result; the first check result is obtained by the CIS node by running the Pod corresponding to the first task;

[0318] Alternatively, the system can receive a second check result from the CIS node and determine whether to upgrade the container platform based on the second check result; the second check result is obtained by the CIS node by running the Pod corresponding to the second task.

[0319] In one possible implementation, the aforementioned capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the aforementioned cluster-level capability baseline information includes cluster label and / or cluster version number information; the aforementioned node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0320] In one possible implementation, the aforementioned dependency requirement baseline information includes cluster-level dependency requirement baseline information and node-level dependency requirement baseline information; the aforementioned cluster-level dependency requirement baseline information includes cluster label and / or cluster version number information; the aforementioned node-level dependency requirement baseline information includes at least one of the following: node label, node version number information, and container engine information.

[0321] In one possible implementation, the aforementioned container application dependency resource also includes the container application's dependency name.

[0322] In one possible implementation, the aforementioned container application dependency requirements resources are established before the container application is deployed or upgraded.

[0323] In one possible implementation, the container platform provides capability resources that also include container platform-provided capability names.

[0324] In one possible implementation, the aforementioned container platform provides the necessary resources before the container platform is upgraded.

[0325] In one possible implementation, the container application mentioned above includes CNF.

[0326] It is understood that the module division in the above-described device is merely a logical functional division. Each function can correspond to a functional module, or two or more functions can be integrated into one functional module. In actual implementation, all or some modules can be integrated into a single physical entity, or they can be distributed across different physical entities. Furthermore, the aforementioned functional modules can be implemented in hardware, software, or a combination of both. Whether a function is executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0327] Figure 9 This is a schematic block diagram of yet another communication device provided in the embodiments of this application. Figure 9 As shown, the communication device 90 includes one or more processors 901. The processor 901 can be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, while the central processing unit can be used to control the device (e.g., a vehicle or a chip), execute software programs, and process data from the software programs.

[0328] Optionally, in one design, the processor 901 may include a computer program (also referred to as code or instructions) that can be executed on the processor 901 to cause the communication device 90 to perform the functions described in the method embodiments above. In yet another possible design, the communication device 90 includes circuitry (…). Figure 9 (Not shown in the diagram), this circuit is used to implement the functions described in the above method embodiments.

[0329] For example, processor 901 can be used to execute a computer program in memory to implement the steps in the above method embodiments.

[0330] Optionally, the communication device 90 may include one or more memories 902 storing computer programs (sometimes referred to as code or instructions) that can be run on the processor 901, causing the communication device 90 to perform the steps in the above method embodiments.

[0331] Optionally, the processor 901 and / or memory 902 may also store data. The processor and memory may be configured separately or integrated together.

[0332] Optionally, the communication device 90 may also include a communication interface 903. The communication interface 903 may sometimes be referred to as a transceiver unit, transceiver, transceiver circuit, or transceiver, etc., and is used for transceiver functions.

[0333] Optionally, the communication device 90 also includes a power supply circuit, which can be used to supply power to the communication device 90.

[0334] It should be noted that the above method embodiments can be applied to a processor, or implemented by a processor. A processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by software instructions.

[0335] The processors mentioned above can be general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any combination thereof. General-purpose processors can be microprocessors or any conventional processor, etc.

[0336] The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0337] The memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0338] This application also provides a chip system including at least one processor for supporting the implementation of the functions involved in any of the above method embodiments.

[0339] In one possible design, the chip system also includes a memory for storing computer program instructions and data, which may be located inside or outside the processor.

[0340] The chip system can consist of chips or include chips and other discrete components.

[0341] This application also provides a computer program product comprising: a computer program (also referred to as code or instructions), wherein when the computer program is run, the compatibility check method described in the above-described embodiments is executed.

[0342] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, the compatibility check method described in the above-described embodiments is executed.

[0343] The compatibility checking method provided in the above embodiments can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented entirely or partially in the form of a computer program product. This computer program product may include one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic disk), an optical medium, or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0344] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

[0347] The unit described as a separate component may or may not be physically separate. The component shown as a unit may or may not be a physical unit; it may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0348] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0349] If this function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or part of it, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

Claims

1. A compatibility checking method, characterized in that, The method includes: Obtain the container platform's provided capability resources and container application dependency requirements resources; the container platform's provided capability resources include the container platform's capability baseline information, and the container application dependency requirements resources include the container application's dependency requirements baseline information; the capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the dependency requirements baseline information includes cluster-level dependency requirements baseline information and node-level dependency requirements baseline information. Based on the container platform's provided capabilities, check whether the container application's dependency requirements meet compatibility conditions, and write the first check result into the container application's dependency requirements; or, based on the container application's dependency requirements, check whether the container platform's provided capabilities meet compatibility conditions, and write the second check result into the container platform's provided capabilities. The container application dependency resource also includes the dependency name of the container application, and the container application dependency resource is established by the Virtual Network Functions Manager (VNFM) before the container application is deployed or upgraded. The method further includes: creating a container group Pod corresponding to the first task, wherein the first task is created by the VNFM and the first task is used to obtain the first check result; the command parameters of the Pod include the dependency requirement name of the container application.

2. A compatibility checking method, characterized in that, The method includes: Obtain the container platform's provided capability resources and container application dependency requirements resources; the container platform's provided capability resources include the container platform's capability baseline information, and the container application dependency requirements resources include the container application's dependency requirements baseline information; the capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the dependency requirements baseline information includes cluster-level dependency requirements baseline information and node-level dependency requirements baseline information. Based on the container platform's provided capabilities, check whether the container application's dependency requirements meet compatibility conditions, and write the first check result into the container application's dependency requirements; or, based on the container application's dependency requirements, check whether the container platform's provided capabilities meet compatibility conditions, and write the second check result into the container platform's provided capabilities. The container platform provides capability resources, including container platform provided capability names, which are established by the Container Infrastructure Service Cluster Manager (CCM) before the container platform is upgraded. The method further includes: creating a Pod corresponding to the second task, wherein the second task is created by the CCM, and the second task is used to obtain the second check result; the command parameters of the Pod include the name of the capability provided by the container platform.

3. The method as described in claim 1 or 2, characterized in that, The cluster-level capability baseline information includes cluster tags and / or cluster version number information; The node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

4. The method as described in claim 1 or 2, characterized in that, The cluster-level dependency requires the baseline information to include the cluster label and / or cluster version number. The node-level dependency requirements baseline information includes at least one of the following: node label, node version number information, and container engine information.

5. The method as described in claim 1 or 2, characterized in that, The container application includes cloud-native networking (CNF).

6. A compatibility checking method, characterized in that, The method includes: Send a request message to the Container Infrastructure Service Manager (CISM); the request message includes container application dependency requirements resources or container platform provided capability resources, the container application dependency requirements resources include container application dependency requirement baseline information, the container platform provided capability resources include container platform capability baseline information; the capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the dependency requirement baseline information includes cluster-level dependency requirement baseline information and node-level dependency requirement baseline information. A first task is established to obtain a first check result, which is obtained by checking whether the container application's dependency resources meet the compatibility conditions based on the container platform's resource requirements; or, a second task is established to obtain a second check result, which is obtained by checking whether the container platform's resource requirements meet the compatibility conditions based on the container application's resource requirements. The container application dependency resource also includes the dependency name of the container application, and the container application dependency resource is established before the container application is deployed or upgraded. The method further includes: receiving a first check result sent from a Container Infrastructure Service (CIS) node, and determining whether to deploy or upgrade the container application based on the first check result; the first check result is obtained by the CIS node by running the Pod corresponding to the first task.

7. A compatibility checking method, characterized in that, The method includes: Send a request message to the Container Infrastructure Service Manager (CISM); the request message includes container application dependency requirements resources or container platform provided capability resources, the container application dependency requirements resources include container application dependency requirement baseline information, the container platform provided capability resources include container platform capability baseline information; the capability baseline information includes cluster-level capability baseline information and node-level capability baseline information; the dependency requirement baseline information includes cluster-level dependency requirement baseline information and node-level dependency requirement baseline information. A first task is established to obtain a first check result, which is obtained by checking whether the container application's dependency resources meet the compatibility conditions based on the container platform's resource requirements; or, a second task is established to obtain a second check result, which is obtained by checking whether the container platform's resource requirements meet the compatibility conditions based on the container application's resource requirements. The container platform provides capability resources, including container platform capability names, which were established before the container platform upgrade. The method further includes: receiving a second check result sent from a CIS node, and determining whether to upgrade the container platform based on the second check result; the second check result is obtained by the CIS node by running the Pod corresponding to the second task.

8. The method as described in claim 6 or 7, characterized in that, The cluster-level capability baseline information includes cluster tags and / or cluster version number information; The node-level capability baseline information includes at least one of the following: node label, node version number information, and container engine information.

9. The method as described in claim 6 or 7, characterized in that, The cluster-level dependency requires the baseline information to include the cluster label and / or cluster version number. The node-level dependency requirements baseline information includes at least one of the following: node label, node version number information, and container engine information.

10. The method as described in claim 6 or 7, characterized in that, The container application includes cloud-native networking (CNF).

11. A communication device, characterized in that, It includes a module for performing the compatibility check method as described in any one of claims 1 to 5, or includes a module for performing the compatibility check method as described in any one of claims 6 to 10.

12. A communication device, characterized in that, The device includes one or more processors, which are configured to execute computer programs or instructions in memory, causing the communication device to perform the compatibility check method as described in any one of claims 1 to 5, or to perform the compatibility check method as described in any one of claims 6 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it causes the compatibility check method as described in any one of claims 1 to 5 to be executed, or causes the compatibility check method as described in any one of claims 6 to 10 to be executed.

14. A computer program product, characterized in that, Includes a computer program that, when run, causes the compatibility check method as described in any one of claims 1 to 5 to be executed, or causes the compatibility check method as described in any one of claims 6 to 10 to be executed.

Citation Information

Patent Citations

  • Container sensing scheduling method, product, device and medium

    CN118467113A

  • Intelligent upgrade workflow for a container orchestration system

    US20240193467A1