Configure service mesh networking resources for dynamically discovered peers or network functions

Abstract

The present disclosure relates to methods and systems for configuring service mesh networking resources for dynamically discovered external entities. The methods and systems create custom resource objects for services provided by external entities and dynamically create service mesh network resources for the custom resource objects. The methods and systems enable communication with external entities using service mesh network resources.

Description

Background Art

[0001] A service mesh requires deploying a complex set of networking configuration resources to implement traffic routing to external entities such as peer network functions (NFs) or external databases and servers. Previously, each different application had to implement numerous communication features and must know, for example, how to encrypt traffic, decrypt traffic, and / or perform packet capture. Consequently, when communication issues arose, resolving them became difficult because different applications executed different procedures for the communication. Summary of the Invention

[0002] According to one aspect of the present disclosure, a system is disclosed that includes one or more processors, a memory in electronic communication with the one or more processors, a data store, and instructions stored in the memory. The instructions are executable by the one or more processors to receive a request from a consumer entity at a service mesh network to register with an external entity providing a service. The service is newly discovered by the consumer entity using a network repository function in a 5G network. The instructions are also executable by the one or more processors to create a record for the service in the data store. The instructions are also executable by the one or more processors to, in response to receiving the request from the consumer entity, create a custom resource object for the service provided by the external entity. The custom resource object includes a custom resource definition that defines characteristics of the service and routing requirements for communications with the service. The instructions are also executable by the one or more processors to provide the custom resource object to a Kubernetes control plane that manages network resources for the service mesh network, and instruct the Kubernetes control plane to dynamically create one or more service mesh network resources for the custom resource object and configure the one or more service mesh network resources using the custom resource definition. The instructions are also executable by the one or more processors to enable communication from the consumer entity to access the service provided by the external entity using the one or more service mesh network resources.

[0003] The instructions are further executable by one or more processors to monitor custom resource objects and, in response to changes to the custom resource objects, perform one or more actions related to one or more service mesh network resources. The changes may include one or more of creation, modification, or deletion.

[0004] The instructions are further executable by the one or more processors to delete one or more service mesh network resources for the custom resource object in response to deletion of the custom resource object. In response to the one or more service mesh network resources being deleted, communication between the consuming entity and the external entity may be disabled.

[0005] A service may be previously unknown to the service mesh prior to receiving a request from a consuming entity.

[0006] The instructions are further executable by the one or more processors to update a record in the data store for the service with the custom resource object.The reference count may be used to identify an association with a consumer entity using the service.

[0007] The instructions are further executable by one or more processors to register a second request to a service provided by an external entity; determine that a record for the service exists in a data store, and increase a reference count for the custom resource object in the data store by one, and update the association with the service to include a second consumer entity.

[0008] The instructions are further executable by the one or more processors to enable a second consuming entity to access the service by using one or more service mesh network resources for the custom resource object for the service.

[0009] Service mesh network resources can include one or more of service entries, virtual services, destination rules, routing rules, gateways, or quotas.

[0010] Custom resource definitions can be created specifically for a service.

[0011] According to another aspect of the present disclosure, a method is disclosed, which includes receiving a request from a consumer entity at a service mesh network to register with an external entity providing a service. The service is newly discovered by the consumer entity using a network repository function in a 5G network. The method also includes creating a record for the service in a data store to maintain an association with the consumer entity using the service. The method also includes creating a custom resource object for the service provided by the external entity in response to receiving the request from the consumer entity. The custom resource object includes a custom resource definition that defines the characteristics of the service and routing requirements for communicating with the service. The method also includes providing the custom resource object to a Kubernetes control plane that manages network resources of the service mesh network, and instructing the Kubernetes control plane to dynamically create one or more service mesh network resources for the custom resource object and configure the one or more service mesh network resources using the custom resource definition. The method also includes enabling communication from the consumer entity to access the service provided by the external entity by using one or more service mesh network resources.

[0012] The method may also include monitoring the custom resource object and, in response to a change to the custom resource object, performing one or more actions related to one or more service mesh network resources. The change may include one or more of creation, modification, or deletion.

[0013] The method may also include, in response to the deletion of the custom resource object, deleting one or more service mesh network resources for the custom resource object. In response to the one or more service mesh network resources being deleted, communication between the consumer entity and the external entity may not be enabled.

[0014] The service may not be previously known to the service mesh before receiving a request from a consuming entity.

[0015] The method may also include updating a record for the service in the data store with the custom resource object and increasing a reference count of the custom resource object by 1. The reference count may be used to identify an association with a consumer entity using the service.

[0016] The method may also include receiving a second request from a second consumer entity to register a service provided by the external entity, determining that a record for the service exists in the data store, and increasing a reference count for the custom resource object in the data store by one, and updating the association with the service to include the second consumer entity.

[0017] The method may also include enabling the second consuming entity to access the service by using the one or more service mesh network resources for the custom resource object for the service.

[0018] Service mesh network resources can include one or more of service entries, virtual services, destination rules, routing rules, gateways, or quotas.

[0019] Custom resource definitions can be created specifically for a service.

[0020] According to another aspect of the present disclosure, a computer-readable medium storing instructions executable by a computer device is disclosed. The instructions include at least one instruction for causing the computer device to receive, at a service mesh network, a request from a consumer entity to register with an external entity providing a service. The service is newly discovered by the consumer entity using a network repository function in a 5G network. The instructions also include at least one instruction for causing the computer device to create a record for the service in a data store to maintain an association with the consumer entity using the service. The instructions also include at least one instruction for causing the computer device to create a custom resource object for the service provided by the external entity in response to receiving the request from the consumer entity. The custom resource object includes a custom resource definition that defines characteristics of the service and routing requirements for communicating with the service. The instructions also include at least one instruction for causing the computer device to provide the custom resource object to a Kubernetes control plane that manages network resources for the service mesh network, and instruct the Kubernetes control plane to dynamically create one or more service mesh network resources for the custom resource object and configure the one or more service mesh network resources using the custom resource definition. The instructions also include at least one instruction for causing the computer device to enable communication from the consumer entity to access the service provided by the external entity using the one or more service mesh network resources.

[0021] The computer-readable medium may also include at least one instruction for causing a computer device to monitor custom resource objects and at least one instruction for causing the computer device to perform one or more actions related to one or more service mesh network resources in response to changes to the custom resource objects. The changes may include one or more of creation, modification, or deletion.

[0022] This summary is provided to introduce a selection of concepts in a simplified form that will be further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0023] Additional features and advantages will be set forth in the description that follows. The features and advantages of the present disclosure may be realized and obtained by the systems and methods particularly pointed out in the appended claims. The features of the present disclosure will become more fully apparent from the following description and the appended claims, or may be learned by practice of the disclosed subject matter as described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] To illustrate the manner in which the above-described and other features of the present disclosure can be obtained, a more particular description will be given by reference to specific embodiments shown in the accompanying drawings. For better understanding, like elements are represented by like reference numerals in the various drawings. It will be understood that the drawings depict some example embodiments, and the embodiments will be described and explained with additional specificity and detail through the use of the drawings, in which:

