学习
实践
活动
专区
工具
TVP
写文章
专栏首页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


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

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

登录 后参与评论
0 条评论

相关文章

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

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

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

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

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

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

    CNCF
  • Kubeflow 部署采坑记录

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

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

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

    罗西的思考
  • 转载|PaddleFluid和TensorFlow基本使用概念对比

    介绍:Paddle Fluid 是用来让用户像 PyTorch 和 Tensorflow Eager Execution 一样执行程序。在这些系统中,不再有模型...

    用户1386409
  • 几种常见设计模式在项目中的应用<Singleton、Factory、Strategy>

      前几天阅读一框架文档,里面有一段这样的描述 “从对象工厂中………” ,促使写下本文。尽管一些模式简单和简单,但是常用、有用。

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

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

    我是阳明
  • 使用 GPU-Operator 与 KubeSphere 简化深度学习训练与监控 GPU

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

    CNCF
  • 云原生赋能智能网联汽车消息处理基础框架构建

    近年来,汽车产业向「电气化、智能化、网联化、共享化」快速演进,「软件定义汽车」模式和 SOA 理念在汽车研发和设计领域逐渐深入。无论是作为智能网联汽车云端底座的...

    EMQ映云科技
  • vivo大规模 Kubernetes 集群自动化运维实践

    随着vivo业务迁移到K8s的增长,我们需要将K8s部署到多个数据中心。如何高效、可靠的在数据中心管理多个大规模的K8s集群是我们面临的关键挑战。kuberne...

    2020labs小助手
  • Kubernetes Operator 测试面面观

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

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

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

    CNCF
  • CNCF Volcano 核心架构和场景分析

    随着业务业务场景不断丰富,批量计算也由传统的HPC逐渐扩展到大数据、AI等多种场景,但各个领域独立发展,呈现出生态割裂、技术栈不兼容,资源利用率低等问题,严重影...

    用户5252199
  • 云原生应用管理:原理与实践

    yeedomliu
  • 云原生技术赋能联邦学习

    (本文作者系 VMware 中国研发云原生实验室架构师,联邦学习 KubeFATE / FATE 开源项目维护者和贡献者。)

    Henry Zhang
  • kube-on-kube-operator 开发(一)

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

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

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

    田飞雨

扫码关注腾讯云开发者

领取腾讯云代金券