Disaggregated Cloud-Native Network Architecture

Abstract

To provide a cloud-based network with a microservices-based application architecture.SOLUTION: A cloud-based network comprises a plurality of nodes, each executing containerized microservices that enable intent-driven operation of the cloud-based network. A resource controller that manages custom resources communicates with a master controller 210 to manage the operational and configuration state of the node and any containerized microservices within the node. The master controller enables users to monitor and automate the management of microservices and entire cloud-based network. The containerized microservices enable user-customizable rendering of the microservices, coordination of the old and new versions of the microservices, and smooth management of the plurality of nodes.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 62 / 880,268, filed July 30, 2019; U.S. Provisional Application No. 62 / 850,810, filed May 21, 2019; U.S. Provisional Application No. 62 / 805,931, filed February 14, 2019; and U.S. Provisional Application No. 62 / 753,792, filed October 31, 2018, each of which is incorporated by reference in its entirety.

[0002] The present disclosure relates to cloud-based computer networking. [Background technology]

[0003]

[0003] A computer networking system connects multiple client devices and enables data transfer between them. Existing networking solutions are insufficient to keep up with the rapid growth of cloud-based applications and data processing. Therefore, there is a need for more flexible, scalable, and efficient cloud-based network architecture solutions. Summary of the Invention

[0004] A cloud-based network has a microservices-based application architecture in which multiple nodes in a network cluster each include at least one microservice, enabling automation, increased visibility, reduced monitoring, and increased control of the network for individual microservices, nodes, and clusters.

[0005] The cloud-based network includes multiple nodes, each node including a master controller, one or more custom controllers, and one or more containerized microservices. The master controller manages the one or more custom controllers, and the custom controllers are configured to access and store custom resources that indicate the operational state of the node, the configuration state of the node, and a set of telemetry data representative of the node. At least one of the custom controllers manages the one or more containerized microservices. The cloud-based network also enables user-customizable rendering of the custom resources and dynamic updating of a command line interface (CLI) shell that displays the custom resources.

[0006] The at least one custom controller may be configured to reconcile the desired operational and configuration states of the node with the existing operational and configuration states of the node, respectively. Similarly, the master controller may be configured to reconcile different versions of multiple microservices to enable smooth functioning of the node during updates.

[0007] The nodes of the cloud-based network may be distributed across multiple clusters, and each cluster may be controlled by a master controller located in an external network cluster. A fabric controller may control the multi-cluster cloud-based network, and the fabric controller monitors, manages, and accesses each of the nodes in each cluster. [Brief explanation of the drawings]

[0008] [Figure 1] 1 illustrates a cloud-based network in accordance with one or more embodiments.

[0009] [Figure 2] 2 illustrates a node in the cloud-based network shown in FIG. 1 in accordance with one or more embodiments.

[0010] [Figure 3] 1 illustrates a method for monitoring changes in a cloud-based network according to one or more embodiments.

[0011] [Figure 4] FIG. 1 illustrates an environment in which a user may interact with a cloud-based network, according to one or more embodiments.

[0012] [Figure 5] FIG. 1 illustrates a method for dynamically rendering a cloud-based network command line interface according to one or more embodiments.

[0013] [Figure 6] FIG. 1 illustrates a process for applying updates to microservices in a cloud-based network, according to one or more embodiments.

[0014] [Figure 7] 1 illustrates a method for dynamic, model-driven micro-logging in a cloud-based network, according to one or more embodiments.

[0015] [Figure 8] 1 illustrates a method for rendering structured custom resource descriptions (CRDs) within a cloud-based network, according to one or more embodiments.

[0016] [Figure 9A] FIG. 10 illustrates a model-driven output of a CRD rendered without templating, in accordance with one or more embodiments.

[0017] [Figure 9B] 9B illustrates a templated output of the CRD shown in FIG. 9A in accordance with one or more embodiments.

[0018] [Figure 9C] FIG. 10 illustrates a templated output of a user-defined CRD in accordance with one or more embodiments.

[0019] [Figure 10] 1 illustrates a cloud-based network with multiple network clusters, according to one or more embodiments.

[0020] The drawings depict various embodiments for illustrative purposes only, and those skilled in the art will readily appreciate from the following discussion that alternative embodiments of the structures and methods described herein may be utilized without departing from the principles described herein. DETAILED DESCRIPTION OF THE INVENTION

[0021] Cloud-based networks provide users with containerized network services through microservices within each node of the network. Users can integrate their networking devices with commercial cloud service providers through the cloud-based network architecture described herein. Thus, users maintain visibility and control over their cloud-based network systems while automating network services. Cloud-based networks can also help users unify their network operations with software development and quality assurance.

[0022] FIG. 1 illustrates a cloud-based network 100 according to one or more embodiments. Cloud-based network 100 enables data packet transfer between devices. Cloud-based network 100 includes a distributed network cluster (“cluster”) 110, a time series database 140, and clients 150A and 150B. Time series database 140 connects to cluster 110 via database data link 145, and clients 150A and 150B connect to the cluster via client data links 152A and 152B, respectively. Cloud-based network 100 may include components other than those shown in FIG. 1, such as additional network nodes and / or client devices.

[0023] Distributed network cluster 110 includes multiple network nodes 120A, 120B, 120C and, in some embodiments, multiple server nodes 121A, 121B. Network nodes 120A-C and server nodes 121A-B are collectively referred to as "nodes" and are connected to one another via one or more data links 130. As described in more detail below with reference to FIG. 2, nodes 120A-C, 121A-B in cluster 110 run and / or support one or more network services to establish a cloud-based network operating system.

[0024] Examples of network nodes 120A-C include network routers, switches, or a combination thereof. Server nodes 121A-B may be, for example, server computers. The cloud-based network enables packet forwarding through hardware and / or software components. In some embodiments, the cloud-based network is deployed on server nodes 121A-B through software and on nodes 120A-C through hardware. In some embodiments, the cloud-based network is deployed on most or all of nodes 120A-C, 121A-B in cluster 110 through software.