[0025] Figure 1 An example system for communicating with external entities using a service mesh according to implementations of the present disclosure is shown.

[0026] Figure 2 An example service mesh according to implementations of the present disclosure is shown.

[0027] Figure 3 An example call flow for registering a new external entity with a service mesh according to an implementation of the present disclosure is shown.

[0028] Figure 4 An example call flow for registering an existing external entity with a service mesh according to an implementation of the present disclosure is shown.

[0029] Figure 5A and Figure 5B An example call flow for deregistering an external entity with a service mesh according to implementations of the present disclosure is shown.

[0030] Figure 6 An example method for configuring service mesh network resources for dynamically discovered peers according to implementations of the present disclosure is provided.

[0031] Figure 7 The diagram illustrates some of the components that may be included in a computer system. DETAILED DESCRIPTION

[0032] The present disclosure generally relates to using a service mesh to support communication. A service mesh is a dedicated infrastructure layer for handling service-to-service communication. Rather than burdening applications with implementing communication features, a service mesh abstracts communication-specific features into a single layer. By using a service mesh, common infrastructure components are responsible for functionality related to communication or service-to-service interaction. This allows applications to be isolated from functionality related to communication or service-to-service interaction, making them unaware of the communication feature implementation.

[0033] A service mesh requires deploying a complex set of networking configuration resources to enable traffic routing to external entities such as peer network functions (NFs) or external databases and servers. The service mesh supports internal signaling and messaging between microservices. When sending messages to external peers, the service mesh can be leveraged. Messages can be routed to external peers via the service mesh.

[0034] The service mesh can be managed by Kubernetes, an application programming interface (API) for coordinating microservice resources. Microservices can be deployed to run on a cluster of virtual machines, and Kubernetes can schedule containers to run on these virtual machines based on the available computing resources of the containers and the resource requirements of each container. Containers can be grouped and scaled as needed. Microservices can also be deployed to run on bare metal servers, and Kubernetes can schedule containers to run on bare metal servers. Kubernetes can also automatically manage service discovery, incorporate load balancing, track resource allocation, and can scale based on computing utilization. Kubernetes can use local resource objects to perform these functions. For example, Kubernetes can receive information through different YAML files. Kubernetes can use the received information to allocate one or more microservice resources to external entities to provide one or more services to consumer entities that may want to use the services.

[0035] Typically, when using a service mesh, each of these external peers or servers must be known in advance so that a set of service mesh configuration resources can be statically configured. The forwarding path to the external peers is typically statically configured within the service mesh itself, via configuration, before the first message is sent to the external peers. The service mesh typically needs to know the characteristics of the external peers and the ultimate route to them. Consequently, service meshes typically statically whitelist external peers by manually configuring Istio networking configuration resources, which limits the number of services that a source NF can access.

[0036] When using a dynamic environment to leverage a service mesh (such as Istio), NF peers are no longer known in advance and must be discovered dynamically through the Network Repository Function (NRF). For example, in a 5G environment, NF peers can be discovered dynamically using NRF. Thus, deploying a service mesh in a dynamic environment where NF peers are not known in advance can be difficult, as service meshes are typically statically configured to communicate with previously known NF peers.

[0037] The methods and systems of the present disclosure enable configuration of a service mesh for dynamically discovered peers.The present disclosure includes several practical applications that provide benefits and / or solve problems associated with service meshes.

[0038] These methods and systems can work in conjunction with the Kubernetes control plane to extend the functionality of the service mesh by providing additional components to the service mesh. The methods and systems can create custom resource objects for newly discovered external entities. Custom resource objects can be new types of objects associated with external entities that are used with the Kubernetes control plane.

[0039] In one implementation, a Kubernetes operator may be provided that reacts to instances of registered Custom Resource Definition Objects (CROs). The custom configuration operator reacts to the deployed CROs and any changes therein to create, modify and / or delete the set of Istio networking configuration resources in real time. The operator pattern may extend the Kubernetes API server (control plane) with a new set of (multiple) custom resource definitions or CRDs. The operator may observe the registered CROs in real time and may react to any events such as creation, deletion and / or modification and may take necessary actions by manipulating the corresponding Istio networking configuration resources. In this way, users can avoid statically configuring external entities and their respective Istio resources or whitelisting external entities and their respective Istio resources from the service mesh by providing a dynamic API to the NF application to configure newly discovered peers through the custom configuration Kubernetes operator.

[0040] The method and system may create and / or configure a service mesh network resource for a newly created custom resource object, and may use the service mesh network resource to communicate with an external host.

[0041] The method and system can program the routing of a newly discovered external host within the service grid before communicating with the external host. In this way, the method and system can enable the dynamic configuration of service grid network resources for newly discovered peers before communicating with the external host.

[0042] Now refer to Figure 1, illustrates an example system 100 used with a service mesh 106 to support communication between one or more (up to n, where n is an integer) consuming entities 102 and one or more (up to m, where m is an integer) external entities 112 via a network 104. The service mesh 106 can be used to support signaling and messaging between the external entities 112 and the consuming entities. The service mesh 106 may require the deployment of a complex set of networking configuration resources to enable traffic routing to the external entities 112. The network configuration resources may include settings for each external entity 112, such as, but not limited to, whether traffic should be encrypted, Domain Name System (DNS)-related parameters, and / or circuit break configurations. The service mesh 106 can abstract communication-specific features into a single layer, allowing messages from the consuming entities 102 to the external entities 112 to be routed through the service mesh 106 without the external entities 112 having to coordinate communications with the consuming entities 102. In one implementation, the service mesh 106 can be an Istio service mesh.

[0043] The service mesh 106 can be managed by a Kubernetes control plane 108. The Kubernetes control plane 108 can coordinate resources for the microservices 110. In one implementation, the microservices 110 can be deployed to run on a virtual machine (VM) infrastructure with a cluster of virtual machines, and the Kubernetes control plane 108 can schedule containers to run on the virtual machines based on the available computing resources of the containers and the resource requirements of each container. If necessary, the containers can be grouped and scaled. The Kubernetes control plane 108 can allocate one or more virtual machines to an external entity 112 for providing services 10 to one or more consumer entities 102. In another implementation, the microservices 110 can be deployed to run on bare metal servers, and the Kubernetes control plane 108 can schedule containers to run on the bare metal. If necessary, the containers can be grouped together.

