Enterprise and 5G Software Application packaging using Helm

Always great to start as a programmer

As most prolific developers consider Kubernetes as the future platform for application development , obviously against odds of Project Pacific https://blogs.vmware.com/vsphere/2019/08/introducing-project-pacific.html) . It is certainly worthy to know a platform that holds the future by learning how to best use it .

An investigation in to Kubernetes platform will reveal that although Kubernetes as platform is a kitchen with Recipe for all sort of applications in any vertical  however things can become very complex as we implement H/A , Load balancers  and other complex scnerio each of which require its own YAML definition and instance creation. In addition, as we apply more and more complex concepts like node affinity and taints it becomes more difficult to remember parameter definitions and to build configurations. Then in addition to this there are so many tools both in community and provided by partner distros followed by Geeks who are always willing to build their own tools so question is how to unify and address the challenges in the most efficient manner.

Can I use a collection of tools like Ansible + Mesos + Vagrant + Helm to use the best of all solve the Infra provisioning and monitoring issues?

 Obviously, no one tool can satisfy all but how to unify the pipeline and packaging and where to start, let us discuss some details to solve these very vital issues of future infrastructure. Most of these tools like HELM are available in community to accelerate development and find and fix bugs. Users of these tools also share deployment playbooks, manifests, recipes, etc  distributing via repos like GitHub and build platforms like Jenkins , mostly community and partners hardened this knowledge and also share it on secure and trusted repos and libraries like Ansible Galaxy  to which reader can refer to following to get more details https://galaxy.ansible.com/

Source: RedHat

All of this require a novel approach to manage the containerized infrastructure , HELM® which is a seed project with in CNCF® is a packaging solution that can address most of the challenges defined above . Just like Kubernetes it also supprots operators through which vendors and ISG can publish their software artefacts and packages to onboard it . This is also a way through which 5G CNF will be onboarded through NFVO (NFV Orchestrator) to the Infrastructure. This is exciting way to manage applications through easy to play charts , template files and easy to manage and control dependencies .

So let us try to understand some key concepts on Helm charts and Helm Operators.

Source: RedHat

Helm Charts:

A Helm chart is a single repository or artefact that contain all objects like deployment , services , policy , routes ,PV’s etc into a single .tgz (ZIP) file that can be instantiated on the fly . Helm also supprots aggregation concept which means you can either deploy each micro service or a collection of them altogether through one deployment process . The later is important specially in Telecom CNF’s . A good collection of helm charts are available at https://github.com/helm/charts which we can customize and also integrate with CI pipeline like Jenkins to do all operations on the fly .

When it comes to telecom and 5G CNF’s it is important to understand following terms before understanding contents of the package

Source: K8S and ETSI NFV Community

Source: Kodecloud and Project experience

Chart: A collection of resources which are packaged as one and will be used to run an application, too or service etc

Repo: A collection like an RPM used to manage and distribute resources as packages. Satellite can be used to integrate both VIM and CIM Repos in a 5G world

Release: A helm supprots to run a Canary release in a Telco environment, each time a chart is instantiated obviously including incremental changes each time will be considered a Release

Helm latest version is 3.0 release in ONS North Americas In Nov 2019 and includes a major change like removal of Tiller (Major security bottleneck) which was major impediment to use helm on more secure clusters.

Just like VNFD and NSD which follows ETSI ® SOL1 and SOL4 which defines VNF packages and its structure using TOSCA in Kubernetes we follow helm chart standard which YAML descriptors and structure that can be instantiates using helm create chart name , further it can be enriched and customized as per need , the mandatory manifests are values.yaml contains details like IP’s ,networks , template.yaml consumes the values ,chart.yaml the master file to manage charts , NOTES.txt  a comment files and Test.yaml to conduct chart testing once deployed . requirements.yaml is a file that list the dependencies