[0025] The nodes 120A-C, 121A-B in the cluster 110 may operate independently or by distributed consensus. Each of the nodes 120A-C, 121A-B includes a master component (not shown in FIG. 1 ) that manages the operation of the respective node. In some embodiments, the master components of all the nodes 120A-C, 121A-B in the cluster 110 cooperate to enable collective operation and synchronization within the cluster. The nodes 120A-C, 121A-B may use an algorithm (such as Raft consensus, Paxos, or delegated Byzantine Fault Tolerance (“dBFT”), or some combination thereof) to manage and coordinate the operation of the nodes 120A-C, 121A-B.

[0026] Connections such as data link 130, database link 140, and client data links 152A-B enable communication coupling within cloud-based network 100. For example, connections may be established over a cable medium (such as electrical wire or optical cable) or a wireless medium (such as WiFi). Clients 150A-B may connect to nodes 120A-C, 121A-B in cluster 110 via ports on some or all of nodes 120A-C, 121A-B.

[0027] Time series database 140A stores sequential, ordered, time-stamped data. The time-stamped data may include, for example, measurements of the configuration and / or operational states of the nodes in cluster 100 taken at 60-second intervals. Time series database 140 receives and stores time series data from nodes 120A-C, 121A-B. In some embodiments, users of cloud-based network 100 may query time series database 140 to perform analysis on the operational and / or configuration states of cluster 110 and its nodes 120A-C, 121A-B and network services operating within cluster 110. The time series data in time series database 140 may be used as part of a control loop for cluster 110, which may be used, for example, to check for irregular spikes in network traffic compared to historical rates.

[0028] Clients 150A-B utilize network services provided by distributed network cluster 110. Clients 150A-B are electronic devices (such as smartphones, laptops, personal computers, and servers) that may utilize network protocols such as the Border Gateway Protocol ("BGP").

[0029] 2 illustrates a node 200 in the cloud-based network 100 shown in FIG. 1, according to one or more embodiments. Each of nodes 120A-C, 121A-B in FIG. 1 is an embodiment of node 200. Node 200 includes a time series database 205, a master controller (“master”) 210, a management controller 211, one or more external node agents 220, a third-party container 226, a host controller 230, one or more resource controllers 235A, 235B, and one or more custom controllers 236. In some embodiments, node 200 may include components other than those illustrated in FIG. 2.

[0030] Time series database 205 records time series data regarding one or more states of node 200. For example, in one embodiment, time series database 205 receives data regarding the configuration state, operational state, and telemetry of node 200. Time series database 205 provides the recorded data to time series database 140 of Figure 1. A user may query time series database 205 to identify the state of node 200.

[0031] The master 210 manages one or more states of the node 200. The master 210 includes an application programming interface ("API") server 212, a scheduler 214, and storage 216. The master 210 is connected to a management controller 211, which provides a command line interface ("CLI") that a user (e.g., a network engineer) uses to interact with the master 210, the node 200, the cluster 110, or some combination thereof. The CLI is discussed in more detail with respect to FIG. 5.

[0032] The API server 212 validates and configures data for API objects that represent the state of the nodes 200 in the cloud-based network 100. The API objects are based on API functions and follow a specific object model. For example, an API object may represent a configuration state set by a user of the cloud-based network 100. Different API objects may represent different containerized microservices, various resources, and policies (e.g., restart policies, upgrades, fault tolerance, etc.). In some embodiments, other components of the node 200 use the API objects to perform declarative automation and form control loops for maintaining various states (e.g., the operational and configuration states of the node 200). The API server 212 may register new microservices and then determine and / or derive a set of CROs that represent instantiations of the CRDs of the newly registered microservices. In some embodiments, the API server 212 services representational state transfer ("REST") operations, providing a front end to both the state of the node 200 and the state of the cluster 110 as a whole. A user may interact with the front-end provided by the management controller 211 to perform configuration and therefore operational changes to the nodes 200 and / or cluster 110, or to monitor activity (i.e., operational status) within the cluster 110.

[0033] Scheduler 214 manages scheduling for containerized microservices across multiple nodes (such as node 200) in cluster 110. Containerized microservices may be coupled together in containers (such as container 240A, described below). In some embodiments, multiple coupled microservices may be referred to as a pod. Scheduler 214 considers the individual and collective resource requirements of the newly created pod, the hardware, software, and policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines of the newly created pod and / or nodes in cluster 110. Scheduler 214 works in coordination with schedulers 214 of other nodes (such as node 200) in cluster 110 to reach consensus on scheduling tasks. For example, schedulers 214 of each node in cluster 110 work in coordination to determine the node on which a pod should be deployed.

[0034] Storage 216 stores one or more custom resource descriptions (“CRDs”) 217, which are templates for custom resources, and one or more custom resource objects (“CROs”) 218, which are operational instantiations of CRDs 217. A custom resource is a data object model that represents the data structure of a microservice or other software component. Node 200 may read from and write to storage 216. In some embodiments, storage 216 is external to node 200, in which case master 210 establishes a standard storage interface that allows various components of node 200 to access storage 216. Node 200 may access storage 216 in real time and on demand. In some embodiments, master 210 comprises two or more storages. For example, one storage may comprise a primary memory, such as random access memory (“RAM”), and a second storage may comprise a secondary memory, such as a hard drive. In one embodiment, storage 216 is etcd, which is a distributed key / value store.

[0035] The external node agent 220 maintains the containerized microservices running on the node 200 according to the configuration provided by the master 210. The master 210 provides the configuration using at least one CRD 217. In some embodiments, the external node agent 220 does not maintain one or more third-party containers 226, but can communicate with them. The node 200 may include multiple external node agents 220. The external node agent 220 may be, for example, a Kubelet. The external node agent 220 is connected to a container manager 225 and a proxy 250. The container manager 225 is a container engine (e.g., DOCKER) used to perform containerization of microservices within the node. The external node agent 220 uses the container manager 225 to maintain the containers 240 within the microservices running on the node 200. The container manager 225 is also connected to one or more third-party containers 226 or other third-party software and is used by the one or more third-party containers 226 or software to perform containerization.

[0036] Proxy 230 is a server that enables packet forwarding within node 200. Proxy 230 can proxy User Datagram Protocol ("UDP"), Transmission Control Protocol ("TCP"), and Stream Control Transmission Protocol ("SCTP") to perform stream forwarding or round-robin forwarding. For example, proxy 230 may be a kube proxy. In other embodiments, additional proxies similar to proxy 230 that perform other proxy services may be included in node 200. For example, node 200 may include a kubectl proxy, an API server proxy, etc., for various purposes, such as proxying Hypertext Transfer Protocol ("HTTP").