[0044] The Kubernetes control plane 108 can also automatically manage service discovery, incorporate load balancing, track resource allocation, and can scale based on compute utilization. The Kubernetes control plane 108 can use local resource objects to perform these functions. In addition, the Kubernetes control plane 108 can receive information, for example, through different YAML files. Kubernetes can use the received information to allocate one or more resources of the microservices 110 to the external entity 112 to provide one or more services 10 to the consumer entity 102 that may want to use the service. For example, in a virtual machine implementation of the microservice 110, Kubernetes can allocate one or more virtual machines to the external entity 112 to provide one or more services 10.

[0045] Now refer to Figure 2 , showing a system 100 ( Figure 1 ). The system 100 can be a dynamic environment in which a consuming entity 102 can discover one or more services 10 provided by an external entity 112 via a network 104. In one implementation, the system 100 can be a 5G system in which the consuming entity 102 discovers one or more services 10, such as network functions (NFs) provided by the external entity 112, using one or more of the Third Generation Partnership Project (3GPP) network protocols.

[0046] The service grid 106 may include a proxy 114 that may be used to provide services to newly discovered external entities 112 ( Figure 1 ) creates a custom resource object (CRO) 14. In one implementation, the external entity 112 may be a peer network function (NF). The NF may be dynamically discovered through a network repository function (NRF).

[0047] The proxy 114 may expose one or more APIs to the consuming entities 102, and the consuming entities 102 may call the APIs in response to discovering one or more external entities 112 and / or services provided by the external entities 112. The proxy 114 may create new CROs for the one or more external entities 112 in response to the API calls generated by the one or more consuming entities 102.

[0048] A CRO 14 can be a new type of object associated with an external entity 112 for use with the Kubernetes control plane 108. A CRO 14 can be different from the native resource objects used by the Kubernetes control plane 108. A CRO 14 can include custom resource definitions that define what items the CRO 14 requires. Examples of custom resource definitions can include, but are not limited to, host presence, annotation owner presence, host information, routing information, and / or timeout information. Custom resource definitions can be specific to a service 10 and / or external entity 112 or use case. In this way, different external entities 112 can have different custom resource definitions than the CRO 14 associated with the external entity 112.

[0049] The CRO 14 may be passed to the controller 116. The controller 116 may process or control the CRO 14. The controller 116 may register with the Kubernetes control plane 108 and may notify the Kubernetes control plane 108 that the controller 116 controls the CRO 14 created by the agent 114. In this way, the Kubernetes control plane 108 may hand over the operation of the new CRO 14 for the external entity 112 to the controller 116.

[0050] The controller 116 can send a request to the Kubernetes control plane 108 to create one or more service mesh network resources 20 for the CRO 14. The service mesh resources 20 can include, but are not limited to, service entries, virtual services, destination rules, routing rules, gateways, and / or quotas. The Kubernetes control plane 108 can configure the service mesh network resources 20 with proxies and / or agents with the correct configuration. For example, the Kubernetes control plane 108 can use custom resource definitions from the CRO 14 to configure the service mesh network resources 20. The service mesh resources 20 can be used by the consumer entity 102 to communicate with the external entity 112 and access or otherwise use the services 10 provided by the external entity 112.

[0051] The service mesh 106 may also include a data store 118. The data store 118 may be a globally accessible data store that stores records 12 for one or more services 10 provided by one or more external entities 112. Each record 12 may include a CRO 14 for a service 10 provided by the external entity 112. The data store 118 may have a single record 12 for each service 10 provided by the external entity 112. Therefore, services 10 provided by the external entity 112 may not have duplicate entries in the data store 118 because the service mesh 106 may not be able to handle multiple CROs 14 for the same service 10.

[0052] In addition, each record may include a reference count 16 indicating the total number of consumer entities 102 that have requested to use the service 10 provided by the external entity 112. Each time a new consumer entity 102 requests to use the external entity 112, the reference count may be incremented. In addition, the reference count may also include an association with the consumer entity 102 that has requested to use the service 10 provided by the external entity 112 (e.g., the consumer entity 102 name may be stored along with the reference count). In this way, the data store 118 may store CROs 14 created for newly discovered services 10 provided by the external entity 112 and may maintain an association of all consumer entities that are interested in using the newly discovered service 10.

[0053] The proxy 114, controller 116, and / or data store 118 can be used in conjunction with the Kubernetes control plane 108 to allow the service mesh 106 to provide secure communication between one or more consuming entities 102 and one or more newly discovered external entities 112. Thus, instead of statically configuring the service mesh 106 with previously known external entities, the proxy 114, controller 116, and / or data store 118 can allow the service mesh 106 to be used in dynamic environments where configuration parameters or resources of the external entity 112 are unknown prior to discovery of the external entity 112.

[0054] The service grid 106 may include the following combined Figure 7 The features and functionality described herein. Furthermore, the components of the service grid 106 may include hardware, software, or both. For example, the components of the service grid 106 may include one or more instructions stored on a computer-readable storage medium and executable by a processor of one or more computing devices. The computer-executable instructions of one or more computing devices (e.g., the service grid 106), when executed by one or more processors, may perform one or more of the methods described herein. Alternatively, the components of the service grid 106 may include hardware, such as a dedicated processing device for performing a certain function or group of functions. Additionally or alternatively, the components of the service grid 106 may include a combination of computer-executable instructions and hardware.

[0055] Now refer to Figure 3 For an example call flow 300 for registering a new external entity, please refer to Figure 1 and Figure 2 The architecture of FIG300 is discussed in detail. The consumer entity 102 may want to consume a newly discovered service provided by an external entity 112. In the illustrated example, the consumer entity 102 may be a network function call control (NF CC) and the external entity 112 may be "amf-1.att.com". The consumer entity 102 may discover the service provided by the external entity 112, for example, through the 3GPP protocol. The call flow 300 may be used to notify the service mesh 106 of the external entity 112 and the service provided by the external entity 112 so that the consumer entity 102 can start using the service. Istio is used in the call flow 300 as an illustrative example of the type of service mesh 106. In this way, the agent 114 may be an Istio agent and the controller 116 may be an Istio controller.

[0056] At 302, a consumer entity 102 may send a registration message to a proxy 114 for an external entity 112. The proxy 114 may expose an API to one or more consumer entities 102 for invocation. The registration message may be in response to a REST API exposed by the proxy 114. For example, the registration message may include a name for the external entity 112.

[0057] At 304, the agent 114 may send a message with a request for the external entity 112 to the data store 118. For example, the message may include the name of the external entity 112. When created, the data store 118 may be a globally accessible data store that stores records for the external entity 112 when the CRO 14 is created for the external entity 112.

