GitLab和Rainbond整合实现一体化开发环境

GitLab擅长源代码管理，Rainbond擅长应用自动化管理，整合Gitlab和Rainbond就能各取所长，本文详细讲述如何整合Gitlab和Rainbond，并通过整合实现一体化开发环境。

一.通过Rainbond一键安装 Gitlab

Rainbond作为应用运行环境，Gitlab可以运行在Rainbond之上，为了便于Gitlab安装，我们制作了Gitlab安装包放到了Rainbond的应用市场，实现Gitlab的一键安装。

1. 安装Rainbond，安装步骤。

2. 从应用市场搜索“Gitlab”，点击安装，一键完成Gitlab所有安装和配置工作，包括数据安装和初始化。
   
   

3. 安装完成，通过Rainbond管理和运维Gitlab。
   
   

二.Rainbond源码构建对接Gitlab Oauth，实现一键代码部署

使用过Rainbond的小伙伴一定知道，在Rainbond上创建组件有三种方式：源代码创建、镜像创建、应用市场创建。

源码构建方式通过配置源码地址实现代码构建，Gitlab虽然可以提供源码地址，但构建新应用需要拷贝源码地址及设置用户名密码，这个过程很麻烦，也容易犯错。

为了与 GitLab 配合有更好的体验，Rainbond做了产品化的支持，通过OAuth2.0协议与GitLab进行对接。

1.配置GitLab Applications

进入 User Settings → Applications

选项名	填写内容	说明
Name	Rainbond	填写自定义的 Application 名称
Redirect URI	https://IP:7070/console/oauth/redirect	回跳路径，用于接收第三方平台返回的凭证
Scopes	api、read_user、read_repository	GitLab的权限设置，需要开启 api、read_user、read_repository

创建后请保存 Application ID 和 Secret，后面会用到。

使用私有化部署 Rainbond 时，需配置 GItLab 允许向本地网络发送 Webhook 请求

进入 Admin area → settings → NetWork → Outbound requests

勾选 Allow requests to the local network from hooks and services 选项即可

2.配置Rainbond OAuth

进入 Rainbond 首页企业视图 → 设置 → Oauth 第三方服务集成 → 开启并查看配置 → 添加

选项名	填写内容	说明
OAuth类型	gitlab	认证的 Oauth 类型
OAuth名称	自定义（GitLab-Demo）	填写自定义的 Oauth 服务名称
服务地址	http://xx.gitlab.com	GitLab 服务访问地址
客户端ID	上一步获取的Application ID	GitLab 生成的 Application ID
客户端密钥	上一步获取的Application Secret	GitLab 生成的 Application Secret
平台访问域名	使用默认填写内容	用于OAuth认证完回跳时的访问地址

3.Rainbond OAuth认证

进入 Rainbond 首页企业视图 → 个人中心 → OAuth 账户绑定 → 对应账号 → 去认证

4.对接后效果

接下来展示Rainbond与Gitlab对接后平台的效果图。

当我们对接成功后，进入基于源码构建的页面会展示下图中的效果，展示所有的仓库列表。

通过Rainbond OAuth2与GitLab进行对接后，在Rainbond平台登录不同的账号时，需进入个人中心认证，认证后Rainbond会根据账号不同的权限展示不同的代码仓库。

三.Rainbond对接Gitlab WebHook，自动触发构建

当我们完成整合Rainbond 和 Gitlab Oauth ，选择指定仓库，点击创建组件，可选择代码版本（自动获取代码分支以及tag）和 开启自动构建。

创建完成后在组件中配置WebHook自动构建，提交代码，Commit信息包含“@deploy”关键字，就可以触发WebHook自动构建。

Commit信息关键字触发GitLab WebHook原生是不支持的，在这之前有社区用户提出在提交代码触发构建时，每一次提交都会触发构建，用户并不想这样做，所以Rainbond研发团队研发了根据提交的Commit信息包含关键字去触发自动构建。

下图中展示了用户从创建组件到持续开发的整个流程。

四.总结

一体化开发环境的能力：

• 代码管理：代码相关的所有管理功能，提供web界面的管理（Gitlab）

• wiki ：在线编辑文档，提供版本管理功能（Gitlab）

• 问题管理：Issue管理（Gitlab）

• 持续集成：代码自动编译和构建（Rainbond）

• 环境管理：快速搭建开发或测试环境，保证开发、测试、生产环境一致性（Rainbond）

• 架构编排：无侵入的Service Mesh架构编排（Rainbond）

• 模块复用：通过组件库 实现公司内部模块、应用、服务积累和复用，同时实现了软件资产管理（Rainbond）

• 持续交付：开发、测试、生产环境持续交付流程（Rainbond）

• 应用管理：应用监控和运维面板（Rainbond）

• 团队管理： 多团队管理，成员、角色管理（Rainbond）

一体化开发环境的价值：

1. 开箱即用

2. 让开发团队专注在写业务代码，不要在环境上浪费时间

3. 应用粒度抽象，使用简单，上手快

4. 过程自动化，提高操作效率（持续集成、环境管理、持续交付等）

五.感谢以下开源项目

Rainbond：开源云原生应用管理平台 https://www.rainbond.com/

Gitlab：知名代码仓库 https://about.git‍lab.cn/

我们需要的不是精通Kubernetes的工程师，我们需要一款小白都能用好的管理工具。

—— 厦门正观易知科技有限公司运维负责人 郭传壕

大家好，我是厦门正观易知科技有限公司运维负责人郭传壕。

藏书馆是一个专注用户自我成长的云端私人图书馆，集电子书的读、荐、借、购、存和知识管理功能于一体，致力于用户的认知赋能，通过读书习惯的养成，达成自我成长。目前累计注册用户已达 1500W ，平台图书资源超过200W册。

我们使用Rainbond已经有2年，我把我们的使用经验分享给大家。

 

1.以前的困局

处于云原生时代中的藏书馆的起点很高，我们一开始就选定了微服务架构、Kubernetes、容器化等符合时代潮流的技术体系。然而原生的kubernetes 管理平台提供的功能并不完全符合我们的预期，二次开发的巨大技术成本也是我们负担不起的。

在了解到 Rainbond 之前，处于创业初期的我们一直受困于产品迭代变更频繁所带来的琐事之中。我所说的琐事包含微服务架构下50个服务的版本管理、构建产物的更替、线上环境的发布以及围绕着应用从开发到上线再到运维的种种繁琐工作。

我们希望可以从这些琐事中跳脱出来，专注于业务本身，探索出一条适合kubernetes环境下持续开发、持续交付的简捷之路。

鉴于此，我们开始积极的寻找一款开源且易用的应用管理平台。

 

2.初识 Rainbond

在 Rainbond 之前，我们已经尝试过了 Rancher 等产品，但产品功能和我们的预期有很大差距。

2 年前，我们通过 Github 第一次了解到了 Rainbond 这款产品，惊喜于功能非常契合藏书馆的需求。列举几个令人印象深刻的能力：

• 应用架构的整体拓扑图

以上帝视角，一览无余的观测到所有服务组件的运行状态与依赖关系。强迫症会逼着我们的工程师消灭红色的异常状态，而体现运行状态的绿色真的令人感到安心。

• 可视化的资源占用情况

资源占用情况是体现可观测性很重要的指标。对于初创公司而言，了解资源分配是否合理，杜绝资源浪费是很重要的。Rainbond 从团队到服务组件的每个维度都提供了良好的可观测性。团队级别的资源限额能力非常实用，解决了运维团队无法有效掌控资源分配的难题。

• 自动伸缩

藏书馆是一个典型的 2C 场景，如何利用好云计算提供的弹性，灵活的应对流量高峰呢？答案就是使用自动伸缩功能。Rainbond 提供的自动伸缩功能，突出了简单易配置的特点。自动伸缩能力极大的解放了运维团队的工作压力，从此远离兴师动众和严阵以待。关键业务会随着我们的心意，自动扩张，直到能够吞吐所有流量。

• 集中式的网关策略管理

2C 场景下的服务发布，是无论如何也绕不过去的坎儿。无论是蓝绿发布、灰度发布抑或是A/B测试，这服务发布相关的十八般武艺多少都会碰到。原生的 Kubernetes Ingress 的确可以实现这些发布策略，但是我们更希望得到一个产品化的集中式管理页面来处理这些问题，而不是去麻烦运维工程师们去碰那些格式严苛的Yaml文件。Rainbond 网关策略管理完美的实现了我们的需求。

• 应用复制快速生成环境

在藏书馆的开发流程中，我们时常需要搭建各种环境，来区分开发、测试、预发布场景，分别对应不同版本的微服务组件，比如Dev、Prod之类的。但如果每次生成环境都要手动创建服务组件，那真的太低效了。应用复制功能在这个场景下非常有用，它帮助我快速复制出一套环境出来。复制过程中自助选择构建源的版本，对我而言是镜像的 Tag。复制后的新环境，保留了所有的服务组件元信息以及依赖关系。

在逐步的探索过程中，和官方团队在社区中进行的互动，让我们少走了很多弯路。一款开源产品如果伴随着有生命力的社区，将会是非常令人安心的。

 

3.开发测试环境部署

第一步，部署微服务

上手 Rainbond ，是从部署单个微服务开始的，这个过程非常简单，不需要学习Kubernetes的 Yaml 。开发环境中的组件是基于镜像构建完成的，只需要按界面的引导填写好镜像地址及相关信息就可以了。

我们用的是 Spring Cloud 微服务框架，在 Rainbond 体系下可以很好的运行，我在部署过程中受到了一系列文档的影响，这里分享给大家:

• Spring Cloud 微服务部署在 Rainbond 的优势

• Spring Cloud 微服务与 Service Mesh 的融合

• Spring Cloud 微服务部署在 Rainbond 的案例

第二步，通过可视化的方式服务编排

在编排微服务的过程中，基于图形化编辑组件依赖关系这个功能，着实惊艳了我。这种编排方式和其他平台基于复杂 Yaml 文件进行编排的方式有极大的不同。感兴趣的小伙伴们可以阅读下服务编排相关的描述，这的确是一种小白都可以掌控的微服务编排方式。

第三步，对接外部的服务

对于我们这样一个初创公司而言，将数据库等服务托管给云服务商，直接使用 RDS 服务是个既经济又稳健的选择。在 Rainbond 体系中，我通过添加第三方组件的方式将位于云端的 RDS 服务纳入管理之中。这种纳入让第三方服务也像部署在平台之中一样，可以被其他微服务组件所依赖。

至此，我的开发环境就已经部署完成了。

第四步，复制出了测试环境、预发布环境和生产环境