[0037] Resource controllers 235A-B manage and contain resources for node 200. Each of resource controllers 235A-B includes at least one custom controller 236, which is configured to manage one or more containerized microservices 245A-B. In some embodiments, node 200 includes more resource controllers and / or custom controllers than shown in FIG. 2 .

[0038] Each resource controller 235A-B has access to one or more custom controllers 236, and therefore the microservices, that it manages. In some embodiments, the resource controllers 235A-B may discover and / or instantiate new microservices and then present them to the API server 212 of the master 210 for registration and use within the node 200. Thus, the master 210 provides the resource controllers 235A-B with the desired configuration state of the node 200 and facilitates the configuration of new microservices registered within the node 200 to reach the desired configuration state. The resource controllers 235A-B also manage the operation of the microservices according to the desired operational state of the node 200 received from the master 210.

[0039] Custom controller 236 provides access to custom resources and manages containerized microservices 245A-B within node 200. Custom controller 236 includes object model 242, such as operational state CRD 243A, configuration state CRD 243B, and telemetry state CRD 243C, and one or more containers 240A-B that contain microservices 245A-B. Operational state CRD 243A is a data object that represents the actual runtime state of cloud-based network 100, configuration state CRD 243B represents the desired state of cloud-based network 100, and telemetry state CRD 243C represents an analysis of the operation of cloud-based network 100. In some embodiments, a dependency order among multiple CRDs 243A-C associated with a microservice may determine the functionality of the network service. API server 212 may relay the order in which CRDs and CROs are registered and deployed to take the dependency order into account. For example, the dependency order may be annotated in the CRD of the microservice.

[0040] Custom controller 236 includes various functions and logic for interacting with the custom resource controlled by custom controller 236. For example, custom controller 236 may include "create," "read," "update," and "delete" ("CRUD") functions specific to the data structure of the custom resource controlled by custom controller 236. Custom controller 236 may extend these functions to API server 212 to add them to the API and enable user interaction with the custom resource.

[0041] Custom controller 236 enables a control loop that periodically observes the state of one or more microservices 245A-B and / or containers 240A-B and object model 242. Custom controller 236 may also change the current state of microservices 245A-B and / or containers 240A-B to a desired state specified by object model 242. For example, a custom resource defined by object model 242 may extend the API for a particular microservice 245A within the domain of custom controller 236A, and custom controller 236A may control microservice 245A based on the functions of custom controller 236.

[0042] Microservices 245A-B are distributed software components of an application that work together to provide the application's functionality. Microservices 245A-B enable users to perform one or more intent-driven actions within cloud-based network 100. A complete networking operating system can perform many intent-driven actions. In some embodiments, microservices may manage various layers of a network protocol stack. For example, microservice 245A may manage BGP, Open Shortest Path First (“OSPF”), Intermediate System to Intermediate System (“IS-IS”), Spanning Tree Protocol (“STP”), and Link Aggregation Control Protocol (“LACP”), among other network protocol stack layers. In another embodiment, microservices 245A-B may be new cloud-native networking operating system services (e.g., service discovery or sidecar services).

[0043] Microservices 245A-B run within containers 240A-B. As described above, container manager 225 manages containers 240A-B within node 200. Containers 240A-B are individual executable software packages that contain dependencies (e.g., libraries) required for the microservices 245A-B contained within them to function independently of external resources (except for the operating system of node 200). Containers 240A-B are virtualization mechanisms at the operating system level, where multiple containers share the kernel of the operating system of node 200.

[0044] Host controller 250 is a daemon that manages control loops within node 200. Each control loop is based on controller logic and is used to change operational states to configuration states or to perform one or more functions within node 200 or cluster 110. Host controller 250 interacts with resource controllers 235A-B and custom controller 236 to maintain the control loops operating within resource controllers 235A-B and custom controller 236, respectively. With multiple resource controllers 235A-B, host controller 250 may enable multiple control loops corresponding to different resources. In some embodiments, host controller 250 is configured to automatically instantiate master 210, resource controllers 235A-B, and custom controller 236. In some embodiments, host controller 250 receives instructions to instantiate one or more controllers from another node, a network operator, a fabric controller, or any other suitable entity.

[0045] Monitoring Changes in Cloud-Based Networks FIG. 3 illustrates a method 300 for monitoring changes in a cloud-based network 100 according to one or more embodiments. Within a node 200, a master 210 dynamically selects a custom resource to monitor for changes based on a watch description (step 310). For example, the master 210 may receive a watch description from a user, who then instructs the host controller 250 to monitor the custom resource using the custom controller 236 corresponding to the custom resource. The watch description describes one or more desired parameters to monitor for changes and a change threshold at which action should be taken for at least one of the parameters. The watch description further includes one or more actions (i.e., a set of response instructions) to be taken in response to a change detected in the custom resource. For example, the watch description may specify a memory usage threshold and may flag the custom resource as unavailable in response to the custom resource exceeding the memory usage threshold.

[0046] Master 210 receives change notifications based on the operational status of the monitored custom resources (step 320). For example, host controller 250 may analyze time series data associated with the monitored custom resources. Upon detecting that a change threshold for a parameter of the custom resource has been exceeded, host controller 250 alerts master 210.

[0047] In response to the change notification from the host controller 250, the master 210 initiates a control sequence (step 330). The actions that the master 210 takes in the control sequence may be described by a watch description.

[0048] The master 210 follows a set of response instructions associated with the watch description (step 340). The response instructions may instruct the master 210 to send emails and / or instant messages to users regarding changes to the custom resource. In some embodiments, users receive notifications about changes to the custom resource via a user interface managed by the management controller 211 of the node 200.

[0049] In some embodiments, master 210 associates relevant post-control actions and takes those actions (step 350). The post-control actions may include monitoring and / or analyzing other custom resources. For example, changes in a monitored custom resource may suggest changes in other custom resources in node 200. Thus, changes in the operational state of a custom resource can trigger monitoring of other custom resources.

[0050] Dynamic and automated cloud-based network CLI rendering 4 illustrates an environment 400 in which a user 405 may interact with the cloud-based network 100, according to one or more embodiments. The environment 400 includes one or more CRDs 217, an API server 212, a user 405, a CLI microservice 410, a user-accessible command line interface (CLI) shell 420, and an information model tree 430.