[0058] The data store 118 can verify whether a record for the external entity 112 exists, for example, by comparing the name of the external entity 112 with the records 12 stored in the data store 118. By verifying whether the external entity 112 previously existed in the data store 118, duplication of records 12 for the same external entity 112 can be prevented. The service grid 106 may not be able to handle multiple CROs 14 for the same external entity 112.

[0059] At 306, the data store 118 may send a reply message indicating that the external entity 112 was not found in the data store 118. For example, if no match occurs between the name for the external entity 112 and the record 12 in the data store 118, the data store 118 may determine that no record for the external entity 112 exists in the data store 118.

[0060] At 308, the proxy 114 may send a request to the data store 118 to create a record 12 for the external entity 112. The request may include the name of the external entity 112 and the consuming entity 102 making the request.

[0061] At 310, the data store 118 may create a record 12 for the external entity 112. The data store 118 may include a reference count 16 indicating the total number of consuming entities 102 that have requested to use the external entity 112. In the illustrative example, the consuming entity 102 (e.g., NF CC-1) may be the first consuming entity to request to use the external entity 112. As such, the reference count may be 1. Additionally, the reference count may include an association with the consuming entity 102 (e.g., consuming entity 102 name NF CC-1). The record 12 may also be used to store the CRO 14 associated with the external entity 112 upon creation. At 312, the data store 118 may send a verification message to the proxy 114 to verify the creation of the record 12 for the external entity 112.

[0062] At 314, the agent 114 may send a create message to the Kubernetes control plane 108 to create a new set of custom resource definitions (CRDs) for the new CRO 14 for the external entity 112. The create message may include any custom definitions for the CRO 14. For example, the agent 114 may identify details to be included for the CRO 14, such as, but not limited to, the name of the external entity 112 and / or information about the annotation owner for the CRO. Each CRO 14 may have a different CRD. Thus, each CRO 14 may be specifically designed for a different external entity 112. The Kubernetes control plane 108 may create a new CRO 14 for the external entity 112 using the set of custom resource definitions (CRDs) provided by the agent 114.

[0063] At 316, the Kubernetes control plane 108 may send the new CRO 14 for the external entity 112 to the controller 116. The controller 116 may already be registered with the Kubernetes control plane 108 and may have informed the Kubernetes control plane 108 that the controller 116 is responsible for the dynamically created new CRO 14. In this way, the Kubernetes control plane 108 may hand over control of the new CRO 14 for the external entity 112 to the controller 116.

[0064] At 318, the agent 114 may send an observe message to the Kubernetes control plane 108 to begin monitoring the state of the CRO 14 for the external entity 112. The observe message may allow the agent 114 to receive notifications of any updates related to changes to the CRO 14 for the external entity 112. If the consuming entity 102 begins communicating with the external entity 112 before the service mesh 106 is configured, the communication may fail. The observe message may prevent the consuming entity 102 from communicating with the external entity 112 until the service mesh 106 is configured with the correct resources for the CRO 14.

[0065] At 320, the controller 116 may send a create Istio network resources message to the Kubernetes control plane 108. The controller 116 may wake up upon receiving the CRO 14 and may instruct the Kubernetes control plane 108 to create one or more Istio network resources for the CRO 14. Istio resources may include, but are not limited to, service entries, virtual services, destination rules, routing rules, gateways, and / or quotas. The Kubernetes control plane 108 may configure a proxy and / or agent with the correct configuration for the Istio network resources.

[0066] At 322, the controller 116 may check whether the configuration of the Istio network resources is complete. The configuration of the Istio network resources for the CRO 14 may take some time to complete. During this time, the controller 116 may continue to check the status of the configuration.

[0067] At 324, the controller 116 may receive a status ready message from the Kubernetes control plane 108 in response to the completion of configuration of the Istio network resources for the CRO 14. Furthermore, at 326, in response to the completion of configuration of the Istio resources for the CRO 14, the Kubernetes control plane 108 may send a notification to the proxy 114. In this way, the proxy 114 may receive a notification indicating that the status of the CRO 14 for the external entity 112 is ready.

[0068] At 328, the proxy 114 may send a completion message to the consuming entity 102, indicating that the service mesh 106 is ready to communicate with the external entity 112. In response to receiving the completion message, the consuming entity 102 may begin communicating with the external entity 112 using Istio resources for the CRO 14. For example, the consuming entity 102 may use the service mesh 106 to access or otherwise use services 10 provided by the external entity 112.

[0069] Now refer to Figure 4 , you can refer to Figure 1 and Figure 2 100. The example call flow 400 for existing external entity registration is discussed using the architecture of FIG. 402. A consuming entity 402 may want to consume a discovered service provided by an external entity 112. In the illustrated example, the consuming entity 402 may be a different entity than the consuming entity 102 ( Figure 3 ), and external entity 112 may be the same "amf-1.att.com". Consumer entity 402 may have discovered the services provided by external entity 112, for example, through a 3GPP protocol. Call flow 400 may be used to notify service mesh 106 that consumer entity 402 wants to communicate with external entity 112 and begin using the services provided by external entity 112. Istio is used in call flow 400 as an illustrative example of a type of service mesh 106. In this manner, proxy 114 may be an Istio proxy, and controller 116 may be an Istio controller.

[0070] At 404, consumer entity 402 may send a registration message to proxy 114 for external entity 112. Proxy 114 may expose an API to one or more consumer entities 402 for invocation. The registration message may be in response to a REST API exposed by proxy 114. For example, the registration message may include a name for external entity 112.

[0071] At 406, proxy 114 may send a message with a request for external entity 112 to data store 118. For example, the message may include a name for external entity 112. Data store 118 may verify whether a record exists for external entity 112, for example, by comparing the name for external entity 112 with records 12 stored in data store 118. By verifying whether external entity 112 exists in data store 118, records 12 already created for external entity 112 in data store 118 may be used. For example, consuming entity 102 may have previously requested to use a service provided by external entity 112. Thus, data store 118 may already have records 12 for external entity 112.

[0072] At 408, the data store 118 may send a reply message to the proxy 114 indicating that the external entity 112 was found in the data store 118. For example, if a match occurs between the name for the external entity 112 and the record 12 in the data store 118, the data store 118 may determine that the record 12 for the external entity 112 exists in the data store 118.

[0073] At 410, the proxy 114 may send a request to the data store 118 to access the record 12 for the external entity 112. The request may include the name of the external entity 112 and the consuming entity 402 making the request.

[0074] At 412, the data store 118 may access the record 12 for the external entity 112. The data store 118 may include a reference count 16 that indicates the total number of consuming entities 402, consuming entities 102, that have requested to use the external entity 112. For example, if the consuming entity 102 previously requested to use the external entity 112 ( Figure 3), the reference count 16 may be increased by 1 to 2. In addition, the reference count 16 may also include an association with the consumer entity requesting to use the external entity 112 (e.g., the reference count 14 may also include the name of the consumer entity, NF CC-1 and NF CC-2). In this way, in response to a new request to use the external entity 112, the record 12 for the external entity 112 may be updated. At 414, the data store 118 may send a verification message to the proxy 114 to verify that the external entity 112 is registered and that the new request is added to the record 12.