在以往的开发过程中，搭建环境是一个很繁琐的事情。对一个处于快速迭代过程中的产品而言，我们至少需要开发环境、测试环境、生产环境，在我们自己的实际场景中，还引入了预发布环境。对于代码而言，我仅需要 Fork 出多个分支，来区分不同环境即可。通过定义流水线，我们也已经完成了不同代码分支打包镜像的不同 tag。但是到了搭建环境这一步，难道就只能根据不同的镜像 tag ，手动一点点的创建组件？想到藏书馆业务的近 50 个微服务组件，和彼此间的依赖关系，我的头就很大，IT 从业者最不能忍受的就是重复工作。

在探索 Rainbond 使用方法的过程中，快速复制这个功能一下子抓住了我的眼球。快速复制功能可以检出所有组件的构建源信息，对于源码构建的组件，构建源就是它的代码仓库地址、编程语言、代码分支；而对于镜像构建的组件，构建源则对应了镜像地址和 tag。在这样一个界面下，我可以选择需要被复制的组件，修改其 tag 版本。这样的复制能力可以实现环境在不同集群、不同团队下的复制。新的环境继承了原环境中除镜像 tag 以外的所有设定：依赖关系、组件名称、环境变量配置、持久化设置等等。

利用这个能力，我基于开发环境，像Fork一份代码一样，通过修改 tag 的方式复制出了测试环境、预发布环境和生产环境。

这一能力极大的节约了我们使用 Rainbond 时，部署各种环境的时间成本。目前，我们也把这一功能用于新人的开发环境搭建，以前手把手教新人如何搭建自己的开发环境是很费心费力的事情。

 

4.串通持续交付流程

早前，我们已经借助 Jenkins ，自定义了一套完整的流水线，来实现所有微服务组件的构建。最终的构建产物会被定制为镜像推送到镜像仓库中去。我们对这一部分的工作是比较满意的，我们希望 Rainbond 能够在镜像仓库之后集成进来，完成微服务组件的持续构建与部署。

Rainbond 在这一部分是非常开放的，提供了接口来实现与第三方 CI 工具的对接。我们只需要在 Jenkins 的流水线完成镜像推送后，添加一个步骤简单的调用下 Rainbond 提供的接口，对应的微服务组件就会自动拉取最新的镜像，完成上线操作。到目前为止，整个技术团队都已经适应了这种使用方式。

实际上这是一个很通用的接口调用方式，无论对接哪一种第三方CI工具，都可以很方便的调用。

每一个运行在 Rainbond 上的微服务组件，在构建源处都可以打开自动构建的设置。自动构建设置有两种实现：

• 基于 Git-Webhook ，针对基于源代码构建的微服务组件，可以借助代码仓库的 Webhook 能力，实现代码一推送，就触发该服务组件自动构建并上线的效果。支持的代码仓库类型比较广泛，GItlab、Github、Gitee、Gitea等代码仓库都支持。

• 基于镜像仓库 Webhook ，针对基于镜像构建的微服务组件，可以借助镜像仓库的 Webhook 能力，实现镜像一推送，就触发该服务组件自动构建并上线的效果。Harbor、Dockerhub等镜像仓库都支持 Webhook 功能。

• 自定义API，这是最通用的接口调用方式，用户只需要基于 Http 协议调用，即可触发该服务组件的自动构建并上线。

触发上图中的自动构建 API，最简单的方式是在命令行中执行一条命令：

curl -d '{"secret_key":"6GvowlHX"}' -H "Content-type: application/json" -X POST https://<Rainbond控制台地址>/console/custom/deploy/c4e7b60bd800986df940d8103f22d271

目前，我们已经可以做到以很简单的方式，精确触发到指定的流水线，完成对应微服务组件的更新上线。

5.其他通过Rainbond解决的问题

随着对 Rainbond 这款产品认识的不断加深，我们开始不断抛却一些琐事，一些传统部署模式下难以规避的问题，借助 Rainbond 的能力都得以很好的解决：

• 内部依赖配置无法查询

传统部署模式下，所有组件之间的相关依赖，都是写在配置文件中的一系列配置。对产品整体没有足够了解的工程师很难掌握所有依赖项的引用地址，写错 IP 导致调用不通的失误时有发生。借助应用拓扑图的展现，现在每一个新手工程师，在看到拓扑图之后，都会立刻对产品的整体结构产生直观认识。

• 多实例部署异常后排查不便

传统部署模式下，每个微服务组件如果需要多实例部署，都需要工程师们手动操作服务器上传jar包进行配置。如果遇到升级调整，偶尔还会错漏。一旦出现问题需要排查，如何定位正确的实例就已经很麻烦了。Rainbond 环境下，每个微服务组件的多实例版本一致性不需要关心，而出问题排查时，实时日志推送和Web控制台都帮了大忙。

• 服务器资源不能共享

传统部署模式下，我们通过划分虚拟机来避免计算资源的浪费，然而这还不够。我们希望计算资源能够完全池化，面向每个微服务组件来划分。这一点所有基于 Kubernetes 实现的应用管理平台都可以实现。而 Rainbond 的伸缩设置，是我见过产品化做的最好，最易用的。Rainbond 平台上线后缩减了三分之二的服务器资源。

• 相同监听端口不能同台部署

端口其实也是一种重要的资源，同个操作系统下，端口的占用是不可以冲突的。这个问题在大规模微服务组件部署时显得尤为突出。Rainbond 这一点做的很好，每个微服务不会直接占用服务器端口，我们的开发人员可以更自由的定义组件监听了。

• 开发人员权限管理

真实的业务场景下，软件系统本身的问题并非都由运维人员处理，更多的情况下需要开发者本人排查和处理。而权限管理则要求开发人员尽可能不具备登录生产服务器的权限。这就导致了一个两难的问题，快速解决问题还是严格管控权限？这是开发人员和运维人员容易产生冲突的点。引入 Rainbond 之后，这个问题得到了很好的解决，开发人员的所有操作都是在 Rainbond 管理界面进行的，即使需要通过命令行排查问题，也可以通过 Web 控制台登录容器环境，而不是宿主机服务器。目前，我们已经形成了应用开发人员基于 Rainbond 运维自己开发微服务组件的模式。

• 应用版本回滚

传统模式下，微服务组件的部署有多复杂，那么回滚到上一个版本就只会更复杂。Rainbond 这款产品非常贴心的提供了服务组件级别的一键回滚，管理人员可以在版本列表之中随意选择需要的版本，进行一键回滚，这真的太方便了。

6.写在最后

和使用其他产品一样，深入使用 Rainbond 也是需要一些磨合过程的。令我印象深刻的一个情况，是 Rainbond 使用的 Glusterfs 分布式文件系统，在经过很长一段时间的使用之后，存储容量被用尽，导致了一系列问题。我们的运维人员缺少对 Glusterfs 的了解，对 Rainbond 如何与 Glusterfs 相互作用更是一知半解。无奈之下求助官方，出乎意料的是官方的工程师非常热心的支持我们解决了问题，并贴心的留下了操作文档。

我对 Rainbond 最大的感触是其易用性做的很好。希望 Rainbond 团队可以将这一点贯彻到底，提供更多能够解决实际问题的实用特性。我们了解到Rainbond的Service Mesh下一步可以支持istio，下一阶段我们打算尝试一下。

10月23日，全球边缘计算大会·上海站在上海市长宁区天山西路舜元会议中心顺利召开。谐云作为此次大会合作伙伴，受邀并出席大会，边缘计算负责人魏欢于23日下午在会上发表“边缘计算大规模落地实践”的主题演讲。

全球边缘计算大会GECC是由边缘计算社区主办的边缘计算领域顶级盛会，至今已在北京、深圳等多地成功举办。此次上海站设置了1个主会场，3个分会场，邀请到政、产、学、研、用各界专家者布道分享，共同促进边缘计算领域知识传播与生态建设。

“边缘赋能”典型场景下，为满足更广连接、更低时延、更好控制等需求，云计算正在向一种更加全局化的分布式组合模式进阶，分布式云成为发展新模式。

开源基因，持续深耕，边缘计算的布道者

在边缘计算领域深耕五年，谐云积极参与分布式云、云边协同、边缘智能和边缘安全的生态共建，是云边协同产业方阵首批共建单位成员，参与信通院云边协同多个技术标准制定。深度参与边缘计算开源工作，贡献多个核心功能，在KubeEdge、OpenYurt项目源码均有极大贡献。此外，副总裁才振功还是云边协同产业方阵指导委员会委员。

谐云边缘计算解决方案，通过EdgeStack智能边缘计算平台保障稳定性，EdgeBox边缘一体机确保边缘安全，并准许物联网设备接入实现丰富的场景应用开发。

谐云EdgeStack®智能边缘计算平台的“云+边缘+端”的云边端协同架构，将容器云计算能力下沉至边缘节点，可支撑百万级边缘节点和设备接入，专为大规模、多接入、低带宽、低时延、高性能、高稳定等边缘计算场景倾力打造。谐云自主研发的EdgeBox边缘一体机，将云端的能力下沉到边缘侧，解决边缘实时性、可靠性、运维经济性等方面遇到的问题。可助力用户实现“降本增效保安全” 的建设、管理目标，使用户真正感受到“云边协同”所带来的全新价值。

多行业、丰富场景大规模落地验证

目前，谐云边缘计算解决方案已实践于分布式云、物联网、车云协同、边缘智能金融等多场景，为边缘计算领域树立了实践标杆和经典案例。在一些典型行业如通信、交通、金融、军工等多个行业领域中得到大规模的落地验证。

通信领域，谐云为行业巨头某在线服务公司业务场景定制开发、打造了云边协同平台，助力其轻松应对流量洪峰；交通领域，联合上汽集团商用车技术中心打造了“基于容器的下一代车云协同架构”，是汽车行业的首款“云、边、端”一体化架构，可实现百万级车联网大规模接入；为某跨海大桥打造了一体化协同的产品，积累了丰富的“边-端”设备协议对接经验，交付了行业顶尖的“软硬一体化”的整体解决方案。

此外，通过赋予边缘节点AI能力，为某银行搭建云边协同平台轻松纳管边缘节点与设备，降低时延，实现成本缩减与效率的飞升。其中，某在线服务公司和上汽集团案例还分别荣获《2020年分布式云与云边协同十佳实践案例》奖项和《2021年分布式云与云边协同十佳实践案例》奖项。

作为国内为数不多掌握底层核心技术的云原生解决方案提供商，谐云始终坚持以云原生技术为核心，同时从云向边缘基础设施延伸，扩大云的范围，建立云原生产品生态、整体解决方案和产业应用相结合的完整生态体系。

未来，谐云将继续潜心深耕云边协同，探索云边协同技术与更多行业的融合落地，推动云边协同生态发展和产业落地。

2021杭州云栖大会于10月19日～22日在杭州云栖小镇举办。谐云作为阿里云的核心合作伙伴，受邀并亮相21日的云原生峰会，谐云CEO王翱宇在现场进行了“深耕云原生技术：Kubernetes应用渐入佳境”的主题演讲，分享云原生领域前沿的创新与经验，探索数字化科技的新趋势，为数字化建设增添云力量。