[0051] The user 405 may be an operator of the cloud-based network 100 who has access to multiple microservices within the nodes.

[0052] CLI microservice 410 accesses API server 212, renders CLI shell 420, and generates and maintains information model tree 430. CLI microservice 410 is an embodiment of microservices 245A-B in FIG. 2, but is specifically configured to render CLI shell 420. CLI microservice 410 may convert the contents of CRD 217 into YANG format, as described in more detail with respect to FIG. 5.

[0053] The CLI shell 420 renders CRDs 217 associated with microservices registered with the API server 212. The CLI shell 420 allows a user 405 to view and access hierarchical objects (e.g., simulated folder-file data structures) defined by one or more CRDs in a command-line interface. The registered microservices may include microservices 245A-B of the node 200. The management controller 210 of the node 200, described with reference to FIG. 2, may provide users with access to the CLI shell 420. In one embodiment, a user communicates and / or interacts with the registered CRDs 217 over a network protocol defined and / or utilized by the API server 212 and / or the registered CRDs 217. In another embodiment, the CLI microservice 410 provides access to the registered CRDs 217 through a network interface different from that of the CLI shell 420.

[0054] Information model tree 430 determines how CLI shell 420 renders CRD 217. Information model tree 430 keeps track of relationships between multiple nodes (e.g., node 200) in cloud-based network 100 and structural information about CRD 217. In some embodiments, information model tree 430 stores hierarchical information about the structure and content of CRD 217. Information model tree 430 dynamically updates with newly registered CRDs 217.

[0055] 5 illustrates a method 500 for dynamically rendering a cloud-based network command line interface (CLI) according to one or more embodiments. The dynamic rendering of the cloud-based network CLI is performed within the cloud-based network 100, node 200, and system environment 400 shown in FIGS. 1, 2, and 4, respectively.

[0056] The API server 212 registers one or more CRDs 217 (step 510). The API server 212 may receive CRDs from client devices (such as client devices 150A-B) and / or custom controllers 236. In some embodiments, any controller in node 200 (e.g., resource controllers 235A-B, host controller 250) may register a CRD 217 with the API server 212.

[0057] Upon registering at least one CRD 217, the API server 212 notifies the CLI microservice 410 (step 520). The notification includes the structure and contents (or information describing the structure and contents) of the registered CRD 217.

[0058] The CLI microservice 410 converts the structure of the CRD 217 into YANG or another suitable language used to access or represent network state information and configuration (step 530).

[0059] Using the YANG-formatted CRD 217, CLI microservice 410 generates (step 540) information model tree 430. Alternatively, CLI microservice 410 modifies and / or contributes to the existing information model tree 430 that corresponds to the requested CRD 217, for example, by generating a new information branch found in the YANG-formatted CRD 217 in information model tree 430. In such an example, if the contents of the registered CRD 217 change, API server 212 can communicate the change to CLI microservice 410 (e.g., in real time or immediately upon detecting the change), and CLI microservice 410 can dynamically modify information model tree 430 to reflect the change in the registered CRD 217.

[0060] API server 212 may also deregister a CRD 217 due to a non-functional or out-of-date controller. In one embodiment, API server 212 may deregister a CRD 217 after user 405 uninstalls or otherwise no longer requires the use of a controller associated with the CRD 217 in node 200 of cloud-based network 100. When a CRD 217 is deregistered, API server 212 notifies CLI microservice 410, which then removes the data and structures associated with the CRD 217 stored in information model tree 430.

[0061] The CLI microservice 410 then renders the CLI shell 420 based on the information model tree 430 (step 550). In some embodiments, the CLI microservice 410 causes a client device (e.g., one of client devices 150A-B) to display the CLI, and the displayed interface may include prompts that allow the user 405 to query and / or navigate the CLI. For example, the user 405 can enter text commands into the CLI shell 420 via a keyboard or other input mechanism to view the status of objects within the network and its equipment, and to configure, navigate, and / or modify the objects. The user 405 can navigate to folders that store objects that each define a network communication protocol and can view the content / details of the protocol within the CLI shell 420. In some embodiments, the user 405 can access the API server 212 itself through the CLI shell 420.

[0062] 5 may be performed dynamically in real time, such that CLI microservice 410 does not need to generate a new information model tree 430 in response to changes in a CRD 217 or de-registration of a CRD 217. Furthermore, it should be noted that the services that API server 212 can register are not limited to services developed by entities involved in the operation of disaggregated cloud-based network 100. For example, services with CRDs 217 that are initially de-registered with API server 212 may be developed by a third party, a community, or any other suitable external source. When API server 212 registers CRDs 217 from these services, it may request CLI microservice 410 to dynamically update information model tree 430 to reflect the state of the CRDs 217 over time. Subsequently, a user accessing CLI shell 420 405can see the latest version of the CRD 217 data reflected in the dynamically updated information model tree 430 without explicitly prompting the user to request an update of the information model tree.

[0063] 2, API server 212 may register new services over time, and information model tree 430 may correspond to one or more CRDs 217. In some embodiments, API server 212 requests microservice 410 to provide information describing portions of information model tree 430 that correspond to different CRDs 217, and then combines the information describing the requested portions of the information model trees to generate a new CRD (e.g., a composite or merged CRD). Note also that in some embodiments, CLI microservice 410 generates multiple information model trees 430 (e.g., one information model tree for each CRD 217 registered or requested by API server 212, one information model tree for each service associated with API server 212, etc.).

[0064] API server 212 may be configured to notify a user when CLI microservice 410 updates information model tree 430, where the updates reflect changes in the operational state of node 200 and / or cloud-based network 100. For example, a user may choose to receive notifications when a user-specified portion of information model tree 430 is updated or generated, when a user-specified CRD is updated, when one or more actions or activities are performed in the network, when one or more objects in the information model tree are accessed, when a user-specified entity accesses a portion of the network, and / or when a user-specified service accesses API server 212 or information model tree 430. In another embodiment, API server 212 notifies user 405 of changes in the organizational structure of information model tree 430 displayed in CLI shell 420, objects in information model tree 430 accessed via CLI shell 420, or in response to any other suitable network change or activity.