[0075] At 418, the proxy 114 may send a completion message to the consuming entity 402 indicating that the service mesh 106 is ready for the external entity 112. In response to receiving the completion message, the consuming entity 402 may begin communicating with the external entity 112 using Istio resources for CRO 14. For example, the consuming entity 102 may use the service mesh 106 to access or otherwise use services 10 provided by the external entity 112.

[0076] In call flow 400 , in response to receiving the registration request, creation of Istio network resources in the service mesh does not occur because the Istio network resources were previously created in response to a request by consuming entity 102 to use external entity 112 , as indicated by record 12 for external entity 112 in data store 118 . Thus, consuming entity 402 can communicate with external entity 112 using the Istio network resources that have already been created for external entity 112 .

[0077] Now refer to Figure 5A and Figure 5B , you can refer to Figure 1 and Figure 2 An example call flow 500 for deregistering an external entity is discussed using an architecture based on Istio. In the illustrated example, consumer entity 402 can be Network Function Call Control (NF CC-2), consumer entity 102 can be Network Function Call Control (NF-CC-1), and external entity 112 can be "amf-1.att.com". Istio is used in call flow 500 as an illustrative example of a type of service mesh 106. In this manner, proxy 114 can be an Istio proxy, and controller 116 can be an Istio controller.

[0078] Call flow 500 may be used to deregister an external entity 112 from a service grid 106. External entity 112 may be deregistered because external entity 112 has failed and / or exited service. Another example of deregistering external entity 112 may include consuming entity 402 or consuming entity 102 no longer requiring services provided by external entity 112 and / or no longer requiring communication with external entity 112. For example, messages may no longer be sent from consuming entity 402 or consuming entity 102 to external entity 112.

[0079] At 502, consuming entity 402 may send a request to proxy 114 to deregister external entity 112. For example, consuming entity 402 may no longer wish to communicate with external entity 112 and / or may have completed using services provided by external entity 112. The deregistration message may include the name of the external entity 112 to be removed.

[0080] At 504, agent 114 may send a message to data store 118 to verify whether external entity 112 exists in a record of data store 118. Data store 118 may compare the name for external entity 112 with records 12 stored within data store 118 to verify whether a record exists for external entity 112.

[0081] At 506, the data store 118 may send a reply message to the proxy 114 indicating that the external entity 112 exists in the data store 118. For example, if a match occurs between the name for the external entity 112 and the record 12 in the data store 118, the data store 118 may send a reply message to the proxy 114 informing the proxy 114 that the record 12 exists for the external entity 112.

[0082] At 508, the proxy 114 may send a delete request to the data store 118 to delete the association with the consuming entity 402 for the external entity 112. The delete request may include the name of the external entity 112 and the consuming entity 402 identity.

[0083] At 510, data store 118 may update record 12 for CRO 14 associated with external entity 112. Data store 118 may update reference count 16 by decrementing reference count 16 by one. Furthermore, data store 118 may remove consuming entity 402 from record 12, thereby removing any association of consuming entity 402 with CRO 14 for external entity 112 from record 12. For example, if both consuming entity 402 and consuming entity 102 were associated with external entity 112 after requesting to register with external entity 112, data store 118 may reduce the reference count for external entity 112 from two to one. Furthermore, data store 118 may remove the association of consuming entity 402 from the reference count, such that the current reference count is now one, and only consuming entity 102 remains associated with the reference count. At 512, data store 118 may send a verification message to proxy 114 verifying that consuming entity 402 has been deleted from record 12 for external entity 112.

[0084] At 514, the proxy 114 may send a request to the data store 118 for a value of a reference count for the external entity 112. The request may include the name of the external entity 112. At 516, the data store 118 may provide the value of the reference count to the proxy 114. In this example, the value of the reference count may be one.

[0085] At 518, proxy 114 may verify whether the value of the reference count is greater than zero. If the value of the reference count is greater than zero, then another consuming entity may be using external entity 112. For example, consuming entity 102 may be using a service provided by external entity 112. Thus, if the value of the reference count is greater than zero, proxy 114 may not take further action with the deregistration process. The Istio resources created for service mesh 106 may remain operational, and other consuming entities may be able to access the services provided by external entity 112.

[0086] At 520, the proxy 114 may send a completion message to the consuming entity 402, notifying the consuming entity 402 that the external entity 112 has been deregistered from the consuming entity 402. In this manner, since the association between the consuming entity 402 and the external entity 112 has been removed, the consuming entity 402 may no longer be able to access services provided by the external entity 112.

[0087] At 522, consuming entity 102 may send a request to proxy 114 to deregister external entity 112. For example, consuming entity 102 may no longer wish to communicate with external entity 112 and / or may have finished using the services provided by external entity 112. The deregistration message may include the name of the external entity 112 to be removed.

[0088] At 524, the agent 114 may send a message to the data store 118 to verify whether the external entity 112 exists in the record 12 of the data store 118. The data store 118 may compare the name for the external entity 112 with the record 12 stored in the data store 118 to verify that the record 12 exists for the external entity 112.

[0089] At 526, the data store 118 may send a reply message to the proxy 114 indicating that the record 12 for the external entity 112 exists in the data store 118. For example, if a match occurs between the name for the external entity 112 and the record 12, the data store 118 may determine that the record 12 for the external entity 112 exists in the data store 118.

[0090] At 528, the proxy 114 may send a delete request to the data store 118 to delete the association with the consuming entity 102 for the external entity 112. The delete request may include the name of the external entity 112 and the identity of the consuming entity 102.

[0091] At 530, data store 118 can update record 12 for external entity 112. Data store 118 can update reference count 16 for external entity 112 by decrementing reference count 16 by one. Additionally, data store 118 can remove any associations of consuming entity 102 from record 12, such that the association of consuming entity 112 with external entity 112 is removed. For example, if consuming entity 102 is the remaining consuming entity associated with external entity 112, data store 118 can decrement reference count 16 for external entity 112 to zero. Additionally, data store 118 can remove consuming entity 102 from the reference count, such that the current reference count is now zero, with no consuming entity associated with reference count 16.

[0092] At 532, the data store 118 may send a verification message to the proxy 114, verifying that the consuming entity 102 has been deleted from the record 12 for the external entity 112. At 534, the proxy 114 may send a request to the data store 118 for the value of the reference count 16 for the external entity 112. The request may include the name of the external entity 112.

