Telco Cloud Automation GitOps

This feature enables you to deploy CNFs and DIPs in the GitOps model. In the GitOps model, instead of uploading CSARs using the TCA manager UI, you need to store the CNF artifacts in a git repository which should be accessible to TCA. After storing the the CNF artifacts in the git repository and configuring GitOps in TCA, the CNF artifacts are automatically realized by TCA to the target workload clusters.

Introduction

GitOps is defined as a mechanism for delivering and maintaining the infrastructure of Kubernetes platforms. Besides this infrastructure focus, some other definitions augment it with deploying business applications on the platform. This section describes the principles and practices of GitOps, an automated process that aims to deliver infrastructures and microservice-based applications quickly and efficiently.

GitOps follows the Infrastructure-as-Code (IaC) principle. It uses a Git repository to store the definition of the required infrastructure or application configuration. GitOps allows for automated, trackable, and repeatable management of infrastructure as well as applications. If an application needs to be redeployed to a new Kubernetes platform, for reasons of disaster recovery or for high availability, it can be easily done using GitOps. Additionally, the GitOps model helps organizations to progress applications through various testing phases all the way to production. This process requires the deployment of applications to different clusters, or different namespaces within a cluster, and the GitOps model ensures that this can be done efficiently and reliably.

There is a clear distinction between the two domains of infrastructure and applications, even though both can be deployed using the GitOps model. Infrastructure configuration takes care of the definition and delivery of the Kubernetes platform, in terms of the compute nodes, kernel and network devices of the underlying host, and many other attributes that create a platform on which applications can run. Applications can be segmented into the source code components that are compiled to an executable within a container image and the Kubernetes resources that configure the container images within a specific environment.

Following are the declarative model and guiding principles of GitOps:

A single source of the truth shall be maintained in the Git repository.
Any changes committed to the Git repository are automatically applied.
Any manual changes to the target environment are automatically reverted.

In simple terms GitOps is the process of defining the single source of the truth for infrastructure and application configuration in a Git repository, which are then automatically deployed to a target Kubernetes environment. If teams wish to make changes to the configuration of an application, then they simply modify the files in the appropriate Git repository and sit back for the automation process to update the application. Extensions to this process can involve the use of external ticketing systems and pull requests in the Git repository to ensure that only approved and appropriate changes are propagated to production environments.

Source Code Management

There are many source code management systems available. Any source code management system that provides a Git type interface can be used, such as Github and Gitlab. The interaction of the source code management system with the GitOps model is based on the following criteria:

The ability of the automated deployment solution to monitor the source code management system to identify new commits. This will allow actions to be triggered in a pull mode in which an external entity takes a decision to perform an action after observing a change in the Git content. There is no payload content included within the pull model directly and the external system must request any information that it needs.

GitOps in VMware Telco Cloud Automation

This section describes about GitOps interactions with TCA and components managed by TCA and requirements that have to be fulfilled by the solution.

The following figure shows the different components and user interactions for GitOps way of CNF deployment and node customization. As a first step, a Tenant Network Admin configures a pipeline providing the Git repository details and the target Workload Cluster to TCA. Once configured, TCA ensures that components inside TCA, responsible for node customization and CNF LCM are setup to consume intents as files from the Git repositories. Once the pipelines are setup, any intent files committed to the Git repository are picked up by the components and realized on the Workload Cluster.

This feature allows you to deploy CNFs as well as apply node customizations in the GitOps model. In this new model, instead of uploading CSARs through TCA manager UI, you can store their CNF artifacts in a git repository which is accessible to TCA. Then these CNF artifacts are automatically realized by TCA to the target workload clusters.

GitOps CNF Artifacts

There are two types of CNF artifacts:

Dynamic Infrastructure Policy (DIP) Intent
CNF Intent

DIP Intent

A DIP intent is a file that allows you to express node customization requirements. Following is an example of DIP intent:

name: sample-dip
kind: dip
version: 1
nodePools:  
 - np1
config:  
   nodeConfiguration:    
      kernel:      
         kernelType:        
             name: linux-rt        
             version: 6.1.62-2.ph5    
      network:      
        devices:        
          - deviceType: vmxnet3          
            networkName: DPortGroup          
            resourceName: nw1          
            interfaceName: nw1               
            count: 1          
            isSharedAcrossNuma: false          
            derivedFromCsar: false    
      iommuEnabled: false

