专栏首页Tungsten Fabric中文社区通过TF Operator进行统一生命周期管理
原创

通过TF Operator进行统一生命周期管理

在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


原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 云原生生态系统赋能新的开源深度学习框架MindSpore

    MindSpore是来自华为的一个新的开源深度学习训练/推理框架,可用于移动、边缘和云场景。

    CNCF
  • [源码解析] 深度学习分布式训练框架 horovod (18) --- kubeflow tf-operator

    Horovod 是一款基于 AllReduce 的分布式训练框架。凭借其对 TensorFlow、PyTorch 等主流深度学习框架的支持,以及通信优化等特点,...

    罗西的思考
  • 使用 GPU-Operator 与 KubeSphere 简化深度学习训练与监控 GPU

    本文将从 GPU-Operator 概念介绍、安装部署、深度训练测试应用部署,以及在 KubeSphere 使用自定义监控面板对接 GPU 监控,从原理到实践,...

    CNCF
  • 揭秘|一探腾讯基于Kubeflow建立的多租户训练平台背后的技术架构

    作者薛磊,腾讯高级软件工程师,服务于腾讯星辰算力平台,是Kubeflow的maintainer以及Volcano、 Kubernetes等其他开源项目的贡献者,...

    腾讯云原生
  • Kubernetes Operator 测试面面观

    软件测试是一门工程技术,更是一门艺术。维护良好、质量过硬的测试用例不仅能大幅提高开发者的工作幸福感,也是企业对外提供优质软件服务的重要基础。在这篇文章中,才云工...

    CNCF
  • 云原生 AI 前沿:Kubeflow Training Operator 统一云上 AI 训练

    张望,腾讯高级工程师,从事云上 GPU 和分布式训练加速,负责腾讯云 TKE 在 AI 场景的研发和支持工作。 单嘉鑫,字节跳动软件工程师,从事基础架构及开...

    腾讯云原生
  • Kubeflow 部署采坑记录

    Kubeflow 是在 K8S 集群上跑机器学习任务的工具集,提供了 Tensorflow, Pytorch 等等机器/深度学习的计算框架,同时构建容器工作流 ...

    runzhliu
  • 云原生应用实现规范 - 初识 Operator

    基于 Kubernetes 平台,我们可以轻松的搭建一些简单的无状态应用,比如对于一些常见的 web apps 或是移动端后台程序,开发者甚至不用十分了解 Ku...

    我是阳明
  • tf-operator 的测试

    近期组内掌管的资源利用效率不够高,我们正在想办法在混部集群(游戏+离线任务),多跑一些离线任务。平台之前提供过一些大规模机器学习的模块给算法同学使用,效果不错,...

    runzhliu
  • Kubernetes CustomResourceDefinitions 和 API server aggregation(1)

    在 Kubernetes 里,Resource 也叫资源,实际上是 Kubernetes API 里的一个 Endpoint 类型,比如内置的 Pod,也是一种...

    runzhliu
  • DL框架的未来发展,TensorFlow/MXNet/Torch, 选哪个?

    DL framework的学习成本还是不小的,以后未来的发展来看,你建议选哪个? 请主要对比分析下4个方面吧: 1. 实现新计算单元(layer)和网络结构的便...

    计算机视觉研究院
  • TiDB Operator 源码阅读 (二) Operator 模式

    在上一篇文章中我们讨论了 TiDB Operator 的应用场景,了解了 TiDB Operator 可以在 Kubernetes 集群中管理 TiDB 的生命...

    PingCAP
  • 从零开始Kubernetes Operator

    Operator 是 Kubernetes 的重要扩展机制,本文从 Operator 概念开始,解释并实践了 Operator 的创建,希望可以帮助大家进一步了...

    CNCF
  • 分布式系统在 Kubernetes 上的进化

    本文译自 The Evolution of Distributed Systems on Kubernetes[1]。作者 Bilgin Ibryam,译者张晓...

    CNCF
  • 使用OperatorHub.io自动化群集上的操作

    为了帮助应对这一挑战,今天Red Hat与AWS、Google Cloud和Microsoft合作推出OperatorHub.io。OperatorHub.io...

    CNCF
  • kube-on-kube-operator 开发(一)

    kubernetes 已经成为容器时代的分布式操作系统内核,目前也是所有公有云提供商的标配,在国内,阿里云、腾讯云、华为云这样的公有云大厂商都支持一键部署 ku...

    田飞雨
  • kube-on-kube-operator 开发(一)

    kubernetes 已经成为容器时代的分布式操作系统内核,目前也是所有公有云提供商的标配,在国内,阿里云、腾讯云、华为云这样的公有云大厂商都支持一键部署 ku...

    田飞雨
  • TiDB Operator 源码阅读 (三) 编排组件控制循环

    上篇文章中,我们介绍了 TiDB Operator 的 Controller Manager 的设计和实现,了解了各个 Controller 如何接受和处理变更...

    PingCAP
  • 云原生AI平台的加速与实践

    前言:12月19日,在 Cloud Native Days China -云原生AI大数据专场,腾讯技术事业群高级工程师薛磊发表了《云原生AI平台的加速与实践》...

    CNCF

扫码关注云+社区

领取腾讯云代金券