[0093] At 536, data store 118 may provide the value of reference count 16 to proxy 114. In this example, the value of reference count 16 may be zero. At 538, proxy 114 may verify whether the value of reference count is greater than zero. If the value of reference count is equal to zero, no consumer entity is currently associated with external entity 112, and therefore, external entity 112 may no longer be used by any consumer entity within system 100. In this manner, CRO 14 for external entity 112 may be removed from service grid 106.

[0094] At 540, the proxy 114 may send a delete request to the controller 116 to delete the external entity 112. The delete request may include the name of the external entity 112. At 542, the controller 116 may send a delete resource request to the Kubernetes control plane 108. The Kubernetes control plane 108 may delete the configuration for the Istio network resource associated with the CRO 14 for the external entity 112. In this way, the Istio network resource may be deleted from the service mesh 106 for the CRO associated with the external entity 112.

[0095] At 544, the controller 116 may check whether the deletion of the Istio network resources is complete. The removal of the Istio network resources for the CRO 14 may take some time to complete. During this time, the controller 116 continues to check the status of the deletion.

[0096] At 546, in response to the Istio network resources for CRO 14 being removed from the service mesh 106, the controller 116 can receive a status deleted message from the Kubernetes control plane 108. At 548, in response to the deletion of the Istio network resources for CRO 14, the Kubernetes control plane 108 can also send a notification to the proxy 114. In this way, the proxy 114 can receive a notification indicating the change to CRO 14 and that CRO 14 has been removed from the service mesh 106.

[0097] At 550, proxy 114 may send a completion message to consuming entity 102 indicating that consuming entity 102 has been deregistered from external entity 112. The services provided by external entity 112 may no longer be accessible to consuming entity 102. Furthermore, the services provided by external entity 112 may no longer be accessible to other consuming entities within system 100 without sending a new request to register with external entity 112.

[0098] Now refer to Figure 6 , used to configure service grid network resources 20 for dynamically discovered peers or network functions (NFs) Figure 2) method 600 may be performed by the service grid 106 ( Figure 1 ) is executed. For example, one or more controllers 116 ( Figure 2 ), Agent 114( Figure 3 ) and / or data storage 118 ( Figure 4 ) can perform the actions of method 600. In an implementation, the service grid 106 can be an Istio service grid. Figure 1 and Figure 2 The actions of method 600 are discussed with reference to the architecture of FIG.

[0099] At 602, method 600 may include receiving a request from a consuming entity to register with an external entity. For example, consuming entity 102 may have discovered a service 10 provided by external entity 112 via a 3GPP protocol. The external entity may be a peer network function (NF). The request may be used to notify service grid 106 that consuming entity 102 desires to access or otherwise use a service 10 provided by external entity 112. For example, consuming entity 102 may operate in a dynamic environment (such as a 5G environment) in which services 10 and / or external entities 112 may be dynamically discovered via a network repository function (NRF). In this manner, consuming entity 102 may discover new services 10 provided by one or more external entities 112 and / or may discover different services 10 provided by one or more external entities 112. In response to exposing one or more APIs to consuming entity 102, proxy 114 may receive the request from consuming entity 102.

[0100] At 604, method 600 may include determining whether a record for the external entity exists in the data store. The agent 114 may send a message with a name for the external entity 112 to the data store 118. The data store 118 may be a globally accessible data store that stores records 12 for one or more services 10 provided by the external entity 112. The data store 118 may verify whether a record 12 for the service 10 provided by the external entity 112 exists in the data store 118. By verifying whether a record 12 for the service 10 already exists in the data store 118, duplication of records 12 for the same external entity 112 may be prevented.

[0101] At 606, method 600 may include creating a record for the external entity in the data store. In response to determining that a record 12 for the external entity 112 does not exist, the data store 118 may create a record for the service 10 provided by the external entity 112. In this way, the service 10 may be unknown to the service grid 106 before the consuming entity 102 discovers the service 10. The data store 118 may include a reference count 16 indicating the total number of consuming entities 102 that have requested to use the service 10 provided by the external entity 112. Furthermore, the reference count 16 may also include an association with the consuming entities that have requested to use the service 10 provided by the external entity 112. The record 12 may also be used to store a CRO 14 for the service 10 provided by the external entity 112 upon creation.

[0102] At 608, method 600 may include creating a CRO for the external entity. The agent 114 may send a create message to the Kubernetes control plane 108 to create a new CRO 14 for the external entity 112. The create message may include any custom definitions for the CRO 14. For example, the agent 114 may identify details to include for the CRO 14, such as, but not limited to, the name of the external entity 112, routing requirements for communicating with the service 10, routing requirements for communicating with the external entity 112, information about the annotation owner, and / or any other characteristics of the service 10 and / or the external entity 112. Each CRO 14 may have a different CRD. Thus, each CRO 14 may be specifically designed for a different service 10 and / or a different external entity 112. The Kubernetes control plane 108 may dynamically create a new CRO 14 for a service 10 provided by an external entity 112 using a set of custom resource definition CRDs provided by the agent 114.

[0103] At 610, method 600 may include monitoring for changes to a CRO. Agent 114 may begin observing services 10 provided by external entity 112 on CRO 14 to monitor the status of CRO 14. Observation messages may allow agent 114 to receive notifications regarding any updates related to changes to CRO 14. Changes may include, for example, the creation of a CRO 14, the modification of a CRO 14, and / or the deletion of a CRO 14. Agent 114 may communicate the changes to controller 116. In response to receiving notification of changes to CRO 14, agent 114 and / or controller 116 may perform one or more actions. For example, when the change is the creation of a CRO 14, controller 116 may perform an action requesting the creation of one or more service mesh network resources 20 for CRO 14. In another example, when the change is the deletion of a CRO 14, controller 116 may perform an action requesting the deletion of one or more service mesh network resources 20 for CRO 14. In another example, when the change is a modification to CRO 14 , controller 116 may perform an action requesting a modification to one or more service mesh network resources 20 for CRO 14 .

[0104] At 612, method 600 may include creating a service mesh resource for the CRO. The controller 116 may receive the CRO 14 and may instruct the Kubernetes control plane 108 to create one or more service mesh network resources 20 for the CRO 14. The service mesh network resources 20 may include, but are not limited to, service entries, virtual services, destination rules, routing rules, gateways, and / or quotas. The Kubernetes control plane 108 may configure a proxy and / or agent with the correct configuration for the service mesh network resources 20. For example, the Kubernetes control plane 108 may use the custom resource definition in the CRO 14 to determine the configuration for the service mesh network resources 20. In this way, the Kubernetes control plane 108 can dynamically configure routing for newly discovered external entities 112 within the service mesh 106.

[0105] Controller 116 and / or agent 114 may monitor the status of the configuration of service mesh network resources 20. Controller 116 and / or agent 114 may receive a notification from Kubernetes control plane 108 indicating that the configuration of service mesh network resources 20 for CRO 14 is complete.

