This section outlines the CNF requirements and how CNF can be onboarded and instantiated in TCP.

HELM Charts

Helm is the default package manager in Kubernetes, and it is widely leveraged by CNF vendors to simplify container packaging. With Helm charts, dependencies between CNFs are handled in the formats agreed upon by the upstream community; allowing Telco operators to consume CNF packages in a declarative and easy to operate manner. With proper version management, Helm charts also simplify workload updates and inventory control.

Helm repository is a required component in the Telco Cloud Platform. Production CNF Helm charts must be stored centrally and accessible by the Tanzu Standard for Telco Kubernetes clusters. To reduce the number of management endpoints, the Helm repository must work seamlessly with container images. A container registry must be capable of supporting both container image and Helm charts.

CSAR Design

Network Function (NF) Helm charts are uploaded as a catalog offering wrapped around the ETSI-compliant TOSCA YAML (CSAR) descriptor file. The descriptor file includes the structure and composition of the NF and supporting artifacts such as Helm charts version, provider, and set of pre-instantiation jobs. 5GC Network Functions have sets of prerequisite configurations on the underlying Kubernetes cluster. Those requirements are also defined in the Network Function CSAR. The summary of features supported by the CSAR extension is:

  • SR-IOV Interface configuration and addition, along with DPDK binding

  • NUMA Alignment of vCPUs and Virtual Functions

  • Latency Sensitivity

  • Custom Operating system package installations

  • Full GRUB configuration

The following table outlines those extensions in detail:

Component

Type

Description

node_components

Kernel_type

Type of Linux Kernel and version.

Based on the Kernel version and type, TCA downloads and installs from VMware Photon Linux repo during Kubernetes node customization.

kernel_args

Kernel boot parameters: Required for CPU isolation and so on. Parameters are free-form text strings. The syntaxes are as follows:

  • Key: the name of the parameter

  • Value: the value corresponding to the key

Note: The Value field is optional for those Kernel parameters that do not require a value.

kernel_modules

Kernel Modules are specific to DPDK. When the DPDK host binding is required, the name of the DPDK module and the relevant version are required.

custom_packages

Custom packages include lxcfs, tuned, and pci-utils. TCA downloads and installs from VMware Photon Linux repo during node customization.

network

deviceType

Types of network device. For example, SR-IOV.

resourceName

Resource name refers to the label in the Network Attachment Definition (NAD).

dpdkBinding

The PCI driver this device must use. Specify "igb_uio" or "vfio" in case DPDK or any equivalent driver depending on the vendors.

count

Number of adapters required

caas_components

CaaS components define the CaaS CNI, CSI, and HELM components for the Kubernetes cluster.
CSAR files can be updated to reflect changes in CNF requirements or deployment model. CNF developers can update the CSAR package directly within the TCA designer or leverage an external CICD process to maintain and build newer versions of the CSAR package.

Design Recommendation

Design Justification

Design Implication

Deploy all containers using the TCA Manager interface.

Direct access to the Kubernetes cluster is not supported.

Some containers may not be available with a CSAR package to be deployed through TCA.

Define all CNF infrastructure requirements using the TOSCA CSAR extension.

When infrastructure requirements are bundled into the CSAR package, TCA provides placement assistance to locate a Kubernetes cluster that meets CNF requirements.

If TCA cannot place the CNF workload due to the lack of resources, TCA leverages the node Operator to update an existing cluster with the required hardware and software based on the CSAR file definition.

CNF developers must work closely with CNF vendors to ensure that the infrastructure requirements are captured correctly in the CSAR file.

Store the TOSCA-compliant CSAR files in a GIT repository.

  • GIT repository is ideal for centralized change control.

  • CSAR package versioning, traceability, and peer review are built into GIT when a proper git-flow is implemented and followed.

Git and Git-flow is outside the scope of this reference architecture guide.

Develop a unit test framework to validate each commit into the GIT repository.

A well-defined unit test framework catches potential syntax issues associated with each commit.

Unit test framework is outside the scope of this reference architecture guide.

Leverage existing CI workflow to maintain the builds and releases of CSAR Packages.

Modern CI pipeline fully integrates with GIT and unit test framework.

CI pipeline is outside the scope of this reference architecture guide.
Note:

VMware Offers a certification program for CNF and VNF vendors to create certified and validated CSARs packages.

RBAC Design

To implement robust object-level access control, the TCA Orchestrator offers a well-defined inventory model to ensure that TCA system administrators can easily assign permissions to CNF users based on RBAC. The TCA system RBAC is based on the design principle of assigning roles and privileges at the highest object level and use advanced filters to assign or group object permissions to child objects in the inventory.

TCA creates a set of system default roles out of the box. For information about privileges associated with the specific role, see Privileges and Roles. Personas defined in the Telco Cloud Automation Architecture Overview section, any other persona beyond default roles in TCA, and custom roles are supported. Custom roles can be built on top of permissions exposed by default system roles and can only be created by the TCA Admin. In addition, any role can have multiple filters associated as rules. Filters can be defined based on CNF vendor, object tags, and so on. The TCA framework evaluates all the filters across all rules as a boolean AND of all filter results.

Design Recommendation

Design Justification

Design Implication

Use TCA custom roles to create personas that align most with operational processes.

  • Custom roles are built based on permissions exposed by default system roles.

  • TCA admins can use custom roles to add or remove permissions required by a different persona.

  • Maintaining custom roles can be operationally expensive, if requirements are not defined properly.

  • Adopt custom role after the operational requirements are solidified.

Use TCA custom permissions to create advanced filter rules for the VIM, catalog, and inventory access control.

Custom permissions ensure that objects created by one group of users are not accessible by a different group of users of the same role.

  • Maintaining custom permissions can be operationally expensive, if organizational alignments are not well defined.

  • TCA admins must ensure that the right permissions are assigned to the right group of users.