Does Kubernetes finally move the Core network deployments to cloud standard?

The transformation of core network solutions toward agility and fast service provision is a long journey. This is not only about technical stack modification but also involves transforming the operational framework.

The goal of this article is high level overview of cloud journey with first hopes, failure and steps toward goals

?

First phase - Virtualization

?The first step began around 2015 when the first converged, virtualized vCNs were commercially launched. It all started with VM-based VNFs, where VNFI was provisioned by OpenStack or VMware. The driving forces behind this development were the desired reductions in CAPEX (Capital Expenditure) and OPEX (Operational Expenditure), as connectivity business models faced pressure due to increasing bandwidth requirements and the need for more efficient resource utilization.

?Virtualization benefit sources:

• ?Virtualization has a significant positive impact on OPEX if automation is efficiently implemented throughout the entire VNF lifecycle: from service orchestration to self-healing and auto-scaling.
• Virtualization has a substantial positive impact on CAPEX due to pooling and maximizing the utilization of COTS servers. CAPEX and OPEX optimization always involve trade-offs, and I will provide a real example later.

The first virtualization vEPC was partial solution because most vendors followed the 'lift and shift' type of VNF deployment, and limitations started to surface . Operationally, each VNF had to go through a complete lifecycle of sizing, deployment, configuration and upgrades. Each VNF had its own customer-specific redundancy scheme and was managed through its unique interface and policy engine. Under these conditions, the possibilities for automation were limited.

?Summing up the first phase lessons:

1. ??CAPEX Optimization and VNFI Utilization: The pursuit of CAPEX optimization led to the use of VNFI (Virtual Network Functions Infrastructure) at levels previously accepted in proprietary solutions. However, new features like self-healing and auto-scaling require additional VNFI capacity. As a result, striving for CAPEX efficiency often led to increased OPEX due to the need for expanding VNFI capacity with each VNF deployment, complicating maintenance operations.
2. ???Limitations of 'Lift and Shift' Migration: This approach restricted the automation capabilities of VNFs. For instance, auto-scaling processes were confined to the VIM (Virtual Infrastructure Manager) layer, and finding an efficient MANO (Management and Orchestration) solution became a crucial challenge for VM-based VNFs. It is not feasible to autoscale the whole VNFs, in other word automatically launch new?identical replicas, due to required customized manual integration tasks. So if you need the new VNF it brings back the traditional workflow.?All expected time-to-market benefits disappear.

?Lessons learned

?The industry has defined a clear path toward cloud-native solutions. From my perspective, telcos should maintain VNFI utilization significantly below the levels of proprietary solutions to preserve VNFI elasticity. This elasticity is essential to quickly spin up VNFs (Virtual Network Functions) in response to changing demand.

Despite this being an obvious solution, its implementation requires a cultural transformation, and it has faced resistance within organizations

??Second step - Telco cloud

?The lesson from the first phase is that virtualization can bring agility while reducing costs, but only with a service-based architecture, elastic infrastructure, catalog-driven services, and reuse of components. These are characteristics of a cloud-native solution.

This new approach is gaining market share with 5GC adoption because 5GC has been designed based on a service-based architecture with the cloud-native approach as an assumption. CNF (Cloud Network Function) is replacing VNF, and CNFVI((Cloud Network Functions Virtualization Infrastructure)) is replacing NFVI.

?* I have added the example of ref architecture just for general understanding I don't have the goal to dive in technical details.

Deployment stack

?The the Kubernetes (K8S) as container orchestrator and the Docker as container runtime are de facto standards for?IT infrastructure??now and Telcos are widely adopting it.

?

The biggest advantage of K8S is the shift from an imperative to a declarative provisioning approach, which widely opens the door to automation. This shift elevates human provisioning to a high-level architectural abstraction, enhancing deeper thinking. By focusing on architectural-level thinking and automated implementation, an environment is created for dynamic systems provisioning, which aligns with the nature of 5GC slices, rather than concentrating on specific CNF characteristics.

?If you have experience with imperative system commissioning, you'll know that a significant portion of issues arise from the miss-translation of initial plans into low-level configurations, leading to errors and inconsistencies.