Happy and ready to apply your own helm charts , then try this out https://hub.helm.sh/charts?q=ericsson .  Although helm charts provide an easy way to manage applications however not all the changes are acceptable directly specially for the case of stateful CNF’s which are very relevant to the Telecom use case. In this case we need to use the Helm operator which first version 1.0 is GA now and let us discuss its key points below. Similarly Kubernetes operator need to be installed first via CRD’s , Helm charts behave in the same manner with a difference it is installed using Software developer provided charts .

 Helm Operators:

A helm chart and its packaging can be compared to Functions of Kubernetes operator which makes it easy to deploy and manage application across its life cycle using CRD and customer defined definition .

The helm operator is doing the next step of what Kubernetes is by enabling complete GitOps  for helm .It focused on defining a custom resource for the helm release itself thereby making it simple to manage complete artefacts as it is being deployed and managed .

As of April 2020 following are major features already added in Helm1.0 Operator

• Declaratively installs, upgrades, and deletes Helm releases
• Pull charts from anychart source;
• Public or private Helm repositories over HTTP/S
• Public or private Git repositories over HTTPS or SSH
• Any other public or private chart source using one of the availableHelm downloader plugins
• Allows Helm values to be specified;
• In-line in the HelmRelease resource
• In (external) sources, e.g. ConfigMap and Secret resources, or a (local) URL
• Automated purging on release install failures
• Automated (optional) rollback on upgrade failures
• Automated image upgradesusing Flux
• Automated (configurable) chart dependency updates for Helm charts from Git sources on install or upgrade
• Detection and recovery from Helm storage mutations (e.g. a manual Helm release that was made but conflicts with the declared configuration for the release)
• Parallel and scalable processing of different Helm Release resources using workers

Source: http://www.weave.works

Helm Operator can also work with other Kubernetes operators and address any dependency constraints infact all those can be expressed as part of the Chart itself. This is certainly needed in CNF’s and Telco use cases where there are lot of dependencies between API versions and cluster components for all rolling updates and each of this will require testing and validation. Traditional Helm obviously can not address it and it is almost impossible for user to address all such changes in an ever changing and complex world of network meshes, Helm operator ensures these requirements are fulfilled with in the GitOps frameworks.

Helm basic commands:

Below is a good jump start to some of basic helm commands .

• helm repo add

command to add a helm chart from a repo

• helm create chart-name

command to add a helm chart , a directory with basic files

• helm install –dry-run —debug ./mychart

Run dry run to install and show debug instructuctions

• helm package ./mychart

Will prepare the .tgz package and a user can install the application from this package.

• helm get all UPF -n CNF

Will retrieve the details of application deployed via helm in a give NS

• helm –help

Want to know all just try it out

Conclusion:

Although I have explained the Helm and Kubernetes in a way that one can believe that Helm chart is the replacement of Operator which is not the case. Infact the Helm is mainly aimed to deploy and manage Day1 tasks while still along the LCM of application you rely on CRD’s and Operators with one caveat why I do not like is that each time a new CRD we have to install and manage them. It will definitely change over time as Helm operator will target to resolve for most of day2 issues and that’s why I will encourage to get involved in Kubernetes SIG community.

Finally, as we will standardize the Dev Pipeline for Telco’s as well which is still too much invisible to us it will enable us to build hybrid cloud environment that will certainly solve so many fundamental architecture and business challenges. As an example, in the COVID-19 scnerio so many of the business face challenge to expand their networks to cater for increased load. If Telco’s already have figured out this pipeline it would have been both economical and responsible to share load between Onprem and Public cloud to address the hour need. This is why the journey to Hybrid cloud and software package standardization and delivery is too vital for both growth and sustainability of the Telco industry and national growth.

References:

ETSI NFV IFA29

@Oreily Kubernetes book sponsored by RedHat

https://medium.com/

https://www.weave.works/blog/introducing-helm-operator-1-0

https://www.digitalocean.com/

The comments in this paper do not reflect any views of my employer and sole analysis based on my individual participation in industry, partners and business at large. I hope sharing of this information with the larger community is the only way to share, improve and grow. Author can be reached at snasrullah@swedtel.com

 

Advertisement