在Linux基金会主办的“LFN技术会议”上，Tungsten Fabric社区进行了一系列演讲，介绍最新的功能和未来发展方向。今天带来第三篇演讲，通过TF Operator实现Tungsten Fabric各方面的部署和生命周期管理。
嗨，大家好！我是Prabhjot Singh Sethi，做架构师已经第八个年头了，今天的主题围绕使用TF Operator进行统一的生命周期管理，同时将演示集成Airship的应用案例。
（附注：Airship是一组用于自动化云配置和管理的开源工具，它提供了一个声明性框架，用于定义和管理开放式基础架构工具和底层硬件的生命周期。）
我们从Tungsten Fabric的发布开始，正如很多人已经知道的，Tungsten Fabric目前是作为一个容器镜像进行打包和发布的，所以基本上在部署它们时，最终会定义为基于docker compose的服务或者Kubernetes的原生对象，来真正推出Tungsten Fabric的各种组件。
当我们这样做的时候，各种模块的生命周期管理要求就变成了首要问题，任何部署系统都必须满足这些依赖关系。例如某些模块被期望按照预定的顺序部署，然后有一些有状态要素的基础设施组件，比如zookeeper，在部署config模块之前这些组件被期望达到某个状态，而这将取决于zookeeper。
此外，在升级和其它的方面，我们需要确保执行升级时各模块间关系的匹配，某些时候升级到各个版本需要执行不同的方案，而不是遵循类似的方案。
最后同样重要的是，作为一个网络提供商，我们还需要处理集群规模问题——当你有新的节点要进入系统，或者当你的Tungsten Fabric需要增加水平扩展的配置节点或控制器节点的时候。
在进入Tungsten Fabric Operator之前，我简单地介绍一下Operators和围绕它的框架。
回到最初的概念，Operator实际上就是K8s控制器，它的框架就是围绕K8s API提供Operator SDK的开发工具包，这有助于我们建立一个K8s控制器，然后封装其它组件，如Operator生命周期管理器——与Operator互动，并管理系统中所有Operator的生命周期。然后，通过Operator Metering实现使用报告和周围的东西。
所以，基本上作为K8s控制器，Operator是有目的地建立与其需要执行的知识间的关系，这就是它的工作，通常比任何通用的工具更好、更智能。同样地，它还可以把自动的操作逻辑打包为Operator的一部分，进而允许复杂的自动化任务。
TF Operator也一样，无非是一个K8s控制器，它的构建目的是解决Tungsten Fabric的生命周期管理需求，所以它本质上是一个TF的生命周期管理器。如果你看一下这些不同的组件在Operator框架中是如何定位的，就会发现Operator本质上是一个生命周期管理器，围绕它有一个封装的OLM，触发Operator实际进行安装和升级。
围绕Tungsten Fabric生命周期管理的所有需求，目前包括OpenShift、Ansible、Operator Framework、Helm Charts，甚至Juju创建的各种资源库。由于多种安装方案的出现，以及各种集成的解决方案，基本上要把Tungsten Fabric的生命周期管理原生地做进这个方案。
当你想用Ansible来做的时候，Tungsten Fabric所有的需求期待成为解决方案的一部分。当你想用OpenShift来做的时候，也是作为其中一部分方案来做的，而我们最后会把它们都复制过来。这本质上增加了任何一项工程的维护周期，额外的维护周期又涉及到更多的成本。
所以我们一开始的目标很简单，就是看如何简化生命周期管理，尽量提高软件的可管理性，以及降低这些成本。而我们需要回答的进一步的问题，就是有没有一种方法来统一应对Tungsten Fabric的LCM处理？如何简化可以允许TF集成到各种部署方案中，而不用担心如何处理每一个独立部署组件之间的版本依赖性问题？当然，集群的扩展也是另一个要考虑的因素。
这时候TF Operator就起到了一个重要的作用，让我们实现了生命周期管理器的统一。本质上TF Operator可以成为一个基于部署（based deployments）的生命周期管理器。当我们谈论TF Operator时，我们谈论的是K8s的原生控制器，其它组件部分都不在TF Operator的范围内，只与OLM有关。而我们在实现的时候，它所允许的是让我们能够重新使用TF Operator作为部署的一部分，也作为Helm deployment，以及Juju Charms的一部分。本质上是通过引入TF Operator来运行以及触发来做各种部署。
通过这样的方式，基本上解决了各种K8s部署与TF集成的问题，比如Airship、OpenShift、K8s、kubeadm、Canonical等，甚至是OpenStack Helm部署。
接下来，我们看下Airship集成的案例，这种整合是如何真正工作的，也将分享一个代码的链接，这是公开的，任何人都可以访问。
首先从需求开始。无论何时，你想使用任何软件以实现首要的需求，我们要有一个Airship Armada Chart，这只不过是一个Helm Chart的wrapper，加入Airship站点定义。然后，Tungsten Fabric被包装为Helm Chart的形式，实际上可以部署SDN控制器、CNI，甚至是OpenStack Neutron。
这种方案真正成功的原因，是你可以使用Helm Chart做一个常规的或基于概念验证的安装。目前，Helm Chart还没有足够的能力提供Tungsten Fabric所需要的生命周期管理的所有方面，这就是TF Operator能发挥更大作用的地方。
如果你期待使用TF Operator作为其中的一部分，还要包括Operator本身的Helm Hook，所以Helm Chart不会部署TF本身，而是部署TF Operator，传统意义上它只提供站点定义作为其中的一部分。它将触发基于对象的K8s，本质上是以TF控制器的形式运行，这是由Operator本身管理的。为了完成这个动作循环，我们要确保等待TF控制器运行完成，并触发回Airship Armada Chart。当知道控制器已经运行，现在各种其它组件可以继续部署。把网络提供商看成一个基础设施组件，我们要确保这个触发的工作，否则组件运行会失败，这是非常重要的。
我们有上述方案的参考实现方案，下面两个代码的链接都是可以公开访问的。
https://github.com/atsgen/tf-Operator-helm-hook
https://github.com/atsgen/treasuremap
一旦我们有社区版TF Operator，我们将迁移这些方案，以使用社区版的TF Operator。以上是我们期待这个统一方案的问题解决方式。关于如何看待这个统一管理的成功，或者它真的可以走多远，欢迎任何人做出讨论、评论，我们要确保能够使用软件的LCM解决几乎所有的问题。
视频链接：https://v.qq.com/x/page/x3218minifn.html
文档：https://tungstenfabric.org.cn/assets/uploads/files/unified-life-cycle-management-using-tf-operator.pdf
