5g cnf是如何设计失败的

How 5G CNFs areDesigned to Fail And how to assure their resilience How 5G CNFs are Designed to Fail This document is intended for the person/persons within a mobile network operator (MNO) or networkequipment manufacturer (NEM) responsible for ensuring 5G cloud-native network functions (CNF) are resilient tocommon failure scenarios that will occur in production Kubernetes cloud deployments and wants to understandhow these failures impact overall 5G Quality of Service (QoS). Introduction The concept of "designed to fail" in relation to 5G cloud-native network functions (CNFs) in a Kubernetesenvironment revolves around building systems and applications to anticipate and gracefully handle failures.This approach acknowledges that failures are inevitable in distributed systems like 5G networks, especially whendeployed in complex, dynamic environments like Kubernetes. The goal is to design CNFs that can withstandfailures without causing any service disruptions. Kubernetes auto-healing is a critical capability that sets it apart from other cloud environments. It enablesthe "designed to fail" concept in 5G CNFs, ensuring that any system failures are automatically detected andcorrected with no human intervention. Here's how it works in relation to 5G CNFs. Figure 1 shows a typical deployment of three different 5G CNFs in a Kubernetes cluster. Each CNF has a numberof workloads that consists of a number of pods with each pod having one or more containers. The diagramalso shows the common practice workloads that are shared between the 5G CNFs. Lastly, the diagram showshow the 5G CNF workloads can be distributed across multiple nodes, but concurrently isolated within a uniquenamespace. WHITE PAPER Failure Types There are three common failure types that can arise among 5G CNFs, as shown in Figure 2. This next sectionwalks through them and their variations. Object Failures In the realm of 5G CNFs, Kubernetes plays a vital role in ensuring the resilience, scalability, and performance ofthe essential network functions for 5G services. Here's how the concepts of container, pod, and node failures arerelated to 5G CNFs: 1.Containers:5G CNFs consist of a number of microservices. At the heart of these microservices are smallapplications that run inside dedicated containers. If a container running a particular network functionfails, Kubernetes can automatically restart it. This ensures critical 5G services, like data routing or sessionmanagement, are quickly restored without manual intervention. 2.Pods:In 5G networks, one or more containers will be grouped into a single pod to provide a completenetwork function, such as a part of the core network. If an entire pod fails, Kubernetes can create a newone to replace it, ensuring that the 5G network remains functional and meets the required service levelagreements (SLAs). 3.Nodes:The infrastructure supporting 5G CNFs consists of a number of multiple nodes (servers). If a node fails,Kubernetes can automatically redistribute the affected pods to other healthy nodes. This is critical in a 5Genvironment where uptime and low latency are essential. By moving the network functions to other nodes,Kubernetes helps maintain the continuity and reliability of the 5G network. WHITE PAPER Resource Constraints Kubernetes plays a crucial role in managing resource contention, ensuring that network functions have thenecessary CPU, memory, disk, and I/O resources to operate efficiently. This is how Kubernetes manages resourcecontention for 5G CNFs: 1.CPU Contention:In a 5G network, different CNFs might compete for CPU resources on the same node.Kubernetes monitors CPU usage and can enforce limits and requests to ensure that each CNF gets its fairshare of processing power. If a CNF attempts to use more CPU than it's allocated, Kubernetes can throttleit or prioritize other critical CNFs, preventing any single function from overwhelming the node and causingperformance degradation across the network. 2.Memory Contention:Memory is vital for the smooth operation of 5G CNFs, which often handle large amountsof data in real time. If multiple CNFs on the same node start to compete for memory, Kubernetes canmanage this by ensuring that each CNF stays within its allocated memory limits. If a CNF exceeds its memoryallocation, Kubernetes might evict the pod or kill the offending containers to free up memory, therebypreventing memory exhaustion that could impact the stability of the entire node. 3.Disk Contention:5G CNFs may need to read from or write to disk frequently, such as logging, storing sessiondata, or caching. If multiple CNFs on the same node are demanding heavy disk usage, Kubernetes canmanage disk I/O through resource requests and limits, ensuring that disk contention doesn't slow downcritical network functions. Kubernetes can also move pods to other nodes with more available disk resourcesif necessary. 4.I/O Contention:Input/Output operations are crucial for 5G CNFs, especially thos