[0065] Service upgrades in cloud-native network environments FIG. 6 illustrates a process 600 for applying updates to microservices in cloud-based network 100 according to one or more embodiments. Process 600 enables management of the lifecycle of network protocol services and applications implemented in the environment. Cloud-based network 100 enables non-disruptive updates and harmonization of network protocol services and applications, such as microservices. Updates to microservices within a node (such as microservices 245A-B of node 200) may include upgrading or downgrading the microservice, version, performance, or functionality. In some embodiments, process 600 is performed across multiple microservices on multiple nodes (e.g., nodes 120A-C, 121A-B).

[0066] A microservice within a node (e.g., microservices 245A-B) has a model of the configuration and operational state of the microservice, which is communicated to and registered with an API server within the node (e.g., API server 212). The API server continuously receives and records the configuration and operational state (step 610). In some embodiments, the API server accumulates or aggregates information describing the configuration and operational state of the microservice. The API server may store the state of the microservice, for example, in a database or other storage accessible by the API server (e.g., storage 216). In another embodiment, the API server itself directly manages the overall execution state of the microservice, which enables the API server to determine the operational and configuration state of the microservice immediately before applying an update to the microservice.

[0067] The API server identifies and applies updates to the microservice (step 620). In one embodiment, the API server applies updates to multiple services or controllers (step 620). When applying an update, the microservice is updated from a first operating version to a second operating version. However, during the application of an update, the memory, configuration state, and operational state of the microservice may be reset or otherwise lost.

[0068] Thus, after the update, the updated microservice can request the last configuration and operational state of the first working version of the microservice from the API server (step 630).

[0069] In response, the API server accesses and provides the requested most recent configuration and operational state for the updated microservice version (step 640). (E.g., the API server can access the last configuration and operational state from a database, storage medium, or cumulative log in which the API server stored the last configuration and operational state before the update was applied.) In some embodiments, the API server can provide the previous configuration and operational state upon application of an update to the microservice (e.g., without an explicit request from the microservice).

[0070] When a microservice is updated, the API server may reconcile the last configuration and operational states of the previous microservice version with other services implemented in cloud-based network 100 or associated with the API server (step 640). The reconciliation process may include checking whether the last configuration and operational states are outdated or otherwise incompatible with other services. If an incompatibility with other services is detected, the API server may update the configuration and operational states of the updated microservice to reconcile the incompatibility (e.g., by identifying the new configuration or operational states in light of the requirements or parameters of the services with which the upgraded microservice is incompatible). The API server may notify a user (e.g., user 405) when changes in other services occur, and the user may then explicitly or manually trigger the reconciliation process. Alternatively, the API server may be configured to automatically initiate the reconciliation process when changes, upgrades, downgrades, or modifications are applied to other services.

[0071] The API server can update and adjust the microservices to avoid or minimize interruptions to operation of or with the microservices (step 640). While applying updates to the microservices or adjusting their operational or configuration states, the API server can allow the previous version of the microservice to be completely offline and then start the new, updated microservice. The API server can enable the operation of a standby service to perform the necessary functions of the offline microservice during the transition from the old to the new version of the microservice. Alternatively, the API server can enable the start of the updated microservice while the previous version of the microservice is still running. While both microservice versions are functional and online, the API server designates one service as the standby service to perform the necessary functions under the management of the other, fully functional service. The standby service allows the data plane (the portion of the network through which user traffic passes) to continue functioning without interruption.

[0072] In some embodiments, updates to services that depend on a microservice may be put on hold or delayed while the API server updates the microservice. These services may be involved in the reconciliation process but may remain unchanged, thereby not being interrupted during the reconciliation.

[0073] Dynamic Model-Driven Micro-Logging 7 illustrates a method 700 for dynamic, model-driven micro-logging in a cloud-based network, according to one or more embodiments. A user (e.g., user 405) may want to specify logging levels for different submodules of a microservice (e.g., microservices 245A-B).

[0074] The microservice registers a logger CRD with an API server (e.g., API server 212) (step 720). The logger CRD may be one embodiment of CRD 217. The logger CRD includes a logger name, a default logging level, and a definition for each of a set of available logging levels. Each logging level specifies the verbosity or specificity at which events are logged. For example, active troubleshooting and debugging may require a logging level that captures more detail in the logs generated by the logger. The registered logger CRD may also include a list of functions that translate user or microservice requests into the logging level defined by the logger CRD. For example, a function in the logger CRD may specify that a user's request for a "debug" function or service is equivalent to a particular logging level defined by the logger CRD (e.g., "logging level 3.2" or any suitable naming convention that corresponds to a particular logging level).

[0075] Each sub-module within a microservice may operate with a configured, standard, or default logging level. During operation of a particular sub-module, different sub-modules, different services, or users may need or require a logging level that differs from the default logging level, for example, in response to wanting to get less or more information, in response to changing security requirements, or to configure a set of sub-modules or services to operate at a uniform logging level.

[0076] In response to the request to change the logging level of the sub-module, the sub-module queries the API server to obtain information regarding the requested logging level, for example, without interrupting the sub-module's services or functionality (step 740).

[0077] In response to receiving a request for information about the requested logging level, the API server can determine the requested logging level from the logger CRD. As described above, the API server can apply a conversion function to determine the logging level defined by the logger CRD that is associated with the requested logging level.

[0078] Upon identifying the requested logging level, the API server can apply the identified logging level to the requesting submodule (step 750) by reconfiguring the submodule to operate at the identified logging level (step 760). Additionally, the user can request that all submodules of the microservice inherit the global logging level, depending on which API server can identify a logging level that corresponds to the requested logging level and configure all submodules of the microservice to operate at the identified logging level simultaneously or for a threshold period of time, thereby beneficially ensuring that all submodules in the microservice are logging at the specified logging level simultaneously or nearly simultaneously.

[0079] CLI shell templates for formatting and displaying relational model information FIG. 8 illustrates a method 800 for rendering a structured custom resource description (CRD) within cloud-based network 100 according to one or more embodiments. A user (e.g., user 405) may want to customize the format of a CRD (e.g., CRD 217) displayed within a CLI shell (e.g., CLI shell 420). In some embodiments, the user may access the CLI shell using a system environment (such as system environment 400 of FIG. 4). Prior to customization, the format of the CRD's content is model- and object-driven; that is, the format varies for each CRD and CRO and may not be structured to facilitate display to a human user. The user may want to unify the format of the displayed content across multiple CRDs and CROs. The unified format of the CRD may capture relationship constraints between CROs. The user can enable customized templating of the CRD's content using CLI shell templates stored and executed by the host controller of the node containing the CRD (e.g., host controller 250 of node 200).