云原生，进入后Kubernetes时代

云原生是面向云应用设计的一种思想理念，是云计算领域炙手可热的主流技术，极大地释放了云计算红利，成为发挥云效能的最佳实践路径。随着全行业上云的逐步深化，云计算的发展应用已进入云原生阶段。

云原生技术往往具有极致的弹性能力，以容器技术为基础的云原生技术架构可实现秒级甚至毫秒级的弹性响应能力，具有服务自治和故障自愈能力。基于云原生技术栈构建的平台具有自动化的分发调度协调机制，可实现应用故障的自动摘除与重构，具备大规模可复制能力，可实现跨区域、跨平台甚至跨服务商的规模化复制部署。

云原生技术的全面落地实践

云原生是企业的下一代基础设施平台，也是企业数字化转型的必然选择和出路，企业数字化转型必然走向云原生。云原生一直处于不断变化和发展的状态，如今随着云原生技术逐渐走向成熟，并在多个行业落地，各行各业对云原生的接受程度越来越高，云原生的落地标准也发生了变化。从之前的以落地k8s作为云原生典型标志转变成了业务全面落地云原生平台作为标志。因此，用户的关注点也从之前的如何搭建一套稳定、可靠的k8s平台转移到了如何让业务快速、稳定的在云元生平台落地、并且长足发展。

从应用价值来看，云原生实现了异构资源标准化，加速了企业数字基础设施升级，提供了业务应用的迭代速度，使云资源和应用更“便宜”。

从产业融合来看，云原生为其他信息技术大规模应用提供了重要支撑，能够为区块链、人工智能、大数据、边缘计算等新兴技术提供部署环境和基础支撑能力，对于建设融合、共赢的产业生态具有促进作用。

谐云✕阿里云打造OAM技术体系

谐云率先实现了基于OAM（开放应用模型）的可视化编排，给阿里云全球云原生生态事业填上了完美的一笔，成为全球首款基于OAM的应用可视化编排平台。

谐云联合阿里推出的OAM（开放应用模型），直接部署在物理机上，完全以应用为中心，让Kubernetes与底层资源打交道，对应用完全屏蔽掉底层资源的异构性，使得简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。

相信未来应用的构建会越来越简单，应用部署也将更贴近用户，基础设施的选择会根据用户的架构需求自动匹配。用户可以真正享受到云平台化的红利，快速复用已有的模块化能力，而OAM也将成为应用云原生化的必然选择。

随着业务需求和场景的增多，以及技术的不断发展，容器应用衍生出了边缘计算、安全、全链路监控等一系列云原生相关技术。谐云也针对技术的演进更新迭代出了边缘计算平台、云监控、云安全等一系列产品。凭借多年的云原生技术积累和客户需求场景实践，重点对以下几个领域进行了深度的技术耕耘和产品打磨：

1.面向分布式云的边缘计算平台：解决边端机器和设备的计算资源管理和调度问题。

2.基于EBPF的容器监控平台：解决云原生应用的全链路监控问题。

3.基于中间件的可视化运维管理平台：解决在应用云原生化之后的中间件的快速供给和自动化运维的问题。

谐云产品采用相同的底层技术架构，可根据客户业务特点、场景需求进行组合，提供高度契合的技术架构、网格布局、数据存储等方案，为企业提供多种场景下的一站式云原生解决方案。

谐云将持续秉承创新研发国产自主云原生操作系统的创业初心，深耕云原生底层技术，实现产品、服务、咨询、落地全覆盖，加速企业数字化转型，携手拥抱云原生。

随着越来越多的用户将业务向公有云上迁移，用户在为应用选择存储时，经常会陷入困境。企业每年数据量快速增长，开销越来越大；私有云中的数据和公有云中的数据、或者多个公有云之间的数据难以流动形成统一整体；同样的数据在面对不同的应用有着不同的性能、功能诉求，而公有云上的存储类型只能照顾一类应用，当另外的应用需要使用这组数据时，只能创建另外一套存储资源，需要面临数据拷贝的繁琐过程并管理这些数据集之间的同步问题。以上这些难点问题并不是一家公有云本身就能很好解决的，因为这涉及到线上/线下、存储产品的定义等问题。

焱融科技在服务大量线下用户的同时，一直关注公有云上的应用场景和技术创新，希望可以为公有云用户提供全新体验的第三方共享文件存储服务。于是，焱融科技于正式推出 SaaS 化的云舟共享数据服务。

01 云舟是什么

云舟是焱融科技构建在公有云基础架构上的 NAS 共享数据服务，支持多个主流的公有云。用户通过注册，就可以在云舟平台上，为不同公有云上运行的业务创建自己的共享文件存储空间。通过简单几步，就可以将这个存储空间共享至自己独立的租户和 VPC 内，应用程序可以使用 NFS 或 POSIX 私有协议客户端（即将推出）访问这些数据。云舟具有以下特点：

• 额外资源零消耗。有别于其它基于公有云的第三方 NAS 存储产品和方案，用户无需为云舟共享文件存储空间创建任何额外的云主机或存储资源，所有的存储资源实现真正的按需使用，数据在云舟平台上进行统一管理。
• 低成本，用户不再为账单发愁。焱融科技在云舟平台上，借助有效的数据生命周期管理技术，极大降低用户使用共享文件存储的成本，远低于公有云原生的共享文件存储。注册即可获得代金券，覆盖大多数中小企业和开发者一年的共享文件存储费用。
• 兼顾容量和性能。用户数据存储在云舟统一管理的空间上，当应用需要更高性能支撑时，只需将共享文件空间从容量型转为性能型即可，无需进行任何拷贝，文件存储类型无缝切换。

02 你会是云舟的用户吗

云舟的共享文件存储服务，为公有云广大用户提供了区别于公有云上原生的文件存储之外更灵活的选择。80% 的中小企业用户，共享文件容量在几 TB 到十多 TB，云舟可以无缝对接当前使用文件存储接口的业务应用，总体成本降低 30-40%，对于需要从精细运营中获取效益的中小企业来说，无疑是更好的选择。

公有云上还有大量的开发者用户，这些用户使用公有云来开发自己的应用程序，甚至是人工智能等需要使用到高性能文件存储的应用。对个人开发者来说，数据量通常来说并不大，但如果要在小容量情况下满足一些高性能应用的需要，无论是自己搭建 NFS 服务、还是使用公有云的共享文件存储，都难以得到理想的性能，甚至会拖慢 GPU 等计算资源，带来更大的成本开销。云舟可以为用户提供小容量、高性能的服务，对开发者来说，可以灵活调整所需的性能。只要你在公有云上需要共享文件存储，云舟就可以成为你的选择。

03 面向的市场和云舟的未来

在公有云上，块存储是云主机和其它很多应用场景的最重要基石。自从 AWS 推出 S3 对象存储之后，各家公有云也都将对象存储纳入必须具备的服务清单中，现在也很难看到没有对象存储的公有云。与之形成对比的是，在文件存储领域，各家公有云处于不同的阶段，所提供的共享文件存储的能力和服务也有较大差异。这是由于文件存储需求量大，但不同应用对文件存储的读写特点不同，公有云厂商众口难调，只能提供通用类型的文件存储产品和服务，这就为第三方存储厂商提供了施展的舞台。事实上，文件存储也是公有云上第三方存储最活跃细分领域。在国外，有不少厂商都在云上为用户提供有特色的文件存储服务，其中就包括大名鼎鼎的 NetApp。

IDC 等研究机构在多份报告中指出，第三方厂商有大量机会在公有云资源之上提供企业级文件存储服务。据 IDC 统计，2019年起，用户在公有云文件存储的支出每年增长 153%，这个数据清楚地表明，越来越多的用户将企业级应用程序迁移和部署到公有云上，并使用基于文件的共享存储。焱融科技在面对快速增长的市场和用户需求上，将 YRCloudFile 成熟的平台和技术创造性地部署在公有云上，针对公有云的特点，经过软件架构调整和长时间测试，推出了云舟共享数据平台。云舟首先解决用户的文件共享需求，通过分层技术降低用户使用成本，让应用不需任何改造就能完成对接。在此基础上，云舟很快会推出高性能 POSIX 客户端访问，并结合更多应用场景为用户带来性能和使用上的优化体验，提供便捷的操作接口，让开发者深切感受到云舟带来的便利。云舟 SaaS 数据服务平台，可以作为用户搭建分布式文件系统和公有云原生文件系统的替代，适用于以下场景：

• 高性能计算/人工智能：POSIX 兼容，可以支持所有机器学习、深度学习框架；共享能力提升团队管理、使用数据效率。
• 共享文件存储：没有客户端并发读写限制，可以并发共享存储访问。
• 数据备份：平滑扩展的存储空间，满足数据备份需求。
• 容器持久化：容器集群将容器镜像的配置文件或初始加载数据存储在共享文件存储上，在容器批量加载时实时读取。多 POD 间通过存储共享持久化数据，在 POD 故障时可以进行故障切换。

云舟是一个快速迭代的数据平台，每一个用户都是焱融科技最珍视的资源。注册试用后，用户有任何意见和想法，都可以反馈到社区中，任何反馈对产品改进都是最大的的推动力。

焱融科技希望通过云舟产品能聚集成围绕云的更强大的数据生态，相信在云舟平台上会诞生最酷的创意和应用。

​1.关于柯基数据

南京柯基数据科技有限公司成立于2015年，提供一站式全生命周期知识图谱构建和运维、智能应用服务，致力于“链接海量数据，从大数据中挖掘智慧“。帮助企业运用知识图谱技术打造世界领先的认知工作自动化智能引擎。

目前在药企、医疗机构、军工院所、科技情报及出版等领域服务了数十家大客户，积累了丰富的行业知识图谱运用开发经验。典型客户有国防科技大学、中国航空、中国电科等。

2.柯基数据的云原生之路

大家好，我是南京柯基数据的解决方案架构师刘占峰，云原生技术在交付运维上的优势让我获益匪浅。作为项目合作伙伴，Rainbond持续助力柯基多套业务系统的快速开发和交付部署。在使用Rainbond之前，由于业务迭代周期短，涉及组件多，平台版本更新耗时耗力，服务运维难度大。很多项目中，客户的运维能力储备不足，基于传统的交付和管理方式，客户对于业务运维根本接管不起来，只要风吹草动，必须要我们派工程师到现场解决。针对交付运维存在的问题，各个业务平台开始着手云原生改造。

最开始我们尝试自己搭建公司内部的开发测试环境，过程中遇到的两个小坑。

第一个坑是：环境搭建完成后使用体验却不佳，所有涉及到磁盘读写的操作都显得异常卡顿，集群中的 Etcd 集群日志中不断报告处于 “read_only” 状态，随之而来的是服务器负载的不断飙升。