[0106] At 614, method 600 may include enabling access by the consuming entity to the external entity using the service mesh resources. Proxy 114 may send a notification to consuming entity 102 indicating that service mesh 106 is ready to communicate with external entity 112. Consuming entity 102 may begin communicating with external entity 112 using service mesh network resources 20 for CRO 14. For example, service mesh network resources 20 may enable communication between consuming entity 102 and service 10, such that consuming entity 102 may access or otherwise use service 10 provided by external entity 112.

[0107] At 616, method 600 may include accessing a service mesh resource for the CRO for the external entity. If a record 12 for a service 10 provided by the external entity 112 already exists in the data store 118, the consuming entity 102 may access the service mesh network resource 20 that has already been created for the CRO 14 associated with the service provided by the external entity 112. Instead of creating a duplicate CRO 14 and service mesh network resource 20 in response to a request from the consuming entity 102 to use the service 10 provided by the external entity 112, if another consuming entity previously requested to register with the service 10 provided by the external entity 112, the service mesh network resource 20 previously established for the service 10 provided by the external entity 112 may be used by the consuming entity 102.

[0108] At 618, method 600 may include enabling access by the consuming entity to the external entity using the service mesh resources. Consuming entity 102 may initiate communication with external entity 112 using service mesh network resources 20 for CRO 14. For example, consuming entity 102 may access or otherwise use services 10 provided by external entity 112 using service mesh network resources 20.

[0109] In this manner, method 600 may be used to dynamically create and configure service mesh resources as new network functions provided by one or more external entities 112 are discovered.

[0110] Figure 7 Illustrated are certain components that may be included within computer system 700. One or more computer systems 700 may be used to implement the various devices, components, and systems described herein.

[0111] Computer system 700 includes a processor 701. Processor 701 may be a general-purpose single-chip or multi-chip microprocessor (e.g., Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a dedicated microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. Processor 701 may be referred to as a central processing unit (CPU). Although in Figure 7Just a single processor 701 is shown in the computer system 700 , but in an alternative configuration, a combination of processors (eg, an ARM and DSP) could be used.

[0112] The computer system 700 also includes a memory 703 in electronic communication with the processor 701. The memory 703 can be any electronic component capable of storing electronic information. For example, the memory 703 can be embodied as a random access memory (RAM), a read-only memory (ROM), a magnetic disk storage medium, an optical storage medium, a flash memory device in a RAM, on-board memory included in a processor, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM) memory, a register, etc., including combinations thereof.

[0113] Instructions 705 and data 707 may be stored in memory 703. Instructions 705 may be executed by processor 701 to implement some or all of the functionality disclosed herein. Executing instructions 705 may involve using data 707 stored in memory 703. Any of the various examples of modules and components described herein may be implemented in part or in whole as instructions 705 stored in memory 703 and executed by processor 701. Any of the various examples of data described herein may be data in data 707 stored in memory 703 and used during execution of instructions 705 by processor 701.

[0114] The computer system 700 may also include one or more communication interfaces 709 for communicating with other electronic devices. The communication interface(s) 709 may be based on wired communication technology, wireless communication technology, or both. Some examples of the communication interface 709 include a Universal Serial Bus (USB), an Ethernet adapter, a wireless adapter operating according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless communication protocol, Wireless communication adapter and infrared (IR) communication port.

[0115] The computer system 700 may also include one or more input devices 711 and one or more output devices 713. Some examples of input devices 711 include a keyboard, a mouse, a microphone, a remote control device, buttons, a joystick, a trackball, a touchpad, and a light pen. Some examples of output devices 713 include speakers and a printer. One specific type of output device typically included in the computer system 700 is a display device 715. The display device 715 used with the embodiments disclosed herein may utilize any suitable image projection technology, such as a liquid crystal display (LCD), a light emitting diode (LED), gas plasma, electroluminescence, etc. A display controller 717 may also be provided for converting data 707 stored in the memory 703 into text, graphics, and / or moving images (as appropriate) displayed on the display device 715.

[0116] The various components of the computer system 700 may be coupled together via one or more buses, which may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For the purpose of clarity, the various buses are shown in FIG. Figure 7 Shown here is bus system 719 .

[0117] Unless specifically described as being implemented in a particular manner, the techniques described herein may be implemented in hardware, software, firmware, or any combination thereof. Any features described as modules, components, etc. may also be implemented together in an integrated logic device, or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be implemented at least in part by a non-transitory processor-readable storage medium comprising instructions that, when executed by at least one processor, perform one or more of the methods described herein. Instructions may be organized into routines, programs, objects, components, data structures, etc., which may perform specific tasks and / or implement specific data types, and may be combined or distributed as desired in various embodiments.

[0118] Computer-readable media can be any available medium that can be accessed by a general-purpose or special-purpose computer system. A computer-readable medium that stores computer-executable instructions is a non-transitory computer-readable storage medium (device). A computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present disclosure may include at least two distinct types of computer-readable media: a non-transitory computer-readable storage medium (device) and a transmission medium.

[0119] As used herein, non-transitory computer-readable storage media (devices) may include RAM, ROM, EEPROM, CD-ROM, solid-state drives (“SSD”) (e.g., RAM-based), flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code means in the form of computer-executable instructions or data structures and that can be accessed by a general purpose or special purpose computer.

[0120] The steps and / or actions of the methods described herein may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is required for proper operation of the method being described, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0121] The term "determining" includes a wide variety of actions, and thus, "determining" may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or other data structure), ascertaining, etc. Furthermore, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. Furthermore, "determining" may include resolving, selecting, choosing, establishing, etc.

[0122] The articles "a," "an," and "the" are intended to indicate the presence of one or more elements described above. The terms "comprising," "including," and "having" are intended to be inclusive, meaning that there may be additional elements in addition to the listed elements. Furthermore, it should be understood that reference to "an implementation" or "implementation" of the present disclosure is not intended to be interpreted as excluding the existence of additional implementations that also include the described features. For example, any element described with respect to an implementation herein can be combined with any element of any other implementation described herein. Numbers, percentages, ratios, or other values described herein are intended to include that value, as well as other values that are "about" or "approximate" the described value, as understood by one of ordinary skill in the art encompassed by the implementations of the present disclosure. Thus, the values should be interpreted broadly enough to include values that are at least close enough to the described value to perform the desired function or achieve the desired result. The values include at least the variations expected in appropriate manufacturing or production processes, and may include values within 5%, within 1%, within 0.1%, or within 0.01% of the described value.

