Unified Life Cycle Management using Tungsten Fabric Operator

Spread the love

Tungsten Fabric being packaged and distributed as container images supports deployments based on Kubernetes native objects and Docker compose based services where Tungsten Fabric includes a large deployment landscape supporting a variety of integrations from different vendors with common requirements around Life Cycle Management (LCM).

These integrated deployments expect to handle LCM for Tungsten Fabric native to their scheme of deployments which add the complexity of managing multiple infrastructures around Tungsten Fabric providing the same deliverables/goals.

However, Tungsten Fabric operator (TF operator) based on operator SDK provides a path to manage LCM of Tungsten Fabric natively in Kubernetes, allowing TF Operator to form a common base for Tungsten Fabric’s LCM and is embeddable as-is into various deployment schemes.

Existing Life Cycle Management Requirements for Tungsten Fabric

  • Tungsten Fabric Modules must be deployed in order
  • Stateful infrastructure components must reach the required state before the roll-out of dependent components
  • Upgrades greatly influence the inter-dependency between modules/components
  • Version dependencies must be handled
  • Network provider handling Cluster scaling events

Why Tungsten Fabric Operator?

Tungsten Fabric operator, based on operator SDK, is essentially a Kubernetes controller purpose-built with logic to address Life Cycle Management (LCM) requirements of Tungsten Fabric.

In Kubernetes based Tungsten Fabric deployments, natively built TF operator acts as unified Life Cycle Manager for Tungsten Fabric.

With the increased adoption of operator framework, Operator Lifecycle Manager (OLM) for Kubernetes can probably be considered as a default Lifecycle Management option.

Irrespectively, TF Operator still seamlessly integrates as a bundled Life Cycle Manager into various deployment infrastructures such as Ansible, Helm, and Juju Charms along with OLM addressing use-cases around CNI providers for various open-source and commercial distribution of Kubernetes and neutron provider for OpenStack Helm.

TF-Operator addresses the following tungsten fabric integrated deployments:

Key Features

  • Unified LCM handling for Tungsten Fabric
  • Simplified Tungsten Fabric integrations into multiple deployments
  • Seamless version dependency between various components
  • Cluster scaling

Use Case: Airship with TF operator

Airship is a collection of loosely coupled but interoperable open source tools that declaratively automate cloud provisioning. Starting from raw bare metal infrastructure, Airship manages the full lifecycle of data centre infrastructure to deliver a production-grade Kubernetes cluster with Helm deployed artifacts, including OpenStack-Helm.

In Airship based model, Armada Charts based on helm charts are the standard tool to onboard any software. However, helm charts being a generic tool is significantly limited while catering to Lifecycle Management requirements of Tungsten Fabric while TF Operator serves as the perfect alternative.

As Airship does not have in-built support for OLM to onboard TF Operator on to Airship, we will make use of a Helm hook for TF Operator allowing it to plug into Airship as an Armada Chart.

Reference implementation using airship in a bottle is available here which uses a sample helm-hook.

On being included as a part of site definition, Armada rolls-out a helm chart triggering TF Operator deployment. TF Operator further deploys HA capable Tungsten Fabric Controller with configured functionality. To further emulate a complete helm type deployment, Helm hook waits for the Tungsten Fabric rollout to be complete before notifying Armada.

Advantages

  • Improved manageability of Tungsten Fabric deployments across different solutions
  • Reduced cost
  • Easy maintenance cycle

Leave a Reply

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