我们带着怀疑的心情求助了Rainbond开源社区，经过多方面的排查，我们把目光落在了磁盘的IO性能上。替换了高性能的磁盘之后，我们重新安装了整个开发测试环境，磁盘性能的提升的确解决了 Etcd 集群时常不工作的问题。

第二个坑是：使用了共享存储的服务却依然处于读写极慢的状态，这着实令在场的所有工程师又开始头大了。确认了硬件性能之后，开始将目光放在操作系统配置参数上面，操作系统内核在不断报告与共享存储有关的错误：

NFS:__nfs4_reclaim_open_state: Lock reclaim failed!指征 nfs client 和 nfs server 之间存在同步差异，差得多了就会开始报警。经过不断摸索，工程师们终于锁定了与 nfs 性能有关的两个系统参数，Linux nfs 客户端对于同时发起的NFS请求数量进行了控制，若该参数配置较小会导致 IO 性能较差。

echo “options sunrpc tcp_slot_table_entries=128” >> /etc/modprobe.d/sunrpc.conf

echo “options sunrpc tcp_max_slot_table_entries=128” >> /etc/modprobe.d/sunrpc.conf

修改了这两个参数后，共享存储的性能得到了显著的提升，令人摸不到头脑的内核报警信息也随之消失。开发测试环境终于可以顺畅使用了。

接下来面临新的挑战是如何将我们的多套业务系统顺利迁移到 Rainbond 上去，所幸Rainbond 的使用很简单，整体学习梯度并不陡峭，我们很轻松把业务系统分批的部署在 Rainbond 上去。然而 Rainbond 工程师组织的云原生应用评估却指出了业务系统有多处不符合云原生特征之处，提出了一些整改意见。在整改过程中，我们对云原生也有了更深入理解。

• Elasticsearch等有状态组件需要将组件部署类型调整成为有状态单实例或有状态多实例，不可以是无状态我们最开始并不了解什么是有\无状态组件，所以并没有注意区分组件的部署类型。Rainbond工程师提示我们，Elasticsearch在Rainbond平台中应该使用有状态的组件部署类型进行部署。
  

  L1级云原生应用特征——可伸缩性

  云原生应用注重部署组件所使用的资源类型，像数据库类型、消息队列类型的服务组件对在Rainbond平台上，应该使用StatefulSet资源类型进行部署。通过对服务组件定义有状态或者无状态的部署类型，来规定使用StatefulSet或Deployment资源类型来部署实例。

• 支持横向伸缩我们的多套业务系统，在接触云原生改造之前，都是传统的单体架构，部署时也基本不考虑高可用特性。这使我们的业务系统相对而言脆弱许多，没有任何容错能力，一旦服务器宕机，整个业务系统就失去了服务能力。云原生改造的过程中，我们借助于Rainbond天然的微服务能力，非常轻松的将我们的业务系统拆分成为更为合理的微服务架构。更令我们惊喜的是，这些拆分出来的微服务组件，大多数直接具备了横向伸缩的能力，借助Rainbond的一键伸缩能力，迅速扩展成为多实例的集群，极大的提高了系统的可用性。而针对某几个不可以一键伸缩的组件，Rainbond工程师们也提供了合理的意见，引导我们对这几个特殊的组件进行修改，使之实现了“无状态化”。现在，经过云原生改造的业务具备了“小强”一般顽强的生命力，再也不怕服务器宕机了。
  

  L1级云原生应用特征——可伸缩性

  通过程序数据分离等手段，实现应用程序的无状态化，就让云原生应用可以随意横向伸缩多个实例。实例数量的伸缩一方面使云原生应用具备了高可用性，也直接影响其抗并发的能力。Rainbond还提供自动伸缩功能，实现削峰填谷。

• 所有配置支持环境变量配置，形如 ${GATEWAY_PORT:8083}以往我们都将服务的配置项写成固定的值，这样的做法使得我们每到一个新的部署环境，都要重新更改大量的配置文件。Rainbond工程师指出，云原生应用应该将配置保存到环境当中，以环境变量加默认值的方式声明出来。而大多数需要修改的配置项，如不同组件之间的连接地址信息，就可以通过Rainbond依赖关系中的连接信息来相互注入，省去了大量的配置工作。
  

  L1级云原生应用特征——可配置性

  云原生应用推崇的一种最佳实践，就是将配置保存在环境之中。在不同的运行环境中，利用环境变量来进行配置，是一种非常好的体验。Rainbond支持为每个服务组件设置环境变量，也可以基于配置组功能，批量配置环境变量。

• 组件主要端口通过环境变量  ${PORT} 定义Rainbond工程师提供了一个小技巧，将组件监听端口的配置，用一个固定的环境变量来配置，这个变量的值会随着我们在Rainbond控制台上手动添加的端口号来自动变更，这样，我们就可以在不更改代码和配置的情况下，随意变更想要监听的端口号，这很方便。
  

  L1级云原生应用特征——可配置性

  作为对环境变量的补充，Rainbond提供了一系列可以自动生成的环境变量，这些特定的环境变量极大方便了用户的使用。

• 所有组件需要统一时区统一所有组件的时区配置是非常有必要的，Rainbond工程师提供了一个技巧，让时区的设置变成了一个很简单的事情。只需要运行环境的镜像中包含 tzdata 软件包，我们就可以基于 TZ=Asia/shanghai 这样一个环境变量的配置，完成时区的配置了。
  

  L1级云原生应用特征——基础可观测性

  统一时间在运维领域十分重要，在云原生领域，时区的配置也可以基于环境变量进行配置。

• 所有业务需要定义健康检查策略Rainbond工程师要求我们为所有的服务组件定义健康检查策略，这样可以在服务组件遭遇问题时，快速识别到运行异常状态，在根据事先的配置，完成下线或重启的操作。对于 http 服务，我们定义了一个检测接口，通过探针请求返回的状态码来判断服务的状态；对于一般中间件，则检测其TCP端口的监听状态来判断。
  

  L1级云原生应用特征——高容错性

  在提高容错性方面，云原生应用需要配置合理的健康检查策略。这有利于快速发现组件的异常状况，并根据事先配置好的策略进行自动化的重启、下线等操作。

• 组件应支持优雅失败与重试机制Rainbond工程师向我们阐述我们的服务组件在被关闭时，应该做出怎样的反应，来最大化的优化最终用户的体验。进程接收SIGTERM时，拒绝新请求，完成已接收请求后关闭端口，退出进程。而对于服务组件突然丢失了数据库连接这样的情况，也应该添加合理的重试机制，在多次重试依然无法重新连接到数据库时，理应结束进程，用显式的组件异常状态来提醒运维人员。
  

  L1级云原生应用特征——高容错性

  云原生应用强调容错性，这不仅仅包含在某些错误被触发时，应用本身和平台是否提供自动的处理手段，也包括在错误无法被处理时，提供更好的可观测性，来提醒运维人员介入。

• 前端web组件调用后端api组件地址需要进行nginx代理对于前后端分离的项目，合理的利用前端的web服务器进行接口层的转发是一种很好的体验。Rainbond工程师在帮助我们完成前端VUE项目的源码构建的同时，也教学了如何通过在代码根目录下添加配置文件，来实现接口请求向后端组件的转发。
  

  L2级云原生应用特征——前后端分离配置

  Rainbond提供了便捷的方式来配置VUE等前端项目运行的Nginx，配置后只需要将前后端组件依赖起来，就可以实现API的转发。而不需要每部署一次，都要根据后端服务的地址变更而重新编译。

• 实现一键交付使用Rainbond的目的之一，是希望能够借助其能力，实现业务系统的快速交付。通过与好雨科技交付团队的合作，我们只需要提供应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键交付整套业务系统。这极大的降低了我们的交付成本。
  

  L2级云原生应用特征——一键安装

  借助于 Rainbond 提供的应用发布能力，我们可以将运行在平台上的企业应用一键发布为一个应用模版。我们对应用模版最殷切的期待，是可以将这个应用模版以最简单的操作方式、尽可能少的人为调试即可安装成为一个应用。

• 实现一键升级为了适应最终用户的需求，我们需要不断迭代自己的产品，并在生产环境中持续升级我们的业务系统。Rainbond 基于应用模板的版本实现了一键升级的能力，这个功能对我们非常有用，我们只需要提供更高版本的应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键升级整套业务系统。
  

  L2级云原生应用特征——一键升级

  Rainbond 的应用商店机制支持基于应用模板的版本对已安装的应用进行升级操作。平台的升级机制解决了服务组件版本、配置、依赖关系等绝大部份属性的版本管理问题。尚需应用开发人员关注的问题在于数据的版本管理。

3.最终效果

应用完成改造后，通过Rainbond可以查看我们产品的拓扑图和依赖关系。

在实际项目当中，我们产品流转了三个环境：

开发环境：我们在公司内部，使用开源版本的Rainbond在公司服务器上搭建了开发测试环境，我们开发团队通过源码构建，很快将业务系统搬上了Rainbond。通过一段时间的测试和迭代，我们拿出了首个版本的应用模板，并使用离线导出功能导出了离线包。

准入测试环境：利用光盘等介质，仅需一个工程师将离线包导入了最终客户提供的私有云准入测试环境，导入后产品一键安装。对于客户反馈的意见，我们在开发环境中导出新的离线包，并再次导入了准入测试环境，进行了一键升级，经过多次迭代最终达到客户的准入要求。

生产环境：最终生产环境是完全由客户管理，我们仅需要提供经过准入的应用模板离线包以及必要的文档，客户就可以非常快速的将我们的产品完成部署和升级。

相对于以前的交付方式和流程，接入Rainbond体系给我们带来了这些更好的交付体验：

• 更便捷的交付方式：交付物只是离线包，不需要关心客户复杂的运行环境。
• 更低的交付成本：无论从时间还是人力的角度，交付成本都极大的降低了。
• 应用运维过程自动化：云原生技术切实的提升了业务系统的各项能力，可用性、容错性以及应对流量陡增时动态的伸缩能力。

最终仅用一个星期，我们就完成了各个业务系统的云原生改造工作，并测试通过云原生应用标准规范认证L2级。之前项目交付过程中交付难、维护难的问题，是我们最大的隐形成本，客户只会看最终交付效果，并不会为交付过程而买单。

做了云原生改造后，之前需要派驻交付团队1个星期才能交付完的项目，现在一个基础的运维工程师刻盘过去安装，1小时就可以搞定。并且用户可以通过Rainbond的可视化界面快速上手掌握，95%的运维问题都可以自行解决，或者远程指导客户操作。

4.什么是云原生应用标准规范认证？

「云原生应用标准规范认证」为软件厂商的应用交付过程中的便利性、交付客户后的可维护性、以及必要时的可迁移性等需求，提供可信赖的技术背书。现阶段，「云原生应用标准规范认证」分为L1、L2、L3级，在应用交付及交付管理发挥重要作用。

