Tungsten Fabric Operator

Spread the love

Tungsten Fabric CNI installation on a Kubernetes cluster currently has two available deployment models: Ansible deployer and Kubernetes Manifest Files. There are various challenges and issues faced by these two models that need to be addressed to get a full potential deployment. To solve the existing Tungsten Fabric CNI deployment issues, we at ATS developed a new solution using Tungsten Fabric Operators. In this blog post, we walk you through the challenges faced by previous deployment models and what’s more exciting in our new deployment model using Tungsten Fabric operators.

Motivation: Challenges Faced by Existing Deployment Models

Ansible deployer is a standard option to deploy Tungsten Fabric and Kubernetes cluster together. Ansible deployer provides a default Tungsten Fabric CNI deployment on any Kubernetes cluster. While deploying Tungsten Fabric CNI in Kubernetes node using ansible deployer, the following issues are usually faced:

  • Time taken for deployment is too long (around 30-40 minutes for a single node ansible deployment)
  • Addition of a new node is not straight forward
  • vRouter kernel init image dependency on Host Operating System
  • Less Availability

The alternative deployment model using Kubernetes manifests files can address only time issue, but other challenges persist.

Our Solution: TF Operator based Deployment

To address the problems with these two deployment models, ATS has developed TF operators. The TF operator reacts to the presence of a CRD (Custom Resource Definition) object with relevant configuration to roll out the corresponding CNI deployment.

How Tungsten Fabric Operator Works

To Simplify the deployment configuration scheme, the TF operators automatically assume Kubernetes master as a controller node for Tungsten Fabric and compute role for all the worker nodes. Whenever the operator discovers a new node joining the cluster, it automatically pushes the relevant Tungsten Fabric components on the new node based on the role assumed. This simplifies the addition of a new node to the cluster as a simple “Kubernetes node join”.

TF operator makes use of a single built-init container image for building and inserting the vRouter kernel module, ensuring decoupling of TF operator from the Host Operating System dependencies/configuration. In addition, it assumes that the relevant kernel header packages are pre-installed on the host.

TF operator is also capable of deploying a high availability setup where multiple master nodes are associated with the Tungsten Fabric Controller role.

Advantages of Tungsten Fabric Operators

  • Time taken for deployment is greatly reduced. For example, a single node TF operator-based deployment took just 8-10 minutes in contrast to the single node ansible deployment that takes around 30-40 minutes.
  • High availability
  • Ease of adding a new node to the system
  • The seamless rollout, without worrying about the Host Operating System
  • Life cycle Management of Tungsten Fabric and easy upgrade process

Future Work

We are looking forward to include support for multi-cloud deployment.

Technical Insights

To know more about Tungsten Fabric Ansible deployed for Kubernetes CNI, visit https://github.com/tungstenfabric/tf-ansible-deployer

To know more about Kubernetes Manifests, visit https://github.com/tungstenfabric/tf-container-builder/tree/master/kubernetes/manifests

To know more about Tungsten Fabric operators, visit https://github.com/atsgen/tf-operator-deployer

To watch our video on Tungsten Fabric CNI roll out with Operators, visit https://www.youtube.com/watch?v=WWW9hiOkOwY

Leave a Reply

Your email address will not be published. Required fields are marked *