[0080] When executing a CLI shell template, a user specifies a desired template for rendering a CRD 217. Templates may be pre-stored on the host controller, or in some embodiments, users can write their own customized templates. The template defines metadata that describes how the CRD content is formatted when displayed. For example, the formatting metadata may specify the placement and alignment of each CRO variable and the spacing between each variable. The template may further include one or more scripts that process the CRD content according to the formatting metadata, for example, by iterating through each CRO variable in the CRD and determining whether, how, and where to display the CRO variable.

[0081] The user accesses the identified templates and CRDs in the CLI shell (step 820). In some embodiments, the user may access multiple CRDs in the CLI shell and may access one or more templates to format the accessed CRDs.

[0082] The host controller renders the CRD based on the user-specified template (step 830) and outputs the structured CRD for display within the CLI shell, through which the user may view and / or access the structured CRD.

[0083] 9A shows a model-driven output 900 of a CRD rendered without templating, according to one or more embodiments. The model-driven output 900 shows one or more CRDs 905, one or more CROs 910 associated with the CRDs, and multiple variables 915 associated with the CROs. The output 900 specifically shows the contents of two CRDs (CRD1 and CRD2), three associated CROs (CRO A, CRO B, and CRO C), and variables associated with the three variables (VAR1, VAR2, and VAR3). In some embodiments, the model-driven output 900 is presented via a CLI shell (e.g., CLI shell 420) accessible by a user (e.g., user 405).

[0084] 9B shows a templated output 950 of the CRD shown in FIG. 9A, according to one or more embodiments. A user (e.g., user 405) specifies a template that defines the structure used to render the contents of the CRD. The specified template structure in FIG. 9B identifies each CRD at the top center of the CRD portion of the display, and the specified CR D9B )。 Finally, within each CRO in the column of CROs, the template identifies variables immediately below the identified CRO. When the host controller of the node containing the CRD (e.g., host controller 250 of node 200) renders output 950, the CLI shell presents the formatted and structured CRD content to the user (as shown in FIG. 9B). Output 950 may be rendered to reflect the relational associations between multiple CRDs.

[0085] FIG. 9C illustrates a templated output 970 of a user-defined CRD, according to one or more embodiments. The new CRD may include a combination of multiple other CRDs (i.e., a composite or merged CRD) and / or components of one or more CRDs. The user can write and / or specify a template that determines the content of the new CRD. The specified template may take into account relationship constraints between the CRD and the CRO. In FIG. 9C, the new CRD 970 includes the components of the CRDs shown in FIGS. 9A-B. The new CRD 970 includes CROs A, B, and C and multiple variables 995 associated with each CRO. The variables included in the new CRD 970 are a subset of the variables 915 shown in FIGS. 9A-B.

[0086] It should be noted that while the templates described herein format CRD content based on the CROs and variables associated with it within each CRD, in fact any type of CRD object or data beyond CROs and variables may be defined and structured by a template according to the principles described herein.

[0087] Multi-cluster management and control 10 illustrates a cloud-based network 1000 with multiple network clusters 1020, 1022, and 1025, according to one or more embodiments. Cloud-based network 1000 may be substantially similar to cloud-based network 100, but includes multiple network clusters 1020, 1022, and 1025. Each of network clusters 1020, 1022, and 1025 may be substantially similar to distributed network cluster 110.

[0088] Each cluster includes one or more nodes 1010, 1012, 1014, and 1016. Each node may be substantially similar to nodes 120A-C, 121A-B, and node 200. For example, cluster 1020 includes nodes 1010 and 1012, and cluster 1022 includes nodes 1014 and 1016. Each node includes one or more microservices 1015. Each microservice 1015 is an embodiment of microservices 245A-B of node 200 described above with reference to FIG. 2.

[0089] The network cluster 1025 may be an external cluster 1025 and may include multiple master controllers, including a master controller 1030 and a master controller 1032, and a fabric controller 1060. Similar to the cluster 1020, the external cluster 1025 may be implemented within or include one or more servers within a cloud service provider, such as AWS. Each master controller monitors and controls the operational state of each of the clusters 1020, 1022. In particular, the master controller 1030 may be configured to control the cluster 1020, and the master controller 1032 may be configured to control the cluster 1022. Each master controller may be an embodiment of the master component 210. The multi-cluster cloud network environment 1000 may include more components than those described herein. For example, the cluster 1020 may include more than two nodes 1010, 1012, and each node may include or implement more than the microservice 1015.

[0090] The fabric controller 1060 monitors and controls the operation of each of the master controllers 1030 and 1032, thereby managing the clusters 1020 and 1022 across the fabric 1050. In some embodiments, the fabric 1050 may include more clusters than those shown in FIG. 10. The system may include multiple fabric controllers 1060, each assisting in load balancing and handling requests from multiple clusters. In some embodiments, one or more fabric controllers 1060 may be deployed outside of the external cluster 1025.

[0091] Upon monitoring each of the master controllers 1030 and 1032, the fabric controller 1060 determines the model to run in the clusters 1020 and 1022. The model may correspond to an API- and / or CLI-level CRD. The fabric controller 1060 is configured to determine which model runs on a subset of nodes and which model runs across the fabric 1050. The model running across the fabric 1050 may be registered and run across all nodes and clusters in the fabric 1050. The fabric controller 1060 allows different versions of models to coexist. For example, a CRD running in the cluster 1020 may be a different version than the same CRD running in the cluster 1022. In such a case, the fabric controller 1060 is configured to monitor and control both versions of the CRD across the clusters 1020 and 1022. The fabric controller 1060 also determines and stores the context in which the model runs and the operational requirements of the model. For example, a particular configuration model stored by fabric controller 1060 may be associated with nodes in cluster 1020, but not with any nodes in cluster 1022. Fabric controller 1060 may store such information regarding the model used across fabric 1050 in a database coupled to fabric controller 1060. Initially, the database of fabric controller 1060 may be fully synchronized, but when changes occur within fabric 1050, fabric controller 1060 need only synchronize the changed content. Thus, fabric controller 1060 may optimize for bandwidth utilization.