[0123] In view of this disclosure, those skilled in the art will recognize that equivalent constructions do not depart from the spirit and scope of this disclosure, and that various changes, substitutions, and modifications may be made to the implementations disclosed herein without departing from the spirit and scope of the invention. Equivalent structures, including functional "means plus function" clauses, are intended to cover structures described herein that perform the described functions, including both structural equivalents that operate in the same manner and equivalent structures that provide the same function. It is the express intention of the applicant not to invoke means plus function or other functional requirements for any claim except those in which the "means" appears together with the relevant function. Every addition, deletion, and modification to the implementation that comes within the meaning and scope of the claims will be encompassed by the claims.

[0124] The present disclosure may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered illustrative rather than restrictive. The scope of the present disclosure is therefore indicated by the appended claims rather than by the foregoing description. Changes within the meaning and range of equivalence of the claims are to be included within their scope.

Claims

1. A communication system comprising: one or more processors; memory in electronic communication with the one or more processors; Data storage; and instructions stored in the memory, the instructions executable by the one or more processors to: receiving, at a service mesh network, a request from a consuming entity to register with an external entity that provides a service, wherein the service was discovered by the consuming entity using a network repository function in a 5G network, and wherein the service was unknown to the service mesh network prior to receiving the request from the consuming entity; creating a record for the service in the data store to maintain an association with the consumer entity using the service; In response to receiving the request from the consuming entity, creating a custom resource object for the service provided by the external entity, wherein the custom resource object includes a custom resource definition defining characteristics of the service and routing requirements for communicating with the service; Providing the custom resource object to a Kubernetes control plane that manages network resources of the service mesh network, and instructing the Kubernetes control plane to dynamically create one or more service mesh network resources for the custom resource object and configure the one or more service mesh network resources using the custom resource definition; as well as Communications from the consuming entity are enabled to access the service provided by the external entity by using the one or more service mesh network resources.

2. The system of claim 1 , wherein the instructions are further executable by the one or more processors to: monitoring the custom resource object; and In response to the change to the custom resource object, one or more actions related to the one or more service mesh network resources are performed, wherein the change comprises one or more of creation, modification, or deletion.

3. The system of claim 2, wherein the instructions are further executable by the one or more processors to: In response to the deletion of the custom resource object, deleting the one or more service mesh network resources for the custom resource object, Wherein, in response to the one or more service mesh network resources being deleted, the communication between the consumer entity and the external entity is not enabled.

4. The system of claim 1 , wherein the instructions are further executable by the one or more processors to: updating the record for the service in the data store using the custom resource object; and A reference count for the custom resource object is incremented by one, wherein the reference count is used to identify the association with the consumer entity using the service.

5. The system of claim 4, wherein the instructions are further executable by the one or more processors to: receiving, from a second consuming entity, a second request to register with the service provided by the external entity; determining that the record for the service exists in the data store; as well as The reference count for the custom resource object in the data store is increased by one, and the association with the service is updated to include the second consumer entity.

6. The system of claim 5, wherein the instructions are further executable by the one or more processors to: The second consuming entity is enabled to access the service by using the one or more service mesh network resources for the custom resource objects for the service.

7. The system of claim 1, wherein the service mesh network resources include one or more of a service entry, a virtual service, a destination rule, a routing rule, a gateway, or a quota.

8. The system of claim 1, wherein the custom resource definition is created specifically for the service.

9. A method for managing network resources, comprising: receiving, at a service mesh network, a request from a consumer entity to register with an external entity that provides a service, wherein the service was discovered by the consumer entity using a network repository function in a 5G network, and wherein the service was unknown to the service mesh network prior to receiving the request from the consumer entity; Creating a record for the service in a data store to maintain an association with the consumer entity using the service; In response to receiving the request from the consuming entity, creating a custom resource object for the service provided by the external entity, wherein the custom resource object includes a custom resource definition defining characteristics of the service and routing requirements for communicating with the service; Providing the custom resource object to a Kubernetes control plane that manages network resources of the service mesh network, and instructing the Kubernetes control plane to dynamically create one or more service mesh network resources for the custom resource object and configure the one or more service mesh network resources using the custom resource definition; as well as Communications from the consuming entity are enabled to access the service provided by the external entity by using the one or more service mesh network resources.

10. The method according to claim 9, further comprising: Monitoring the custom resource object; as well as In response to the change to the custom resource object, one or more actions related to the one or more service mesh network resources are performed, wherein the change comprises one or more of creation, modification, or deletion.

11. The method according to claim 10, further comprising: In response to the deletion of the custom resource object, deleting the one or more service mesh network resources for the custom resource object, Wherein, in response to the one or more service mesh network resources being deleted, the communication between the consumer entity and the external entity is not enabled.

12. The method according to claim 9, further comprising: updating the record for the service in the data store using the custom resource object; as well as A reference count for the custom resource object is incremented by one, wherein the reference count is used to identify an association with the consumer entity using the service.

13. The method according to claim 12, further comprising: receiving, from a second consuming entity, a second request to register with the service provided by the external entity; determining that the record for the service exists in the data store; as well as The reference count for the custom resource object in the data store is increased by one, and the association with the service is updated to include the second consumer entity.

14. The method according to claim 13, further comprising: The second consuming entity is enabled to access the service by using the one or more service mesh network resources for the custom resource objects for the service.

15. The method of claim 9, wherein the service mesh network resources include one or more of a service entry, a virtual service, a destination rule, a routing rule, a gateway, or a quota.

16. The method of claim 9, wherein the custom resource definition is created specifically for the service.

17. A computer-readable medium storing instructions executable by a computer device, the instructions comprising: at least one instruction for causing the computer device to receive, at a service mesh network, from a consuming entity, a request to register with an external entity that provides a service, wherein the service was discovered by the consuming entity using a network repository function in a 5G network, and wherein prior to receiving the request from the consuming entity, the service was unknown to the service mesh network; at least one instruction for causing the computer device to create a record for the service in a data store to maintain an association of the consumer entity using the service; at least one instruction for causing the computer device to create, in response to receiving the request from the consuming entity, a custom resource object for the service provided by the external entity, wherein the custom resource object includes a custom resource definition defining characteristics of the service and routing requirements for communications with the service; at least one instruction for causing the computer device to provide the custom resource object to a Kubernetes control plane that manages network resources of the service mesh network and instructing the Kubernetes control plane to dynamically create one or more service mesh network resources for the custom resource object and configure the one or more service mesh network resources using the custom resource definition; as well as At least one instruction for causing the computer device to enable communication from the consuming entity to access the service provided by the external entity using the one or more service mesh network resources.

18. The computer-readable medium of claim 17, further comprising: at least one instruction for causing the computer device to monitor the custom resource object; as well as At least one instruction for causing the computer device to perform one or more actions related to the one or more service mesh network resources in response to a change to the custom resource object, wherein the change comprises one or more of creation, modification, or deletion.

Images