• L1关注：应用跨环境交付后的一键安装和自动化运维。如高可用、可伸缩性、可观测性等，提升最终客户的可维护性，降低客户的学习成本。
• L2在L1基础之上关注：应用跨环境交付后的一键升级。如全量/增量升级、版本回滚等，满足客户小步快跑的持续迭代交付需求。
• L3在L2基础之上点关注：应用跨环境交付后的一键备份迁移。如包含完整数据的打包备份、可迁移性等，帮助客户实现整体生产环境的迁移、灾备。

5.关于Rainbond

Rainbond作为开源的云原生应用管理平台，是「云原生应用标准规范」落地实施的最佳工具。

https://www.rainbond.com

https://github.com/goodrain/rainbond

 

kubevirt是Red Hat开源的以容器方式运行虚拟机的项目，是基于kubernetes运行，利用k8s CRD为增加资源类型VirtualMachineInstance（VMI），使用CRD的方式是由于kubevirt对虚拟机的管理不局限于pod管理接口。通过CRD机制，kubevirt可以自定义额外的操作，来调整常规容器中不可用的行为。kubevirt可以使用容器的image registry去创建虚拟机并提供VM生命周期管理。

Kubevirt的架构

 

kubevirt以CRD的形式将VM管理接口接入到kubernetes中，通过一个pod去使用libvirtd管理VM的方式，实现pod与VM的一一对应，做到如同容器一般去管理虚拟机，并且做到与容器一样的资源管理、调度规划、这一层整体与企业IAAS关系不大，也方便企业的接入，统一纳管。

virt-api：kubevirt是以CRD形式去管理VM Pod，virt-api就是所有虚拟化操作的入口，这里面包括常规的CDR更新验证、以及console、vm start、stop等操作。

virt-controller：virt-controller会根据vmi CRD，生成对应的virt-launcher Pod，并且维护CRD的状态。与kubernetes api-server通讯监控VMI资源的创建删除等状态。

virt-handler：virt-handler会以deamonset形式部署在每一个节点上，负责监控节点上的每个虚拟机实例状态变化，一旦检测到状态的变化，会进行响应并且确保相应的操作能够达到所需（理想）的状态。virt-handler还会保持集群级别VMI Spec与相应libvirt域之间的同步；报告libvirt域状态和集群Spec的变化；调用以节点为中心的插件以满足VMI Spec定义的网络和存储要求。

virt-launcher：每个virt-launcher pod对应着一个VMI，kubelet只负责virt-launcher pod运行状态，不会去关心VMI创建情况。virt-handler会根据CRD参数配置去通知virt-launcher去使用本地的libvirtd实例来启动VMI，随着Pod的生命周期结束，virt-lanuncher也会去通知VMI去执行终止操作；其次在每个virt-launcher pod中还对应着一个libvirtd，virt-launcher通过libvirtd去管理VM的生命周期，这样做到去中心化，不再是以前的虚拟机那套做法，一个libvirtd去管理多个VM。

virtctl：virtctl是kubevirt自带类似kubectl的命令行工具，它是越过virt-launcher pod这一层去直接管理VM虚拟机，可以控制VM的start、stop、restart。

Kubevirt如何管理虚拟机？

虚拟机镜像制作与管理

虚拟机镜像采用容器镜像形式存放在镜像仓库中。创建原理如上图所示，将Linux发行版本的镜像文件存放到基础镜像的/disk目录内，镜像格式支持qcow2、raw、img。通过Dockerfile文件将虚拟机镜像制作成容器镜像，然后分别推送到不同的registry镜像仓库中。客户在创建虚拟机时，根据配置的优先级策略拉取registry中的虚拟机容器镜像，如果其中一台registry故障，会另一台健康的registry拉取镜像。

虚拟机生命周期管理

KubeVirt虚拟机生命周期管理主要分为以下几种状态：

• 虚拟机创建：创建VM对象，并同步创建DataVolume/PVC，从Harbor镜像仓库中拉取系统模板镜像拷贝至目标调度主机，通过调度、IP分配后生成VMI以及管理VM的Launcher Pod从而启动供业务使用的VM。
• 虚拟机运行：运行状态下的VM 可以进行控制台管理、快照备份/恢复、热迁移、磁盘热挂载/热删除等操作，此外还可以进行重启、下电操作，提高VM安全的同时解决业务存储空间需求和主机异常Hung等问题。
• 虚拟机关机：关机状态下的VM可以进行快照备份/恢复、冷迁移、CPU/MEM规格变更、重命名以及磁盘挂载等操作，同时可通过重新启动进入运行状态，也可删除进行资源回收。
• 虚拟机删除：对虚机资源进行回收，但VM所属的磁盘数据仍将保留、具备恢复条件。

虚拟机创建流程

虚拟机创建分为创建DataVolume和VMI两个流程：

1. 创建DataVolume后，CDI组件创建对应的PVC并且关联到合适的PV，然后通过临时Importer Pod拉取虚拟机容器镜像绑定到DataVolume生成的PV中，并且将镜像转换成disk.img文件存储在PV中供虚拟机使用。
2. 创建VMI后，等待disk.img转换成功，然后在对应的Node上启动Launcher Pod，并将CDI流程生成的PV挂载到Pod内，当做虚拟机启动的系统盘。Launcher根据VMI的定义生成定义虚拟机的XML文件，然后调用libvirt进程调用Qemu命令创建并且启动虚拟机。VMI会对Launcher Pod状态进行同步，反应VM运行的状态。

Kubevirt如何实现容器与虚拟机交互TBD

容器和虚拟机互通

• Virtual-Kubelet对应的Node会上报节点上Pod的Endpoint，假定Kubernetes集群和IaaS层平台部署在同一个二层网络下，则集群内容器Pod可以访问VM-Pod，但容器Pod对于VM-Pod不可见；
• 针对上一点可以通过Macvlan等网络插件，将容器-Pod，降维至二层网络上，实现容器-Pod和虚拟机互通，有一定硬件要求。

如何实现⼀套集群下虚拟机与容器的混合调度与资源隔离

• Virtual-Kubelet提供的是一个虚拟节点用来向Kubernetes上报Node对象和Pod的状态和资源情况，虚拟机资源和集群内节点资源完全隔离；
• 在引入Virtual-Kubelet的情况下，需要对Virtual-Kubelet节点配置Taint和Tolerations，保证容器-Pod和VM-Pod调度分离。

服务发现

Virtual-Kubelet，通过Provider实现的API将IaaS层VM信息抽象成对应Pod对象的信息的方式来上报Endpoints，可以通过给CR添加no selector Service，待VM-Pod拉起后补充address至对应的Service

Kubevirt适用场景

由于Kubervirt提供的成熟的虚拟化能力和性能，并且可以直接通过Kubernetes进行统一管理。所以Kubevirt适合在有PaaS层管理平台和Kubernetes集群环境的情况下，通过kubevirt中的单一控制平面简化了对虚拟机的管理，让用户无需关心IaaS层，即可轻松在集群内构建、部署出一台虚拟机进行使用。

如何搭建Kubevirt

Kubevirt安装

1. 前置条件

查看硬件是否支持虚拟化

如果虚拟化不可用，则需要手动开启软件仿真

2. 安装Kubevirt组件

直接操作以下命令进行安装

3. 检查实例是否正常运行

4. 启动相关特性

修改kubevirt-config configmap内的数据

5. 安装virtctl

安装kubevirt命令行工具

6. 安装CDI

CDI(containerized-data-importer) 是kubernetes的持久存储管理插件，帮助kubevirt构建磁盘镜像，可以将不同来源的数据源（url、container image、upload….）来填充pvc的能力。

获取最新版，进行安装

安装完毕后，会在cdi namespace下，启动cdi相关组件

至此，kubevirt安装完毕

创建虚拟机

1. 准备一个虚拟机镜像

通过dockerfile构建出一个虚拟机镜像

2. 创建一台VM

编辑好yaml文件，通过kubectl命令拉起一台vm

Rainbond 是云原生且易用的应用管理平台。云原生应用交付的最佳实践。专注于以应用为中心的理念，赋能企业搭建云原生开发云、云原生交付云。

对于企业： Rainbond 是开箱即用的云原生平台，借助 Rainbond 可以快速完成企业研发和交付体系的云原生转型。

对于开发者： 基于 Rainbond 开发、测试和运维企业业务应用，开箱即用的获得全方位的云原生技术能力。包括但不仅限于持续集成、服务治理、架构支撑、多维度应用观测、流量管理。

对于项目交付： 基于 Rainbond 搭建产品版本化管理体系，搭建标准化客户交付环境，使传统的交付流程可以自动化、简单化和可管理。

Rainbond 5.3.3 版本来了，本次发布的版本我们主要以用户实际需求为导向进行优化，在过去的一些实践中，我们发现，对于复杂的业务组件，部分资源的配置需要个性化配置，这就对我们平台使用的灵活性提出了更高的要求。因此 5.3.3 版本我们主要以配置的灵活性为主要迭代方向。

在一些开发场景中，用户机器可能是高内存型或高 CPU 型，此时用户机器资源往往得不到充分利用，因此现在我们提供了组件 CPU 设置的能力，用户可以根据自己需求个性化配置资源。其次，对于一些配置文件，用户除了配置文件相关内容外，也有配置其权限的需求，现在这些需求都可以得到满足。

主要功能点解读：

1. 支持实时查看 Rainbond 自身组件的状态和初始化进度

在该版本以前，我们在初始化 Rainbond 集群时，整体对用户是不可见的，相当于一个黑盒，用户出现问题，很难及时定位。现在我们在初始化 Rainbond 集群时，给出了集群的 pod 信息，用户可以通过可视化界面，直接了解到初始化集群需要多少组件，目前已经完成的组件数。还可点击组件，查看组件的事件信息。使用户能更直观的了解整个过程和快速定位问题。效果如下图所示：

2. 支持组件配置文件的权限设置

在之前的版本中，为某个组件挂载配置文件时，默认的权限为 0777 ，但是有些配置文件有权限要求，比如my.cnf，0777 会被忽略，因此在 5.3.3 版本中，支持为挂载的配置文件设置一个权限，用于解决该类问题。

3. 支持组件的CPU设置

在之前，我们只支持了组件的内存设置，CPU 通过算法得出。但这样有以下几个问题：

• 部分业务由于CPU资源分配过少，运行缓慢。出现问题甚至难以排查。

• 在部分开发环境中，用户想自己手动指定相应的 CPU ，也难以操作。

因此我们现在支持了自己手动设置组件的 CPU 和内存，且 CPU 和内存资源都可设置为不限制，给用户提供更灵活的使用方式。

4. 第三方组件的重构

为了逐步适配 OAM 应用规范，提升 Rainbond 的可扩展性。在之前发布的 5.3.1 版本中我们基于 OAM规范，重新实现了第三方组件类型，定义了 ThirdComponent 作为第一个 ComponentDefinition，并在产品中实现对ComponentDefinition 的基础管理机制。此次我们基于 ComponentDefinition 定义重新实现了第三方组件的静态配置和 API 配置实例类型。现在第三方组件已支持添加多个端口，并支持对应端口进行绑定。下面我对此次第三方组件的功能点做个简要说明。