[0092] The fabric controller 1060 may use CLI shell templates (such as those described above with respect to FIGS. 9A-C) to describe and render relational model information. A user may use the CLI shell to view, access, and customize the models stored and controlled by the fabric controller 1060 (i.e., the models used within individual clusters and across the fabric 1050). The CLI shells for individual nodes may have different formats, different commands, and different modes of operation. A user may customize the CLI shell templates rendered by the fabric controller 1060 for individual nodes and for the entire fabric 1050, as described above with respect to FIG. 8.

[0093] A user may analyze the operation and performance of nodes in the fabric 1050 using CLI shell renderings of models determined and stored by the fabric controller 1060. The fabric controller 1060 also tracks the dynamic addition of new models as they are registered and executed on nodes. When a new model is registered on, for example, node 1010 of cluster 1020, the fabric controller 1060 determines that a new model has been introduced and updates the CLI shell template accordingly. The fabric controller 1060 may determine when new nodes join the network and trends across nodes in the network. The fabric controller 1060 may correlate trends with actions taken by node administrators to determine administrator intent. The fabric controller 1060 may identify discrepancies between nodes in the network and then correct the discrepancies and / or bring the discrepancies to the attention of a network administrator. Each of these trends and actions may be listed using a CLI shell template for user access.

[0094] The fabric controller 1060 may directly control operation at each of the nodes. Each node and / or cluster may grant the fabric controller 1060 permission to directly access and control the node. The fabric controller 1060 may execute microservices to operate on the nodes and / or clusters. These microservices may include, among other things, a fabric-level CLI operator for rendering the CLI shell templates described above, an Ethernet VPN operator, and a software lifecycle operator for automatically downgrading and / or upgrading model versions. The fabric controller 1060 may use each of these operators to directly control the nodes of the fabric 1050. Any updates made to a node by the fabric controller 1060 are immediately reflected at the node. Changes to the node (such as changes made by a node administrator or operator simultaneously with or independently of changes made by the fabric controller 1060) are also immediately reflected at the fabric controller 1060 level. For example, any changes to the configuration at the node 1010 are recorded by the fabric controller 1060 in real time. Thus, the fabric controller 1060 and the individual nodes each make modifications simultaneously, allowing for two-way synchronization.

[0095] The fabric controller 1060 may receive user input for fabric-wide configuration instructions and translate the instructions to be executable on each target node. A user may provide fabric-level configuration instructions to the fabric controller 1060, which means implementing the configuration across both clusters 1020 and 1022 of the fabric 1050. The fabric controller 1060 may translate the configuration instructions for each cluster and each node and configure each node according to the user's intent and within the context of the node itself. For example, a user may provide instructions to the fabric controller 1060 to configure a virtual LAN (VLAN) on some of the nodes in the fabric 1050. Each of the nodes may operate with different versions of software, and the fabric controller 1060 can reconcile the differences in software versions to ensure that the VLAN is configured across the target nodes. The fabric controller 1060 may be able to resolve any violations in the node-level configuration. While reconciliation logic for node-level configuration violations may require user input, the fabric controller 1060 can determine the capabilities of each software version and configure each node based on those software versions to implement fabric-wide configuration instructions.

[0096] Other points to note The features and advantages described herein are not all-inclusive, and many additional features and advantages will become apparent to those skilled in the art, particularly in light of the drawings, specification, and claims. Furthermore, it should be noted that the language used herein has been chosen primarily for ease of reading and guidance, and not to delineate or limit the subject matter disclosed.

[0097] It should be understood that the drawings and description have been simplified to illustrate elements relevant to a clear understanding of the invention, but that for clarity, many other elements found in a typical online system have been omitted. Those skilled in the art will recognize that other elements and / or steps are desirable and / or necessary in implementing the embodiments. However, because such elements and steps are well known to those skilled in the art and do not facilitate a better understanding of the embodiments, a discussion of such elements and steps is not provided herein. The present disclosure covers all variations and modifications to such elements and methods known to those skilled in the art.

[0098] Some portions of the above description describe embodiments in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to effectively convey the substance of their work to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Further, it has proven convenient at times to refer to arrangements of these operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combination thereof.

[0099] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification do not necessarily all refer to the same embodiment.

[0100] Some embodiments may be described using the terms "coupled" and "connected," along with their derivatives. It should be understood that these terms are not intended as synonyms for each other. For example, some embodiments may be described using the term "connected" to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments may be described using the term "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other. The embodiments are not limited in this context.

[0101] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "had," or any other variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus comprising a list of elements is not limited to only those elements, but may include other elements not expressly listed or inherent in such process, method, article, or apparatus. Furthermore, unless expressly stated otherwise, the word "or" refers to an inclusive "or," not an exclusive "or." For example, condition A or B is satisfied by either: A is true (or present) and B is false (or absent); A is false (or absent) and B is true (or present); or both A and B are true (or present).

[0102] Furthermore, the use of the indefinite article "a" or "an" is used to describe a plurality of elements and components of the embodiments herein. This is done merely for simplicity and to give a general sense of the various embodiments. The description should be read to include one or at least one, and the singular also includes the plural unless it is clear that otherwise is intended.