The following is the description of the each field:

name: The name of the DIP that uniquely identifies a DIP

kind: keyword "dip" allows TCA to identify this as DIP intent

version: The version of this DIP intent. You can make changes to this intent file and increment the version accordingly.

nodePools: An array of nodepools that the DIP intent is applied to.

Note:

The VMware Telco Cloud Automation version 3.2 does not support multi nodepools. Therefore, this array can only have one element.

Config: The infrastructure requirements for node customization. For more information, see Customizing Network Function Infrastructure Requirements. The supported node customizations in GitOps models are described in Supported 3.2 Node Customizations.

CNF Intent

A CNF intent is a file that allows you to define what CNF needs to be deployed. The following is an example of CNF intent:

name: sample-cnf
kind: cnf
provider: Mavenir
productName: DU
version: "3.1"
releaseDate: 2024-01-12T23:20:50.52Z
manifests:  
   - name: demo-chart    
     sourceRepo: GitOps-poc    
     sourceRepoRevision: test    
     path: demo    
     valuesRepo: GitOps-test    
     valuesRepoRevision: HEAD    
     valuesFiles:      
        - demo/values.yaml
namespace: du-ns
dip:  
   name: sample-dip  
   version: 1

The following is the explaination of each field:

name: The name of the CNF that uniquely identifies a CNF

kind: keyword "cnf" allows TCA to identify this as DIP intent

provider: CNF provider

productName: CNF product name

version: CNF version

releaseDate: CNF release date

manifests: An array of Kubernetes manifest sources. Each item in the array specifies the Kubernetes manifests to be deployed. The manifests can be helm charts, kustomize files or plain Kubernetes yaml files.

Note:
TCA does not support dependencies between helm charts. All helm charts will be deployed simultaneously.
- name: Name of this manifest
- sourceRepo: This is the name of the partner system that points to the git repo hosting the manifests.
- sourceRepoRevision (optional, default to "HEAD"): The git revision to track for this manifest. The values can be:
  - HEAD: Special keyword that tracks the latest commit in master branch
  - Branch name: Tracking the latest commit of the branch
  - Tag name: Tracking a specific git tag
  - Commit SHA: Tracking a specific git commit
- path: The folder path of the manifest inside the source repository
- valuesRepo (optional): For helm charts, values.yaml files can come from a different repository to overwrite the default values.yaml file. This valuesRepo field specifies the repository that the values.yaml files are stored.
- valuesRepoRevision (optional): The git revision to track for the values.yaml file. Same convention as sourceRepoRevision.
- valuesFiles (optional): An array of values.yaml file paths in the values repository.
namespace: The namespace in the workload cluster to deploy this CNF. The CNF deployment is restricted in certain namespaces. The restricted namespaces are:
- kube-node-lease
- kube-public
- kube-system
- tanzu-package-repo-global
- tanzu-system
- tca-system
- tkg-system
- tkg-system-public
- vmware-system-csi
- vmware-system-antrea

dip (optional): If a CNF intent is dependent on a DIP intent, this field specifies the dependent DIP intent
- name: The name of the dependent DIP intent
- version: The version of the dependent DIP intent

Note:

One CNF can only have one namespace specified for all the manifests in the CNF.

Besides storing helm charts in git repositories, storing them in harbor is also supported. Following is an example of CNF intent which points the manifest to harbor repository:

name: sample-cnf-harbor
kind: cnf
provider: Mavenir
productName: DU
version: "3.1"
releaseDate: 2024-01-12T23:20:50.52Z
manifests:  
- name: demo-chart    
  sourceRepo: harbor1-3    
  chartVersion: 0.1.0    
  path: demo    
  valuesRepo: GitOps-test    
  valuesRepoRevision: HEAD    
  valuesFiles:      
      - demo/values.yaml
namespace: harbor
dip:  
   name: sample-dip  
   version: 1

Most of the fields are the same except for the following three:

chartVersion: The version of the helm chart
path: The path to the helm chart in the harbor repository
sourceRepo: This is the name of the Harbor partner system which stores the manifests.