假如现在你的第三方组件只开启了 80 端口，此时该组件有以下两个实例 10.10.10.10:80 ，10.10.10.11:5000

• 支持单端口映射到不同端口的endpoints

  对于第三方组件，只开通一个端口，添加多个实例且多个实例端口不同时，那么可以通过开通的端口轮询访问到该组件下的所有实例。

  参考上述前提，那么此时你访问第三方组件的 80 端口，实际是会轮询访问这两个实例 10.10.10.10:80 ，10.10.10.11:5000

• 添加多个端口，多个端口的绑定关系

  此时为第三方组件新建端口 5000 ，那么对应的端口将会与实例进行绑定，此时访问第三方组件的 80 端口，将只会访问到实例 10.10.10.10:80 ，访问 5000 端口，也只会访问到实例 10.10.10.11:5000。

5. 应用模版的变更

在 5.3.3 版本中，我们更改了应用模版的元数据模型，支持了更多组件属性的发布。如组件的 CPU 设置、组件特性、组件网关策略、配置文件权限的发布与安装等。其次，基于元数据模型的变更，我们在导出 RAM 规范的应用时，也支持了应用 logo 和版本信息的导出，现在，你可以更好的导入应用并获得该应用的版本信息。

6. 支持组件的容器日志可以单独查看

在以往的版本中，一个组件下有多个容器时，多个容器的日志均输出到日志页面，难以区分。在 5.3.3 版本中，这不再是问题，5.3.3 版本中支持单独查看各容器的日志，你只需在组件日志页面选择你需要查看的容器，即可快速获取到你关心的信息。

详细变更点：

新增功能

• 【安装】支持查询Ranbond组件的状态信息和安装进度；

• 【应用管理】支持网关访问策略的发布与安装；

• 【组件管理】支持配置文件设置文件权限；

• 【组件管理】支持设置组件和插件的CPU；

• 【组件管理】支持查看组件内各容器的日志；

• 【组件库管理】支持导入导出应用模版的logo和版本信息；

• 【第三方组件】支持第三方组件添加多个端口；

• 【第三方组件】支持单端口映射到不同端口的endpoints；

优化功能

• 【性能】缓存企业级统计数据，提升首页展示速度；

• 【存储】自动清理备份恢复和导入时产生的缓存数据；

• 【稳定性】升级底层ingress版本；

• 【日志】优化allinone部署的控制台日志持续输出无法连接redis的问题；

• 【日志】优化导入大体积模版时rbd-chaos的日志提示；

BUG 修复

• 【安装】修复集群安装驱动服务崩溃的问题；

• 【安装】修复同名称集群,重新安装失败的问题；

• 【安装】修复初始化Rainbond集群操作未实现幂等的问题；

• 【网关】修复两条相同网关策略导致网关报错的问题；

• 【组件库管理】修复应用模版release状态展示错误的问题；

• 【资源统计】修复团队使用资源统计中磁盘使用量统计错误的问题；

• 【应用管理】修复应用治理模式切换错误提示的问题；

• 【应用管理】修复恢复时删除原应用下组件导致恢复失败的问题；

• 【应用管理】修复升级时未变更组件仍然进行了滚动更新的问题；

• 【应用管理】修复升级时只发布部分组件，导致升级后依赖丢失的问题；

• 【组件管理】修复组件配置文件名称校验错误的问题；

• 【组件管理】修复第三方组件实例数与初始化状态错误的问题；

 

云原生应用理念经过几年的落地实践已经得到企业市场的广泛认可，云原生应用更是成为企业数字化转型的必选项。基于云原生技术架构衍生的产品和工具，已经逐渐应用在开发者的日常工作当中。

近日，全球最具影响力的咨询机构Forrester联合阿里云发布《云原生开发者洞察白皮书》，JFrog中国首席架构师王青受邀参与该白皮书的编写。Forrester首次定义云原生时代开发者的能力模型，助力开发者拥抱云原生技术，实现开发者自身的转型。

早在2020 年IDC发布的报告中，曾提到在未来的 3-5 年，软件制品的数量会越来越多，到 2025 年，全球会出现520M 个应用，超过 60%的企业软件版本的部署频率为 1 天，甚至更短。软件发布的种类也越来越多，Go、Maven、Docker、NPM 等类型的制品会不断的从研发中心构建出来，并推送到云环境进行部署。同时，由于开发者不熟悉云资源的使用，且依赖大量的开源软件，导致开发的软件遇到了部署难、安全管控难、传输慢等常见问题。

这样就给开发者带来一个新的挑战：开发者如何将制品快速的分发到各个云原生环境进行快速、安全的发布？我认为开发者需要从以下几个方面做出改变。

一、软件供应链安全可控

在云原生环境下，你的服务极有可能是对互联网开发服务的，由于开发者使用的依赖包往往来自于互联网公有仓库，这就使得使用了开源软件的应用容易被黑客攻击。大家可以尝试在云环境中安装一个 Jenkins 直接对外提供服务，用不了几天就会被黑客攻击，并且在你不知情的情况下种下木马，去挖矿或者执行其他任务。

我们应该如何解决？

整个部署过程必须使用自动化工具来保障软件供应链的安全可控，应当通过自动化工具自动生成软件物料依赖清单 SBOM，并实时扫描依赖包的漏洞风险和 License 合规性。开发者应该使用实时的开源组件分析工具，进行实时的 SAST 静态应用安全扫描，在开发阶段把已知的安全漏洞扫描出来，并根据优先级进行修复。参考以下操作流程：

1.1 使用Sonarlint 进行静态代码扫描，实时修复漏洞

1.2 在IDE中安装JFrog插件，实现开源组件漏洞和License的合规性检查

通过对开源软件供应链的扫描，实现对依赖的管控。

在构建过程中，自动收集软件物料清单 SBOM 如下：

通过自动的依赖清单收集，能够清晰的定义软件版本的依赖信息，以及依赖组件的漏洞扫描信息和 License 合规性信息。

二、面向云资源的部署

开发者在云原生环境下，想要实现应用的部署，必须熟悉云资源的类型，从而将云资源的字段从应用配置中抽取出来，这样才能实现一次构建，处处运行。以 Kubernetes 应用开发为例，开发者之前在本地配置的数据库、存储、端口等配置都需要抽取出来，定义成 YAML 文件的变量，抽象成 Helm Chart，这样开发者在本地开发配置的程序内，不做任何修改，只通过修改应用的 Chart Values文件，即可实现云环境的适配。

三、 Docker镜像高效分发

当版本发布之后，需要具备快速、高效的将版本分发到多地数据中心、边缘节点、IOT 设备等能力，例如支持大文件分片分发，支持 Docker 镜像的 P2P 分发等能力。

Docker 镜像的P2P分发将成为大企业在云原生环境下的必备能力，通过 P2P 分发，能够极大的提升 Docker 镜像的下载速度，快速的将新功能部署在服务器上，更快的给用户带来价值。

---

云原生时代已经来临，在云原生的环境下，企业及开发者想要占据先机，快人一步，就必须实现流动式的软件版本发布，才能在发布频率越来越快的将来站稳脚跟，奋勇前进。

添加小助手微信：JFrogjiewachina，您将获得《云原生开发者洞察白皮书》

在了解virtual-Kubelet之前，我们先了解下什么是Kubelet。

Kubelet 是在每个Node节点上运行的主要 “节点代理”。在Kubernetes集群中每个节点都会启动一个kubelet进程，kubelet基于PodSpec来工作。每个Pod Spec是一个描述Pod的YAML或JSON对象。Kubelet接受通过各种机制（主要是通过Apiserver）提供的一组Pod Spec，并确保这些Pod Spec中描述的容器处于运行状态且运行状况良好。同时Kubelet还通过cAdvisor监控容器和节点资源，定期向上报当前节点的健康状态以及资源使用情况，可以把Kubelet理解成[Server-Agent]架构中的Agent。

Virtual-Kubelet是基于Kubelet的典型特性实现，向上伪装成Kubelet，从而模拟出Node对象，对接Kubernetes的原生资源对象；向下提供API，可对接其他资源管理平台提供的Provider。不同的平台通过实现Virtual-Kubelet定义的方法，允许节点由其对应的Provider提供(如ACI，AWS Fargate，IoT Edge，Tensile Kube等)支持，实现Serverless，或者将其扩展到如Docker Swarm、Openstack Zun等容器平台中，也可以通过Provider纳管其他Kubernetes集群，甚至是原生的IaaS层平台(VMware、zstack、openstack)。

最好的描述是Kubernetes API on top，programmable back。

Virtual-Kubelet如何管理虚拟机是本文讨论重点。

Virutal-Kubelet的架构

Virtual-Kubelet 模拟了Node资源对象，并负责对Pod调度到Virtual-Kubelet伪装的虚拟节点之后，对Pod进行生命周期管理。

当前支持原生Kubernetes特性：

• 创建，删除和更新Pod
• Container的日志，管理和监控
• 获取单个Pod或多个Pod状态
• 节点地址，节点容量，节点守护程序端点
• 管理操作系统
• 携带私有虚拟网络

Virtual-Kubelet如何管理虚拟机？

虚拟机生命周期管理

Virtual-Kubelet在虚拟机调度和操作方面可以复用Kubernetes原生的资源对象，但Pod在Kubelet管理下的生命周期仅存在创建、运行和销毁，实际对于虚拟机的开关机、备份和迁移等操作无法实现映射关系，因此对于复杂的生命周期管理，需要通过自定义CRD方式支持不同类型的IaaS平台，每一个VM-CR对应一个IaaS层VM实例。

对于VM-CR操作主要可以分为两类：

• 对VM运行状态变更
• 创建和销毁：可以对应一个VM-CR的create/delete
• VM启停操作对应VM-CR replicas数量的变更:开机0→1关机1→0
• VM规格变更：修改VM-CR Spec资源定义
• kubectl logs/exec VM-pod：实现对Pod的访问
• 对VM进行备份/迁移
• VM备份采用创建对应Backup-Job对象，通过与VM-CR实例pod亲和方式，将Backup-Job调度置VM实际节点所运行的Virtual-Kubelet节点上，备份状态与Job执行状态一致
• VM迁移采用Kubernetes原生的节点调度方式，IaaS平台每一个负载VM的物理机对应一个Kubernetes集群内的Virtual-Kubelet，VM-CR实例Pod的调度由Kubernetes控制面管理

虚拟机存储管理

由于Virtual-Kubelet中Pod仅作为逻辑概念，IaaS层存储无法与Kubernetes集群公用，但可抽象为Kubernetes原生定义的PV/PVC，PV的access mode能力依赖IaaS层能力，并需要实现对应平台和底层存储的Provider和Provisioner。