[0103] After reading this disclosure, those skilled in the art will recognize still other structural and functional designs for systems and processes for displaying charts using distorted fields through the principles disclosed herein. Thus, while specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise structure and components disclosed herein. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope, as defined by the appended claims. The present disclosure can also be realized in the following forms. [Form 1] A cloud-based network comprising a plurality of nodes, each node comprising: a master controller; one or more custom controllers managed by the master controller, the one or more custom controllers configured to access and store custom resources, each custom resource comprising: the operational state of the node; The configuration state of the node; and one or more custom controllers including a set of telemetry data representative of the node; one or more containerized microservices managed by at least one of the custom controllers; A cloud-based network. [Form 2] 10. The cloud-based network of claim 1, wherein at least one containerized microservice enables execution of one or more intent-driven actions within the cloud-based network. [Form 3] 2. A cloud-based network according to claim 1, wherein the plurality of nodes are managed by an external system. [Form 4] 2. The cloud-based network according to claim 1, wherein the node further comprises: A cloud-based network comprising a host controller configured to instantiate the master controller and the custom controller. [Form 5] 2. A cloud-based network as described in claim 1, wherein data is stored external to the node and is accessible on demand. [Form 6] A cloud-based network as described in form 1, wherein the master controller comprises an application programming interface (API) server, and the master controller is configured to establish a standard storage interface using the API server. [Form 7] 7. A cloud-based network as described in claim 6, wherein the data stored outside the node is accessed by a custom controller via the standard storage interface. [Form 8] 10. The cloud-based network of claim 1, wherein the at least one custom controller further comprises: from the master controller a desired operational state of the node; and receiving a desired configuration state for the node; reconciling the operational state and the desired operational state of the node; A cloud-based network configured to coordinate the configuration and the desired configuration of the nodes. [Form 9] 2. The cloud-based network according to claim 1, wherein the master controller further comprises: From microservices The operational state of the microservice; and receiving a configuration state of the microservice; the operational state and the configuration state relate to a current version of the microservice; To the microservice, a second operational state of the microservice; and providing a second configuration state of the microservice; the second operational state and the second configuration state are associated with a second version of the microservice; a cloud-based network configured to coordinate the current version and the second version of the microservice with one or more other microservices. [Form 10] 10. The cloud-based network of claim 1, wherein at least one containerized microservice is a command line interface (CLI) microservice configured to render the custom resources stored by the custom controller for display to a node operator. [Form 11] A cloud-based network as described in claim 1, wherein the plurality of nodes comprises a cluster, and the cluster includes one of a plurality of clusters each comprising a corresponding set of nodes in the cloud-based network. [Form 12] 12. The cloud-based network according to claim 11, wherein at least one cluster is an external cluster, and the external cluster: a plurality of master controllers, each master controller configured to manage one of the plurality of clusters; a fabric controller; A cloud-based network. [Form 13] 13. The cloud-based network according to claim 12, wherein the fabric controller: monitoring each of the plurality of master controllers; managing each of the plurality of master controllers; accessing each of the plurality of nodes in each cluster; A cloud-based network configured to manage each of the plurality of nodes in each cluster. [Form 14] 1. A method for managing a cloud-based network, comprising: The method includes a step of generating and managing a plurality of nodes, each of which includes: a master controller; One or more custom controllers, One or more containerized microservices; Equipped with The step of managing each of the nodes includes: managing, by the master controller, the one or more custom controllers; managing the one or more containerized microservices with at least one custom controller; accessing and storing custom resources; Each custom resource contains the operational state of the node; The configuration state of the node; and a set of telemetry data representative of said node; A method comprising: [Form 15] 15. The method of claim 14, wherein at least one containerized microservice enables execution of one or more intent-driven actions within the cloud-based network. [Form 16] 15. The method of claim 14, wherein the plurality of nodes are managed by an external system. [Form 17] 15. The method of claim 14, wherein each node further comprises: The method comprises a host controller configured to instantiate the master controller and the custom controller. [Form 18] 15. The method of claim 14, wherein the at least one custom controller: from the master controller a desired operational state of the node; and receiving a desired configuration state for the node; reconciling the operational state and the desired operational state of the node; A method configured to reconcile the configuration and the desired configuration of the node. [Form 19] 15. The method of claim 14, wherein the master controller further comprises: From microservices The operational state of the microservice; and receiving a configuration state of the microservice; the operational state and the configuration state relate to a current version of the microservice; To the microservice, a second operational state of the microservice; and providing a second configuration state of the microservice; the second operational state and the second configuration state are associated with a second version of the microservice; The method is configured to reconcile the current version and the second version of the microservice with one or more other microservices. [Form 20] 20. The method of claim 19, wherein at least one containerized microservice is a command line interface (CLI) microservice configured to render the custom resources stored by the custom controller for display to a node operator.

Claims

1. A cloud-based network comprising a plurality of nodes, each node comprising: a master controller; one or more custom controllers managed by the master controller, the one or more custom controllers configured to access custom resources stored in a storage device, each custom resource comprising: node operational status data relating to the operational status of the node; Node configuration state data relating to the configuration state of the node; and one or more custom controllers including a set of telemetry data representative of the node with respect to an analysis of the node's operation; one or more containerized microservices managed by at least one of the custom controllers; A cloud-based network.

2. 10. The cloud-based network of claim 1, wherein at least one containerized microservice enables execution of one or more intent-driven actions within the cloud-based network.

3. The cloud-based network of claim 1 , wherein the plurality of nodes is managed by an external system.

4. 10. The cloud-based network of claim 1, wherein the node further comprises: A cloud-based network comprising a host controller configured to instantiate the master controller and the custom controller.

5. 10. The cloud-based network of claim 1, wherein data is stored external to the nodes and is accessible on demand.

6. 6. The cloud-based network of claim 5, wherein the master controller comprises an application programming interface (API) server, and the master controller is configured to establish a standard storage interface with the API server.

7. 7. The cloud-based network of claim 6, wherein the data stored external to the node is accessed by a custom controller via the standard storage interface.

8. 10. The cloud-based network of claim 1, wherein at least one containerized microservice is a command line interface (CLI) microservice configured to render the custom resources stored by the custom controller for display to a node operator.

9. 2. The cloud-based network of claim 1, wherein the plurality of nodes comprises a cluster, the cluster including one of a plurality of clusters each comprising a corresponding set of nodes in the cloud-based network.

10. 1. A method for computer-implemented management of a cloud-based network, comprising: The method includes a step of generating and managing a plurality of nodes by the computer, wherein each node a master controller; one or more custom controllers; one or more containerized microservices; Equipped with The step of managing each of the nodes by the computer includes: the master controller as the computer managing the one or more custom controllers; The at least one custom controller as a computer manages the one or more containerized microservices; accessing a custom resource stored in a storage device by the at least one custom controller as the computer; Each custom resource contains node operational status data relating to the operational status of the node; Node configuration state data relating to the configuration state of the node; and a set of telemetry data representative of the node with respect to an analysis of the operation of the node.

11. 11. The method of claim 10, wherein at least one containerized microservice enables execution of one or more intent-driven actions within the cloud-based network.

12. The method of claim 10 , wherein the plurality of nodes is managed by an external system.

13. 11. The method of claim 10, wherein each node further comprises: The method comprises a host controller configured to instantiate the master controller and the custom controller.

Images