Kubernetes can facilitate communication to a master node 200 that can comprise an API server, a database, a scheduler function, and a controller manager function. For every NF, there can be a set of worker nodes comprising a cAMF 204, a cSMF 206, and/or a cUPF 208. The worker nodes make up a cluster and can comprise kubelets, a runtime container, and a kubeproxy. The kubeproxy are APIs for a service path connection. The N2 network service path can flow from a base station equipment (e.g., network node 104) to a DU and CU and then on to the kubeproxy of the cAMF 204 via a control plane connection. Then, a userplane connection can send this data to the cSMF 206 and the cUPF 208. For example, the UE 102 can request a service via the N2 control plane connection and then the cAMF 204 can identify the cSMF 206 and select the cUPF 208 to establish the session via an N3 service path, which can allow the traffic to flow to the internet via an N6 service path. The kubeproxys are non-transient objects (e.g., static) while the container runtimes are transient objections (e.g., can change anytime). Therefore, the topological visualization can be built with a non-transient object that can be supported by the kubeproxys within the clusters.

Referring now to FIG. 4, illustrated is an example schematic system block diagram of a deep service path discovery architecture according to one or more embodiments.