Virtual-Kubelet如何实现容器与虚拟机交互

容器和虚拟机互通

• Virtual-Kubelet对应的Node会上报节点上Pod的Endpoint，假定Kubernetes集群和IaaS层平台部署在同一个二层网络下，则集群内容器Pod可以访问VM-Pod，但容器Pod对于VM-Pod不可见；
• 针对上一点可以通过Macvlan等网络插件，将容器-Pod，降维至二层网络上，实现容器-Pod和虚拟机互通，有一定硬件要求。

如何实现一套集群下虚拟机与容器的混合调度与资源隔离

• Virtual-Kubelet提供的是一个虚拟节点用来向Kubernetes上报Node对象和Pod的状态和资源情况，虚拟机资源和集群内节点资源完全隔离；
• 在引入Virtual-Kubelet的情况下，需要对Virtual-Kubelet节点配置Taint和Tolerations，保证容器-Pod和VM-Pod调度分离。

服务发现

Virtual-Kubelet，通过Provider实现的API将IaaS层VM信息抽象成对应Pod对象的信息的方式来上报Endpoints，可以通过给CR添加no selector Service，待VM-Pod拉起后补充address至对应的Service。

Virutal-Kubelet适用场景

适用场景

Virtual-Kuberlet适合在已有IaaS层管理平台和Kubernetes集群环境下进行二者的打通，实现在Kubernetes集群上统一管理容器和非容器平台，同时由于Virtual-Kubelet在Serverless和纳管其他已有容器平台(Openstack Zun，Docker Swarm)方面也具有很高适配性，Virtual-Kubelet可以提供一套统一的API，方便开发者打通全流程。

Virtual-Kubelet的优缺点

优点

• 一个开源的Kubelet实现，使用Kubernetes源语，使构建、部署更简单
• 提供Kubelet典型特性接口，Provider仅需实现对应服务管理平台资源到Node和Pod对象特性的实现，不需要考虑如何访问Kubernetes
• 灵活性高，Severless实践、对接现有容器平台、对接现有IaaS平台均有一定前景
• Virtual-Kubelet设计将virtual-kubelet和Provider高度分离，Virtual-Kubelet使对于异构服务平台具有很高的兼容性(不同架构如：ARM、S390x，不同CRI如：Kata、PodMan)，不光是可以纳关IaaS平台对于其他Kubernetes集群也可以实现管理

缺点

• 将非集群内资源抽象成Node和Pod对象对资源使用上有一定局限性，很难提供超出原有kubelet和IaaS平台能力范畴，IaaS深度整合需要自行实现CRD
• 仅能作为转换器，用于容器和虚拟机统一管理时还是需要依托已有的平台能力，无法像Kubevirt等方案作为一个单独的Iaas管理平台使用

Virtual-Kubelet开发及部署

开发自定义的Provider

Virtual-Kubelet项目本身并不提供Provider,而是提供一系列定义Kubelet典型操作的接口，开发者需要根据应用场景实现对应的Provider。使Kubernetes可以进行按需和几乎即时的Container的计算、调度，而无需管理VM基础结构，同时仍可利用可移植的KubernetesAPI。

实现遵循以下三个准则：

• 提供必要的后端管道(back-end plumbing)，以在Kubernetes的Context中支持Pods，Containers和相关资源的的生命周期管理
• 符合Virtual-Kubelet当前提供的API
• 没有访问Kubernetes APIServer的权限，通过实现具有定义良好的回调机制来获取Secrets或Configmap之类的数据

创建一个新的Provider主要需要通过调用Virtual-Kubelet提供的库实现如下三个接口：

• PodLifecylceHandler：用于Pod生命周期的管理

type PodLifecycleHandler interface {

// CreatePod takes a Kubernetes Pod and deploys it within the provider.

CreatePod(ctx context.Context, pod *corev1.Pod) error

 

// UpdatePod takes a Kubernetes Pod and updates it within the provider.

UpdatePod(ctx context.Context, pod *corev1.Pod) error

 

// DeletePod takes a Kubernetes Pod and deletes it from the provider.

DeletePod(ctx context.Context, pod *corev1.Pod) error

 

// GetPod retrieves a pod by name from the provider (can be cached).

GetPod(ctx context.Context, namespace, name string) (*corev1.Pod, error)

 

// GetPodStatus retrieves the status of a pod by name from the provider.

GetPodStatus(ctx context.Context, namespace, name string) (*corev1.PodStatus, error)

 

// GetPods retrieves a list of all pods running on the provider (can be cached).

GetPods(context.Context) ([]*corev1.Pod, error)

}

• PodNotifier：该接口允许Provider提供异步通知Virtual-Kubelet有关Pod状态更新的信息，如未实现该接口的话，Virtual-Kubelet会定期检查所有Pod的状态，在计划运行大量Pod的场景中强烈推荐实现该接口

type PodNotifier interface {

// NotifyPods instructs the notifier to call the passed in function when

// the pod status changes.

//

// NotifyPods should not block callers.

NotifyPods(context.Context, func(*corev1.Pod))

}

• NodeProvider：NodeProvider负责通知虚拟小程序有关节点状态更新的信息。Virtual-Kubelet将定期检查节点的状态并相应地更新Kubernetes，如果不打算额外定义Node特性，可以直接使用Virtual-Kubelet提供的NativeNodeProvider

type NodeProvider interface {

// Ping checks if the node is still active.

// This is intended to be lightweight as it will be called periodically as a

// heartbeat to keep the node marked as ready in Kubernetes.

Ping(context.Context) error

 

// NotifyNodeStatus is used to asynchronously monitor the node.

// The passed in callback should be called any time there is a change to the

// node’s status.

// This will generally trigger a call to the Kubernetes API server to update

// the status.

//

// NotifyNodeStatus should not block callers.

NotifyNodeStatus(ctx context.Context, cb func(*corev1.Node))

}

• API Endpoints：用于实现kubectl logs和kubectl exec

部署

Provider部署简单仅需要在要添加目标集群的主机中添加二进制程序并根据IaaS层配置启动即可：

./bin/virtual-kubelet –provider=”hc-vmware-provider” –exsi=”X.X.X.X”

作者 | 白玙

随着容器技术蓬勃发展与落地推行，越来越多企业的业务运行于容器中。作为主流部署方式之一，容器将团队的任务和关注点分割开，开发团队只需关注应用程序逻辑和依赖项，而运维团队只需关注部署和管理，无需再为特定软件版本和应用程序特定配置等应用程序细节而提心吊胆。这意味着开发团队和运维团队可以花费更少时间进行调试上线，将更多时间用于向最终用户交付新功能。容器使企业可以更加轻松的提高应用程序可移植性和操作弹性。据 CNCF 的调研报告显示，73% 受访者正在使用容器来提高生产敏捷性并加快创新速度。

 

为什么我们需要容器监测

在大规模使用容器过程中，面对高动态且需要持续监测的容器化环境，建立监测体系对于维持运行环境稳定、优化资源成本具有巨大意义。每个容器镜像可能有大量运行实例，由于新镜像和新版本的引入速度很快，故障很容易通过容器、应用程序和架构扩散。这使得在问题发生后，为了防止异常扩散，立即进行问题根因定位变得至关重要。经过大量实践，我们认为在容器使用过程中，以下组件的监测至关重要：

主机服务器；
容器运行时；
Orchestrator 控制平面；
中间件依赖；
在容器内运行的应用程序。

在完整的监测体系下，通过深入了解指标、日志和链路，团队不仅可以了解在集群以及在容器运行时和应用程序中发生的事情，也可以为团队进行业务决策时提供数据支持，比如何时扩展/缩减实例/任务/Pod、更改实例类型。DevOps 工程师还可以通过添加自动化告警以及相关配置，来提高故障排除以及资源管理效率，比如通过主动监测内存利用率，当资源消耗接近所设定的阈值时通知运维团队对可用 CPU 、内存资源耗尽之前添加额外节点。这其中的价值包括：

及早发现问题，以避免系统中断；
跨云环境分析容器健康状况；
识别分配过多/不足的可用资源的集群，调整应用程序以获得更好性能；
创建智能警报，提高报警精准率，避免误报；
借助监测数据进行优化，获得最佳系统性能，降低运营成本。

但在实际落地过程中，运维团队会觉得以上价值相对浅显，似乎现有运维工具都能达到上述目的。但针对容器相关场景，如果无法构建相应监测体系，随着业务不断扩张，就不得不面临以下两个非常棘手的针对性问题：

 

1、排障时间拖长，SLA 无法满足。

开发团队与运维团队很难了解正在运行的内容及其执行情况。维护应用程序、满足 SLA 和故障排除异常困难。

2、可扩展性被拖累，无法实现弹性。

按需快速扩展应用程序或微服务实例的能力是容器化环境的重要要求。监测体系是衡量需求和用户体验的唯一可视化方法。扩展太晚，导致性能与用户体验的下降；过晚缩小规模，又会导致资源以及成本的浪费。

因此，当容器监测的问题以及价值，不断叠加且浮出水面，越来越多运维团队开始重视容器监测体系的搭建。但在实际落地容器监测这一过程中，又遇到各种各样意料之外的问题。

比如短暂存在特性带来的跟踪困难，由于容器自身存在着复杂性，容器不仅包含底层代码，还包含应用程序运行所需的所有底层服务。随着新部署投入生产，并更改代码和底层服务，容器化应用程序会频繁更新，这就增加了出错的可能。快速创建、快速销毁的特性，使得在大规模复杂系统中跟踪变化变得异常困难。

又比如，由于共享资源带来的监控困难，由于容器使用的内存和 CPU 等资源在一台或多台主机之间共享，因此很难监控物理主机上资源消耗情况，也导致很难获得容器性能或应用程序健康状况的良好指示。

最后，就是传统工具难以满足容器监测需求。传统的监测解决方案通常缺乏虚拟化环境所需的指标、跟踪和日志所需的工具，容器的健康和性能指标及工具更是如此。

因此，结合以上的价值、问题、难点，我们在建立容器监测体系时，需要从以下几个维度进行考量与设计：

无侵入性：监测SDK或者探针集成到业务代码是否存在侵入性，影响业务稳定下；

整体性：是否可以观测整个应用程序在业务和技术平台方面的表现；

多源性：是否可以从不同数据源获取相关指标和日志集进行汇总显示、分析和警报；

便捷性：是否可以关联事件和日志，发现异常并主被动地排除故障并降低损失，相关告警策略配置是否便捷。

在明确业务需求以及设计监测体系过程中，有非常多开源工具供运维团队选择，但运维团队还需要评估可能存在的业务与项目风险。这其中包括：

存在影响业务稳定性的未知风险，监测服务是否可以做到“无痕”。监测过程本身是否影响系统正常运作。

