Watch Full VMware Telco Cloud Platform 5G Demo – Simplifying CNF Operations with Automation
One of the key benefits of VMware Telco Cloud Platform is its late binding feature, which dynamically configures the underlying infrastructure resources based on the requirements of CNFs to be deployed. This feature prevents overprovisioning of the valuable hardware resources because the platform allocates pass-through resources only at the time of CNF deployment.
In Part 1 and Part 2 of this blog series, we deployed a Tanzu Kubernetes cluster. Now let’s look at how the late binding feature works by instantiating a CNF.
First, add a sample CNF catalog into the registry by selecting the descriptor file corresponding to the CNF.
As shown below, you can customize a CNF’s infrastructure according to its unique requirements. Customizing the infrastructure requirements enables you to create a cluster and then instantiate and deploy the network functions without any manual user inputs.
Before we Instantiate the CNF, let’s check the current capacity settings on the workload cluster nodes by logging in to the management node and checking the network settings through the vSphere client UI.
Below you can see that the current settings for HugePages is set to 0 by default.
From vSphere client UI you can see that the workload cluster node has only one Network adapter defined.
Next, instantiate the CNF by selecting the catalog we just updated.
Provide a Namespace and select default Repo URL.
Enter any pre-instantiation properties necessary for your CNF. Upload a corresponding descriptor YAML file with the new Helm Chart values. In this demo we downloaded the descriptor file from github registry. and instantiate the CNF.
As shown below, Telco Cloud Platform checks the current node settings and shows what the desired state will be after the CNF is instantiated.
The cluster is customized according to the differences detected between the CNF catalog and the actual configuration present in the cluster during instantiation.
Now let us instantiate the CNF.
During customization, the VMConfig plug-in tries to fit the virtual machines to the correct NUMA nodes of the ESXi server based on its SR-IOV, Passthrough, and Pinning specifications. On vSphere Web Client, we can see that each node in the node pool is modified with the addition of two SR-IOV network adapters.
From the workload cluster CLI, it’s evident that the Huge pages configuration has been modified.
Also, from the vSphere Client UI, it’s evident that the workload cluster node has been modified with two additional SR-IOV network adapters. This modification was triggered by the requirements specified in the CNF override file.
Once the necessary changes are implemented to the node pool, the CNF will be instantiated successfully.
The advantage of deploying Kubernetes clusters through VMware Telco Cloud Automation is that it customizes the Kubernetes clusters according to the network function’s requirements before the CNF is deployed.
This concludes the last Part 3 in the blog series of Simplifying Kubernetes Operations using VMware Telco cloud Platform.
To summarize, with VMware Telco Cloud Platform and its automation capabilities, deploying Kubernetes clusters and instantiating CNFs has never been easier. Your operations are simplified and consistent across multiple clouds and your OpEx is reduced.
You can finally focus on your innovation and introduce new services to the market faster.