In contrast, the declarative approach involves defining the desired state in high-level manifests, with implementation carried out automatically via defined APIs. This process makes all stages transparent and verifiable, thereby eliminating the causes of issues mentioned above

?

Despite these advantages, K8S adoptions face resistance like any other new solutions

The Cloud Native Computing Foundation (CNCF)?conducted telco survey in 2022 to get people’s biggest concerns or challenges in adopting K8S: networking (57.14%) was on first place, interoperability between different network subsystems (like vIMS, vEPC ect) was on the?second (42.86%) , ?cluster management and complexity both were on?third with 33.33%.

?These challenges have been?overcome by wide and active?CNIs and Ingress controllers communities.??They have adopted the telco-specific protocols (SCTP, Diameter and GTP), acceleration technologies ( SR-IOV and DPDK) and?Pods multi-homing capability in K8S clusters (Multus CNI).

?The most?promising deployment stack in 2023 is containers on bare metal orchestrated by K8S to maximize the HW utilization and improve the telco critical forwarding performance. All major telcos vendors have adopted this stack in their portfolios.

The CNF architecture is commonly realized through a Kubernetes Cluster that utilizes Deployment or StatefulSet API objects to define and manage the desired state of the CNFs. Deployment inherently supports cloud-native features such as auto-scaling, auto-healing, and rolling upgrades up to the entire CNI level.

Furthermore, the Ingress resource, tailored to support telco-specific protocols, serves as a gateway or entry point for CNFs to connect with external networks, facilitating system integration

?

Operational shift

Technological development and operational culture go hand in hand.

Embracing new cloud native technologies requires the culture that encourages innovation, collaboration, and continuous improvement. It requires openness to change, willingness to experiment, and a proactive mindset to adapt to emerging trends and practices.

?The telco community is adopting GitOps, promoted by the DevOps movement, and AIOps (Artificial Intelligence for Operations), promoted by TM Forum, as operational frameworks that benefit from a powerful synergy.

?GitOps fundamentally alters deployment and operational processes by using a version-controlled repository, such as Git, as the single source of truth for the system's desired state. This repository stores deployment manifests, facilitates change management, and automates Continuous Deployment, enabling essentially a zero-touch operation.

An additional benefit of GitOps is that it relies on self-updating executable documentation, which are typically K8S manifests. These manifests, written in a human-readable YAML format, are automatically kept consistent with K8S cluster deployments by the GitOps agent, such as ArgoCD or Flu.

Reference to operation pain-points

?Let's compare the GitOps flow with the traditional workflow in telecommunications. In the traditional workflow, planning begins with data in xls or doc formats. This data must be manually converted into configuration scripts and tasks are then assigned to the operational team. Following this, there's a waiting period for their confirmation before starting the validation process. Issues such as configuration drift can arise due to ongoing operations. Additionally, it's common to find that only one person has in-depth knowledge of how a specific subsystem is designed and functions. This approach, in the context of today's technological landscape, appears archaic

The AIOps framework concentrates on automatically analyzing and extracting insights from various types of collected data, such as performance metrics, log files, traces, and so forth. The issues identified through this analysis are then fed back into the GitOps workflow, leading to updates in the declarative infrastructure manifests. This integration is where the synergy happens, effectively bridging the feedback loop with the Infrastructure as Code (IaC) environment

?

Vodafon, Orange, Telstra and many other benefit from GitOps/AIOps synergy.

Don’t forget the first virtualization lessons

The technological stack is characterized by a clear layer structure, where the performance and efficiency of higher levels depend on the layers beneath them. While Kubernetes (K8s) introduces efficiency, realizing its full potential demands elasticity at the CVNFI layer, essentially maintaining a consistently low level of utilization.

As previously mentioned, this requirement can often conflict with the widely adopted planning approaches that are based on proprietary timelines

Conclusion

The adoption of the K8s ecosystem, which is both amazing and rapidly growing, significantly shifts the telecom technology stack and operations into the cloud-native era.

The ecosystem differentiating Kubernetes (K8s) from OpenStack lies in the nature of their impact: while OpenStack generally changes the technology stack, K8S revolutionizes technology stack and culture.