开源或自研的人力/时间投入难以预计，关联组件或资源需要自行配置或搭建，缺乏相应支持与服务，随着业务不断变化，是否可能耗费更多人力及时间成本。且面对大规模场景下性能问题，开源或企业自有团队是否可以快速应对。

 

阿里云 Kubernetes 监测：让容器集群监测更直观、更简单

因此，基于上述洞察考量与大量实践经验，阿里云推出 Kubernetes 监测服务。阿里云 Kubernetes 监测是一套针对 Kubernetes 集群开发的一站式可观测性产品。基于 Kubernetes 集群下的指标、应用链路、日志和事件，阿里云 Kubernetes 监测旨在为 IT 开发运维人员提供整体的可观测性方案。阿里云 Kubernetes 监测具备以下六大特性：

代码无侵入：通过旁路技术，无需代码埋点，即可获取到网络性能数据。
多语言支持：通过内核层进行网络协议解析，支持任意语言及框架。
低耗高性能：基于 eBPF 技术，以极低消耗获取网络性能数据。
资源自动拓扑：通过网络拓扑，资源拓扑展示相关资源的关联情况。
数据多维展现：支持可观测的各种类型数据（监测指标、链路、日志和事件）。
打造关联闭环：完整关联架构层、应用层、容器运行层、容器管控层、基础资源层相关可观测数据。

与此同时，相对于与开源容器监测，阿里云 Kubernetes 监测具备更加贴近业务场景的差异化价值：

数据量无上限：指标、链路、日志等数据独立存储，借助云存储能力确保低成本大容量存储。

资源高效关联交互：通过监测网络请求，完整构建网络拓扑，便于查看服务依赖状态，提升运维效率。除了网络拓扑之外，3D 拓扑功能支持同时查看网络拓扑和资源拓扑，提升问题定位速度。

多样化数据组合：指标、链路、日志等数据可视化展示并自由组合，挖掘运维优化点。

构建完整监测体系：与应用实时监测服务的其他子产品，共同构建完整监测体系。应用监测关注应用语言运行时、应用框架与业务代码；Kubernetes 监测关注容器化应用的容器运行时、容器管控层与系统调用，两个监测均服务于应用，关注应用的不同层次，两个产品互为补充。Prometheus 是指标采集，存储，查询的基础设施，应用监测与 Kubernetes 监测的指标类数据均依赖 Prometheus。

 

基于以上产品特性与差异化价值，我们应用在以下场景：

通过 Kubernetes 监测的系统默认或者自定义巡检规则，发现节点，服务与工作负载的异常。Kubernetes 监测从性能、资源、管控三个维度对节点、服务与工作负载进行异常巡检，将分析结果直观地通过正常、警告、严重等状态配合特定颜色进行展示，帮助运维人员直观感知用户节点，服务与工作负载运行状态。

使用 Kubernetes 监测定位服务与工作负载响应失败根因，Kubernetes 监测通过分析网络协议对失败请求进行明细存储，利用失败请求指标关联的失败请求明细定位失败原因。

使用 Kubernetes 监测定位服务与工作负载响应慢根因，Kubernetes 监测通过抓取网络链路关键路径的指标，查看 DNS 解析性能，TCP 重传率，网络包 rtt 等指标。利用网络链路关键路径的指标定位响应慢的原因，进而优化相关服务。

使用 Kubernetes 监测探索应用架构，发现预期外的网络流量。Kubernetes 监测支持查看全局流量构建起来的拓扑大图，支持配置静态端口标识特定服务。利用拓扑图直观强大的交互进行应用架构探索，验证流量是否符合预期，架构形态是否合理。

使用 Kubernetes 监测发现节点资源使用不均匀的问题，提前进行节点资源调配，降低业务运行风险。

目前，Kubernetes 监测已经开启全面公测，公测期间免费使用。让 Kubernetes 监测帮你摆脱机械重复的运维工作～

随着Docker和Kubernetes生态圈的发展，云计算领域对容器的兴趣达到了狂热的程度。容器技术为应用程序提供了隔离的运行空间，每个容器内都包含一个独享的完整用户环境空间，容器内的变动不会影响其他容器的运行环境。因为容器之间共享同一个系统内核，当同一个库被多个容器使用时，内存的使用效率会得到提升。基于物理主机操作系统内核的，那就意味着对于不同内核或者操作系统需求的应用是不可能部署在一起的。

虚拟化技术则是提供了一个完整的虚拟机，为用户提供了不依赖于宿主机内核的运行环境。对于从物理服务器过渡到虚拟服务器是一个很自然的过程，从用户使用上并没有什么区别。

目前Redhat开源的kubevirt和Mirantis开源的virtlet都提供了以容器方式运行虚拟机的方案。

kubevirt 是 Redhat 开源的以容器方式运行虚拟机的项目，以 k8s add-on方式，利用 k8s CRD 为增加资源类型Virtual Machine Instance（VMI）， 使用容器的image registry去创建虚拟机并提供VM生命周期管理。 用pod管理能力，要自主去实现，目前kubevirt实现了类似RS的功能。

那Virtlet是什么呢？

Virtlet 来自于 Mirantis，跟 kubevirt 的不同之处在于它使用 POD 来描述一个 VM（Virtual Machine,虚拟机)。Virtlet 是 Kubernetes 一个运行时服务，能够根据 QCOW2 映像运行 VM 工作负载。Virtlet是是K8S的一个插件，CRI接口兼容的插件，能够在 Kubernetes 集群上运行基于虚拟机的 Pods。

Virtlet的架构

CRIProxy作为代理，可以实现在一个节点上支持多种CRI。

kubelet会去调用CRIProxy，由CRIProxy根据pod image前缀（默认virtlet.cloud）决定将请求发给virtlet process 还是dockershim server，从而去创建虚拟机或者容器。

每个节点上会由daemonset负责启动virtlet pod，该virtlet pod包括三个容器：

• virtlet：接收 CRI 调用，管理VM
• libvirt：接收 virtlet 的请求创建、停止或销毁VM
• VMs：所有 virtlet 管理的VM 都会在这个容器的命名空间里

vm的确在vms container下，可以看到对应/proc/{id}/ns/下都是一致的，其实其他container ns只有mnt ns是不一样的。

Virtlet如何管理虚拟机

虚拟机生命周期管理流程

virtlet使用原生的workload（deployment，statefulset）去管理vm pod，vm的生命周期与pod一致。vm随着pod的创建而创建，随着pod的销毁而销毁。

整体流程：

1. deploy、statefulset等workload创建出对应的pod；
2. kubelet list-watch发现了调度到该节点的pod，根据cri调用criproxy；
3. criproxy会根据pod image前缀判断是将请求发给virtlet还是docker，比如pod image为virtlet.cloud/library/cirrors, 根据前缀匹配到virtlet.cloud,则将请求转给virtlet；
4. virtlet process会根据请求去调用libvirt api通过qemu-kvm去创建/输出虚拟机

虚拟机存储

virtlet支持原生存储范畴：

• emptydir
• hostpath
• pvc， 需要mode类型是block
• flexvolumes
• secret，configmap

可以通过annotation字段去配置磁盘驱动以及系统磁盘大小：

metadata:

name: my-vm

annotations:

kubernetes.io/target-runtime: virtlet.cloud

VirtletRootVolumeSize: 4Gi

VirtletDiskDriver: virtio

….

VirtletRootVolumeSize定义了根卷的磁盘大小，VirtletDiskDriver定义了磁盘驱动，常规磁盘驱动默认为virtio-scsi。

其中virtlet也支持cloud-init进行初始化配置，定义ssh密码以及相关用户、网络等初始化：

apiVersion: v1

kind: Pod

metadata:

name: ubuntu-vm

annotations:

kubernetes.io/target-runtime: virtlet.cloud

 

# override some fields in cloud-init meta-data

VirtletCloudInitMetaData: |

instance-id: foobar

 

# override some fields in cloud-init user-data

VirtletCloudInitUserData: |

users:

– name: cloudy

gecos: Magic Cloud App Daemon User

inactive: true

system: true

virtlet管理的虚拟机与容器如何实现整体交互

virtlet与常规CRI一样，也是使用CNI管理虚拟机的网络。

virtlet去调用cni之前，会创建出新的network namespace，通过tap设备连接虚拟机，veth pair连接主机网络与cni 网络模型。

当前连通virtlet管理的虚拟机方式：

• 根据virtlet pod IP地址，直接ssh形式
• kubectl attach命令， virtlet提供attach接口，能够以类似console形式访问
• virtletctl 命令，提供ssh，vps形式

虚拟机镜像

virtlet支持qcow格式的镜像文件，但需要在pod image定义中指定virtlet.cloud前缀。virtlet会将对镜像进行名称转换, 将名称转换成虚拟机镜像下载地址。

当前virtlet支持两种镜像名称转换的方式：

• 静态配置：默认kube-system会创建名为virtlet-image-translations的configmap

translations:

– name: cirros

url: https://github.com/mirantis/virtlet/releases/download/v0.9.3/cirros.img

– name: fedora

url: https://dl.fedoraproject.org/pub/fedora/linux/releases/29/Cloud/x86_64/images/Fedora-Cloud-Base-29-1.2.x86_64.qcow2

举个例子：

当你将image配置成virtlet.cloud/cirrors, virtlet会将该镜像转换成

https://github.com/mirantis/virtlet/releases/download/v0.9.3/cirros.img，virtlet根据该地址去下载，下载完毕后从而去创建虚拟机。

• 自定义对象配置：virtlet提供VirtletImageMapping资源对象，相对来说，优先级会高于静态配置

apiVersion: “virtlet.k8s/v1”

kind: VirtletImageMapping

metadata:

name: primary

namespace: kube-system

spec:

prefix: “”

translations:

– …

– …

默认的是，virtlet是基于文件系统进行存储虚拟机镜像，镜像存储地址如下：

/var/lib/virtlet/images

links/

example.com%whatever%etc -> ../data/2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881

example.com%same%image   -> ../data/2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881

anotherimg               -> ../data/a1fce4363854ff888cff4b8e7875d600c2682390412a8cf79b37d0b11148b0fa

data/

2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881

a1fce4363854ff888cff4b8e7875d600c2682390412a8cf79b37d0b11148b0fa

镜像名称中/字段转换成%，并软连接到匹配的数据文件。

Virtlet优缺点

优点

• 沿用原生workload，virtlet可无缝接入已有平台
• 复用CRI能力，侵入性小

缺点

• 引入CRIPROXY链路风险
• 限于CRI的整体框架内，无法灵活扩展
• 不支持CSI，仅支持flexvolume存储驱动
• 不支持备份与迁移等能力
• 社区活跃度低，已不再继续维护

整体来说，virtlet是一种接入成本低，能够快速融入已有云平台的方式，但由于社区已不维护且本身CRI方式对接的局限性，对后续的可扩展性以及迭代开发来说，其可扩展方式不够优雅且低，迭代开发难度相对来说大。