Skip to main content

· 阅读需要 1 分钟
曾庆国

KubeVela 1.5 于近日正式发布。在该版本中为社区带来了更多的开箱即用的应用交付能力,包括新增系统可观测;新增Cloud Shell 终端,将 Vela CLI 搬到了浏览器;增强的金丝雀发布;优化多环境应用交付工作流等。进一步提升和打磨了 KubeVela 作为应用交付平台的高扩展性体验。另外,社区也正式开始推动项目提级到 CNCF Incubation 阶段,同时在多次社区会议中听取了多个社区标杆用户的实践分享,这也证明了社区的良性发展。项目的成熟度,采纳度皆取得了阶段性成绩。这非常感谢社区 200 多位开发者的贡献。

KubeVela 近一年来发布了五个大版本,每一次迭代都是一个飞跃。1.1 的发布带来了衔接多集群的能力,1.2/1.3 带来了扩展体系和更友好的开发者体验,1.4 引入了全链路安全机制。 如今 1.5 的发布让我们离 KubeVela “让应用交付和管理更轻松”的愿景更近了一步。一路走来,我们始终遵循同样的设计理念,在不失可扩展性的基础上构建自动化处理底层差异化基础设施复杂性的平台,帮助应用开发者低成本从业务开发升级为云原生研发。技术上则围绕从代码到云、从应用交付到管理的完整链路,基于开放应用模型(OAM)提炼衔接基础设施的框架能力。如图 1 所示,如今的 KubeVela 已经覆盖了从应用定义、交付、运维、管理全链路的能力,而这一切能力都基于 OAM 的可扩展性(即 OAM Definition)插件式地衔接生态项目实现。本质上,每一个 Definition 都是将一项具体能力的使用经验,转化为一个可复用的最佳实践模块,通过插件打包实现企业共享或者社区共享。

kubevela-extensibility 图1 KubeVela 扩展性的核心结构

云原生领域的原子能力百花齐放既是宝贵的财富,同时也提升了从业门槛。平台构建者需要学习大量的开源项目,聚合多个领域的经验。这往往会花费几个月甚至更长的时间才能构建起企业云原生支撑平台。然而往往搭建的平台将复杂性直接传递给了应用开发者,使其也得学习大量的额外知识。 KubeVela 的设计理念和已有技术成果或许可以帮助到你快速进入云原生世界。KubeVela 在 1.5 版本以及之前数个版本中重点打磨的插件集成规范和统一应用交付体验,有效的解决了云原生领域的原子能力离散问题。

插件规范升级,更灵活的定义方式

KubeVela 插件机制从 1.2 版本发布以来,广受社区用户喜爱,社区插件仓库中已存在近 50 款插件。有近 50 位开发者参与了插件的贡献。

详见:https://github.com/kubevela/catalog

从 1.5 版本开始,插件开发者可以获得更优的体验。从插件定义,分发到可视化管理都全面提升。开发者除了可以使用 YAML 方式来定义插件以外,如果希望更灵活的组合插件包括的资源和更高级的参数化控制,开发者可以完全使用 CUE 来完成插件的定义。目前插件定义的规范包括以下几部分:

  • template.cue 或者 template.yaml 结合 resources 目录来定义插件的运行时,例如扩展一个工作负载需要在背后运行的 Operator 等。这一部分不是必须的,例如一些轻量级插件可以没有背后的运行时或者复用其他运行时。通过 YAML 和 CUE 结合的配置方式可以覆盖大多数需求场景。
  • definitions 目录,存放 Definition 定义,这是插件的核心部分,定义了该插件扩展的能力如何被用户使用。
  • schema 目录,用来辅助 Definition,定义相关 Definition 在 UI 侧的自定义渲染规则。
  • views 目录,存储 VelaQL 的语法定义,用来扩展 VelaQL 的查询能力。
  • metadata.yaml 与 readme.md,插件元数据定义文件,描述该插件的基础信息和环境需求。 具体规范详见文档:http://kubevela.net/zh/docs/platform-engineers/addon/intro

这里以集成 Helm Chart 包交付能力为例。目前社区中像 FluxCD 或 ArgoCD 项目都提供了部署 Chart 包的原子能力,他们的实现方式不同,各有优势。那么对于 KubeVela 的用户来说可以通过插件引入这个两个项目。如图 2 所示我们需要为终端用户定义一个标准的 API,根据企业实际情况向终端用户暴露必要的参数。

kubevela-helm 图2 KubeVela 扩展 Helm Chart 包的流程

如图 3 所示,根据标准的 API,前端 UI 即可自动生成对应的交互页面帮助终端用户便捷简单的完成 Helm Chart 包部署。平台侧根据用户的输入参数和插件定义自动生成底层能力的驱动配置,并智能获取相关状态反馈给用户。这些都是基于插件规范来描述,例如集成 FluxCD,该项目包括了多个控制器提供不同的原子能力,首先我们通过 template.cue 来定义FluxCD 的部署方式,基于不同的参数输入选择部署不同的组件。再通过 definitions 和 schema 目录来定义用户体验。

详细参考:https://github.com/kubevela/catalog/tree/master/addons/fluxcd

helm-ui 图3 KubeVela 交付 Helm Chart 包的交互

基于插件扩展的功能解读

Telemetry 集成 Prometheus + Grafana + Exporters 支撑系统可观测

应用可观测体系与应用发布关系紧密,一个好的应用可观测体系可以使得应用可靠性管理变得容易。KubeVela 社区将应用可观测列入核心 Feature。社区在 1.5 版本中首先选取了 KubeVela 系统本身的可观测作为案例进行体系能力的研发。目前实现了以下几个要点:

  1. 多集群可观测基础设施通过插件一键安装,我们首先围绕着 Prometheus + Grafana + Exporters 的方案形成了可观测插件集。面向不同的基础环境便捷安装基础能力。
  2. 支持一键开启多集群 Metrics 数据汇聚,采用 Thanos Query 方案实现多集群指标聚合查询和可视化。类似的方案将逐步覆盖 Logger 和 Tracing 维度。
  3. Grafana IaC 化。将 Grafana 的数据源,大盘等配置通过应用模型进行描述,创新性得使用扩展 API 轻量的将 Grafana API 变成了 KubeVela 可以操作的运行时。
  4. Grafana 大盘自动生成,用户可以通过启用 Grafana 插件即可自动生成 KubeVela 的系统可观测大盘,如图4 所示为 KubeVela 系统运行指标的大盘。该大盘即通过 IaC 体系自动生成,用户只需要启用对应的插件即可。

system dashboard 图4 KubeVela 系统可观测大盘

如图 5 所示为接入 KubeVela 的 Kubernetes API Sserver 服务的监控大盘。通过插件向所有子集群下发Exporter,将数据向各集群的 Prometheus 服务暴露,然后汇聚到管控集群进行集中可视化。花一份时间完成 N个集群的监控数据和大盘接入。

apiserver dashboard 图5 KubeVela 多集群 API 观测大盘

在接下来的版本中,社区将逐步将应用可观测的统一描述和交付融入应用交付过程。覆盖 Metric,Logger 和 Tracing 的数据获取,中间处理和传输,存储和分析,报警和可视化以及应用于应用发布流水线全链路。 参考文档:http://kubevela.net/docs/platform-engineers/operations/observability

集成 Cloud Shell 实现 CLI & UI 协同应用交付

通过 CLI 黑屏的方式操控应用交付的优势在于便捷、批量化和易复制,开发者尤其喜欢。通过 UI 的方式交付应用交互更加优雅,流程性的操作有利于降低学习成本,实现更严格的企业安全控制。可视化程度高可以更好的掌握应用,随时随地进行相关操作。过去的版本中 KubeVela 在 CLI 和 UI 两个维度上存在差异化大,数据不互通的问题。如果两种终端方式可以有效结合可以使应用交付和管理更加顺畅。在 1.5 版本中,KubeVela 引入了 CloudShell 插件,该插件为 UI 用户提供了 Web Shell 终端,统一的入口很好的解决了 CLI 和 UI 割裂的问题,同时带来了更多的能力。针对该流程主要变更如下:

  1. 开箱即用的工具集;不同于其他平台主要提供进入应用运行空间的 Web Shell 能力。CloudShell 为每一个用户生成一个终端环境,包括了 Vela,Kubectl 等 CLI 工具,在同一个环境中即可管理多个应用。
  2. 自动完成授权;用户无需关心如何分配 KubeConfig,系统自动根据 UI 用户所拥有的权限完成黑屏环境授权,实现了基本的白屏和黑屏的权限一致化。
  3. 环境自动回收;每一个用户的终端环境最长存活时间为 1 小时,过期后自动回收防止过多的资源消耗。
  4. 增强 Vela CLI 能力;重新实现了 log,status,exec,port-forward 等用于 Debug 应用的操作命令,针对应用下差异化工作负载实现了无缝兼容,让用户无感知的可以完成相关操作。无论是基础的 Deployment 资源还是 Helm 打包的负载资源集,亦或者是自定义的 Operator 驱动的工作负载。Vela 都可以自动发现命令相关的底层操作对象。
  5. 数据自动同步;CLI 可以创建更新应用,变更会同步的 UI 上进行可视化,直到用户选择通过 UI 来接管应用和后续的发布。

cloud shell 图6 KubeVela CloudShell 操作终端

集成 OpenKruise Rollout 提供金丝雀发布能力

KubeVela 社区在早期孵化了 Rollout 项目,与 Argo Rollout 的实现模式类似,以一种新的工作负载的形式工作,主要实现了分批发布的能力。随着社区发展,KubeVela 更聚焦于应用全局管控层和插件化扩展能力。因此工作负载层面的 Rollout 实现转移到了 OpenKruise 社区,在双方的共同努力下实现了可以针对原生 Deployment,StatefulSet 以及 OpenKruise 扩展的工作负载 CloneSet 多种工作负载的金丝雀发布能力。同时与 KubeVela 中的 Helm 交付模式共存时,可以实现针对 Helm Chart 包应用无需做任何变更即可进行金丝雀发布,这在业内具有创新性,对于用户非常便捷。Kruise Rollout 作为一个插件集成到了 KubeVela 生态。KubeVela 用户仅需要启用 插件,即可在应用组件中配置 Rollout Trait。同时可以与组件的 Gateway,HTTPRoute 等网关规则 Trait 实现协同。 整理下来,该实现有以下几项优势:

  1. 无侵入,无绑定;通过旁路的方式引入 Rollout 能力,用户无需对已有应用配置进行其他变更,引入成本低且随时可以移除;
  2. 易于使用;仅需要简单的配置流量切换规则,结合 KubeVela 的 UI 可视化,可以有效观测 Rollout 过程中的副本数量变化以及引入的额外资源关系;
  3. 兼容性好;不管用户使用了什么工作负载进行包装(Helm 或 自定义 Operator),Rollout 可以发现现底层的负载资源后以旁路形式工作。

参考文档:http://kubevela.net/docs/end-user/traits/rollout

VelaUX 增加多环境差异化可视化配置

VelaUX 至推出开始就具有了多环境部署能力,直到 1.5 版本,支持了用户可视化编辑多环境的差异化,从而真正匹配了用户多环境应用发布的需要。用户可以添加 Override Policy 配置,可以做到环境,集群或 Namespace 多个维度的差异化。应用的基准配置和差异化的配置统一管理。 如图5 所示,应用策略 Policy 已内置了多种可选项,包括差异化配置;应用多集群策略;应用维持策略和GC策略等等。通过 UI 的引导可以方便用户根据需要配置对应的策略。

create policy 图7 KubeVela Policy 新增/编辑窗口

在1.5 版本中,针对不同的环境部署前后新增了以下便捷功能:

  • DryRun(试运行)能力;用户可以在部署一个环境之前选择先进行 DryRun,通过 UI 反馈的结果评估应用配置是否符合预期,防止部署后才发现错误配置影响线上服务稳定性。

  • 环境差异洞察;切换到不同环境视图时自动进行本地配置与部署配置的比对,如果出现差异将提示用户并展示出差异的配置项。防止出现配置漂移或计划进行上线的配置忘记上线等。

  • 版本详情查询和差异比对;通过版本管理页面,可以查看每一个版本的应用配置渲染结果,也可以将版本配置与当前运行配置或最新的本地配置进行比对。方便用户追踪配置变更过程。

参考文档:http://kubevela.net/docs/tutorials/multi-env

应用引擎能力提升

除了上述的插件能力提升以外,在应用引擎方面也进行了大量的更新。其中性能优化提升明显,工作流执行时 CPU 消耗降低 75%。并行执行的数量显著提升。下面列举了以下重要的变更:

  1. Workflow 新增超时控制,在 Workflow 步骤中配置超时时间,当执行时间大于超时时间后 Workflow 将结束变为终止状态。
  2. Workflow 新增条件判断,在 Workflow 步骤中配置 If 字段,支持从 status 或 input 中读取数据进行判断以确定当前步骤是否需要执行。同时支持 If Always 机制,支持有些步骤需要在任何情况下执行的场景。
  3. Workflow 支持显示切换模式,支持 DAG 或者默认的 StepByStep。
  4. 新增共享资源策略,不同应用可以描述相同的资源,例如命名空间或者ConfigMap,设置为共享资源即不会冲突。
  5. 优化应用资源树构建算法,提升了在不同场景下的查询效率,更易于扩展自定义规则,同时增加了部分默认规则。

更多变更内容请参考:https://github.com/kubevela/kubevela/releases/tag/v1.5.0

结语

整体来说,随着 1.5 版本的发布,KubeVela 在产品能力,社区生态,标杆用户等多个维度都取得了显著进步。用户案例囊括了金融,智能制造,互联网等多个行业。我们也期待更多的用户可以分享你的实践经验,帮助 KubeVela 社区找到更准确的前进道路。在 1.6 的版本计划中,将带来更完善的应用可观测能力;独立于应用的工作流能力,衔接多个应用的持续发布控制和与可观测系统的协同。有相关需求和想法的开发者可以随时参与到社区讨论之中。

· 阅读需要 1 分钟

背景

Helm 是云原生领域被广泛采用的客户端应用打包和部署工具,其简洁的设计和易用的体验得到了用户的认可并形成了自己的生态,到如今已有近万个应用使用 Helm Chart 的方式打包。Helm 的设计理念足够简洁,甚至可以归纳为以下两条:

  1. 对复杂的 Kubernetes API 做打包和模板化,抽象并简化为少量参数。
  2. 给出应用生命周期解决方案:制作、上传(托管)、版本化、分发(发现)、部署。

这两条设计原则保证了 Helm 足够灵活,同时也足够简单,能够涵盖全部的 Kubernetes API,很好的解决了云原生应用一次性交付的场景。然而对于具备一定规模的企业而言,使用 Helm 做软件的持续交付就出现了不小的挑战。

Helm 持续交付的挑战

Helm 设计之初就为了保证其简单易用,放弃了复杂的组件编排。所以在应用部署时,Helm 是一股脑将所有的资源交付到 Kubernetes 集群中,期望通过 Kubernetes 面向终态的自愈能力,自动化的解决应用的依赖和编排问题。这样的设计在首次部署时可能没有问题,然而对于具备一定规模的企业生产环境而言,就显得过于理想化了。

一方面,在应用升级时一股脑将资源全部更新很容易因为部分服务短暂的不可用造成整体的服务中断;另一方面,如果软件存在 BUG,也无法及时回滚,很容易将影响范围扩大,难以控制。在某些更严重的场景下,如存在生产环境部分配置被运维人工修改过,由于 Helm 一次性部署会将原有的修改全部覆盖,而 Helm 之前的版本与生产环境可能并不一致,导致回滚也无法恢复,形成更大面积的故障。

由此可见,当具备一定规模以后,软件在生产环境的灰度和回滚的能力极其重要,而 Helm 自身并不能保证足够的稳定性。

如何针对 Helm 做金丝雀发布?

通常情况下,一个严谨的软件升级过程会遵从类似如下流程:大致分成三个阶段,第一阶段升级少量(如 20% )的实例,并切换少量流量到新版本,完成这个阶段后先暂停升级。经过人工确认之后继续第二个阶段,升级更大比例(如 90% )的实例和流量,再次暂停等待人工确认。最后阶段将全量升级到新版本并验证完毕,从而完成整个发布过程。如果升级期间发现包括业务指标在内的任何异常,例如 CPU或 memory 异常使用率升高或请求 500 日志过多等情况,可以快速回滚。

image

上面就是一个典型的金丝雀发布的场景,那么针对 Helm Chart 应用,我们该如何完成上面这个流程呢?业界的典型做法通常有如下两种:

  1. 修改 Helm Chart,将工作负载变成两份,并分别暴露出不同的 Helm 参数,在发布时不断修改两份工作负载的镜像、实例数和流量比例,从而实现灰度发布。
  2. 修改 Helm Chart,将原先的基础工作负载修改为具备同样功能但是具备灰度发布能力的自定义工作负载,并暴露出 Helm 参数,在发布是操纵这些灰度发布的 CRD。

这两个方案都很复杂,有不小的改造成本,尤其是当你的 Helm Chart 是第三方组件无法修改或自身不具备维护 Helm Chart 能力时,这些方法都是不可行的。即使真的去改造了,相比于原先简单的工作负载模式,也存在不小的稳定性风险。究其原因,还是在于 Helm 本身的定位只是一个包管理工具,设计时并不考虑灰度发布、也不针对工作负载做管理。

事实上,当我们跟社区的大量用户深入交流以后,我们发现大多数用户的应用并不复杂,类别都是诸如 Deployment、StatefulSet 这些经典的类型。所以,我们通过 KubeVela( http://kubevela.net/ ) 强大的插件机制,联合 OpenKruise (https://openkruise.io/)社区做了一款针对这些限定类型的金丝雀发布插件。这款插件帮助你不做任何迁移改造,轻松完成 Helm Chart 的灰度发布。不仅如此,如果你的 Helm Chart 比较复杂,你完全可以针对你的场景定制一个插件,获得同样的体验。

下面我们通过一个实际的例子(以 Deployment工作负载为例),手把手带你感受一下完整的流程。

使用 KubeVela 做金丝雀发布

环境准备

  • 安装 KubeVela
$ curl -fsSl https://static.kubevela.net/script/install-velad.sh | bash
velad install

See this document for more installation details.

  • 启用相关的 addon
$ vela addon enable fluxcd
$ vela addon enable ingress-nginx
$ vela addon enable kruise-rollout
$ vela addon enable velaux

在这一步中,启动了以下几个插件:

  1. fluxcd 插件帮助我们具备 helm 交付的能力;
  2. ingress-nginx 插件用于提供金丝雀发布的流量管理能力;
  3. kruise-rollout 提供金丝雀发布能力;
  4. velaux 插件则提供界面操作和可视化。
  • 将 nginx ingress-controller 的端口映射到本地
$ vela port-forward addon-ingress-nginx -n vela-system

首次部署

通过执行下面的命令,第一次发布 helm 应用。在这一步中,我们通过 vela 的 CLI 工具部署,如果你熟悉 Kubernetes,也可以通过 kubectl apply 部署,效果完全相同。

cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: canary-demo
annotations:
app.oam.dev/publishVersion: v1
spec:
components:
- name: canary-demo
type: helm
properties:
repoType: "helm"
url: "https://wangyikewxgm.github.io/my-charts/"
chart: "canary-demo"
version: "1.0.0"
traits:
- type: kruise-rollout
properties:
canary:
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
steps:
- weight: 20
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
- weight: 90
trafficRoutings:
- type: nginx
EOF

在上面的例子中,我们声明了一个名为 canary-demo 的应用,其中包含一个 helm 类型的组件(KubeVela 也支持其他类型的组件部署),在组件的参数中包含 chart 的地址以及版本等信息。

另外,我们还为这个组件声明了 kruise-rollout 的运维特征,这个就是 kruise-rollout 这个插件安装后具备的能力。其中可以指定 helm 的升级策略,第一个阶段先升级 20% 的实例和流量,经过人工确认之后再升级90%,最后全量升到最新的版本。

需要注意的是,为了演示效果直观(体现版本变化),我们专门准备了一个 chart 。该 helm chart 的主体包含一个 Deployment 和 Ingress 对象,这是 helm chart 制作时最通用的场景。如果你的 helm chart 同样具备上述的资源,也一样可以通过这个例子进行金丝雀的发布。

部署成功之后,我们通过下面的命令访问你集群内的网关地址,将会看到下面的效果:

$ curl -H "Host: canary-demo.com" http://localhost:8080/version
Demo: V1

另外,通过 VelaUX 的资源拓扑页面,我们可以看到五个 V1 版本的实例已经全部就绪。

image

升级应用

应用下面的这个 yaml ,来升级你的应用。

cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: canary-demo
annotations:
app.oam.dev/publishVersion: v2
spec:
components:
- name: canary-demo
type: helm
properties:
repoType: "helm"
url: "https://wangyikewxgm.github.io/my-charts/"
chart: "canary-demo"
# Upgade to version 2.0.0
version: "2.0.0"
traits:
- type: kruise-rollout
properties:
canary:
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
steps:
- weight: 20
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
- weight: 90
trafficRoutings:
- type: nginx
EOF

我们注意到新的 application 和首次部署的相比仅有两处改动:

  1. 把 app.oam.dev/publishVersion 的 annotation 从 v1 升级到了 v2。这代表这次修改是一个新的版本。
  2. 把 helm chart 的版本升级到了 2.0.0 ,该版本的 chart 中的 deployment 镜像的 tag 升级到了 V2。

一段时间之后,我们会发现升级过程停在了我们上面定义的第一个批次,也就是只升级 20% 的实例和流量。这个时候多次执行上面访问网关的命令,你会发现 Demo: v1和 Demo: v2交替出现,并且有差不多 20% 的概率得到 Demo: v2的结果。

$ curl -H "Host: canary-demo.com" http://localhost:8080/version
Demo: V2

再次查看应用的资源的拓扑状态,会看到由 kruise-rollout trait 创建出来的 rolloutCR 为我们创建了一个新版本的实例,而之前工作负载创建出来的5个旧版本的实例并没有发生变化。

image

接下来,我们通过 vela 的 CLI 执行下面的命令,通过人工审核恢复继续升级:

$ vela workflow resume canary-demo

一段时间之后,通过资源拓扑图,我们看到五个新版本的实例被创建出来了。这个时候我们再次访问网关,会发现出现 Demo:v2 的概率大幅增加,接近于90%。

快速回滚

通常在一个真实场景中的发布中,经常会有经过人工审核之后,发现新版本应用的状态异常,需要终止当前的升级,快速将应用回退到升级开始前的版本。

我们就可以执行下面的命令,先暂停当前的发布工作流:

$ vela workflow suspend canary-demo
Rollout default/canary-demo in cluster suspended.
Successfully suspend workflow: canary-demo

紧接着回滚到发布之前的版本,也就是 V1 :

$ vela workflow rollback canary-demo
Application spec rollback successfully.
Application status rollback successfully.
Rollout default/canary-demo in cluster rollback.
Successfully rollback rolloutApplication outdated revision cleaned up.

这个时候,我们再次访问网关,会发现所有的请求结果又回到了 V1 的状态。

$ curl -H "Host: canary-demo.com" http://localhost:8080/version
Demo: V1

这时候,通过资源拓扑图,我们可以看到,金丝雀版本的实例也全部被删除了,并且从始至终,v1 的五个实例,作为稳定版本的实例,一直没有发生任何变化。

image

如果你将上面的回滚操作改为恢复继续升级,将会继续执行后续的升级过程,完成全量发布。

上述 demo 的完整操作过程请参考 文档

如果你希望直接使用原生的 k8s 资源实现上面过程可以参考 文档 。另外,除了 Deployment ,kruise-rollout 插件还支持了 StatefulSet 和 OpenKruise 的 CloneSet ,如果你的 chart 中的工作负载类型是以上三种都可以通过上面的例子实现金丝雀发布。

相信你也看注意到,上面的例子我们给出的是基于 nginx-Ingress-controller 的七层流量切分方案,另外我们也支持了 Kubernetes Gateway 的 API 从而能够支持更多的网关类型和四层的流量切分方案。

发布过程的稳定性是如何保证的?

首次部署完成后,kruise rollout 插件(以下简称 rollout)会监听 Helm Chart部署的资源,在我们的例子中就是 deployment, service 和 ingress ,还支持 StatefulSet 以及 OpenKruise Cloneset。rollout 会接管这个 deployment 后续的升级动作。

在进行升级时,新版本的 Helm 部署首先生效,会将 deployment 的镜像更新为 v2,然而这个时候 deployment 的升级过程会被 rollout 从 controller-manager 手中接管,使得 deployment 下面的 Pod 不会被升级。于此同时,rollout 会复制一个金丝雀版本的 deployment,镜像的 tag 为 v2,并创建一个 service 筛选到它下面的实例,和一个指向这个 service 的 ingress ,最后通过设置 ingress 相对应的 annotation,让这个 ingress 承接金丝雀版本的流量,具体可以参考 文档 ,从而实现流量切分。

在通过所有的人工确认步骤之后,完成全量发布时,rollout 会把稳定版本的 deployment 升级控制权交还给 controller-manager ,届时稳定版本的实例会陆续升级到新版本,当稳定版本的实例全部就绪之后,才会陆续销毁金丝雀版本的 deployment,service 和 ingress,从而保证了整个过程中请求流量不会因为打到没有就绪的实例上,导致请求异常,做到无损的金丝雀发布。

之后我们还将在以下方面持续迭代,支持更多的场景并带来更加稳定可靠的升级体验:

  1. 升级过程对接 KubeVela 的 workflow 体系,从而引入更加丰富的中间步骤扩展体系,支持升级过程中通过 workflow 执行通知发送等功能。甚至在各个步骤的暂停阶段,对接外部的可观测性体系,通过检查日志或者监控等指标,自动决策是否继续发布或回滚,从而实现无人值守的发布策略。
  2. 集成 istio 等 更多的 addon,支持 serviceMesh 的流量切分方案。
  3. 除了支持基于百分比流量切分方式,支持基于 header 或 cookie 的流量切分规则,以及支持诸如蓝绿发布等特性。

总结

前文已经提到,KubeVela 支持 Helm 做金丝雀发布的流程完全是通过 插件(Addon)体系实现的,fluxcd addon 助我们通过部署和管理 helm chart 的生命周期。kruise-rollout addon 帮助我们实现 workload 的实例升级以及在升级过程中流量的切换。通过组合两个 addon 的方式,实现了对于 helm 应用的全生命周期的管理和金丝雀升级,不需要对你的 Helm Chart 做任何改动。你也可以针对你的场景 编写插件 ,完成更特殊的场景或流程。

基于 KubeVela 强大的可扩展能力,你不仅可以灵活地组合这些 addon,你还可以保持上层应用不做任何变动的情况下,根据不同的平台或环境动态替换底层的能力实现。例如,如果你更希望采用 argocd 不是 fluxcd 实现对于 helm 应用的部署,你就可以通过启用 argocd 的 addon 实现相同的功能,上层的 helm 应用不需要做任何改变或迁移。

现在 KubeVela 社区已经提供了数十个 addon ,可以能够帮助平台扩展 可观测性,gitOps,finOps ,rollout 等各方面的能力。

image

Addon 的仓库地址是:https://github.com/kubevela/catalog ,如果你对 addon 感兴趣的话,也非常欢迎为这个仓库提交你的自定义插件,为社区贡献新的生态能力!

· 阅读需要 1 分钟

你可能已经从这篇博客 中了解到,我们可以通过 terraform 插件使用 vela 来管理云资源(如 s3 bucket、AWS EIP 等)。 我们可以创建一个包含一些云资源组件的应用,这个应用会生成这些云资源,然后我们可以使用 vela 来管理它们。

有时我们已经有一些 Terraform 云资源,这些资源可能由 Terraform 二进制程序或其他程序创建和管理。 为了获得 使用 KubeVela 管理云资源的好处 或者只是在管理云资源的方式上保持一致性,我们可能希望将这些现有的 Terraform 云资源导入 KubeVela 并使用 vela 进行管理。如果我们只是创建一个描述这些云资源的应用,这些云资源将被重新创建并可能导致错误。 为了解决这个问题,我们制作了 一个简单的 backup_restore 工具。 本博客将向你展示如何使用 backup_restore 工具将现有的 Terraform 云资源导入 KubeVela。

步骤1:创建 Terraform 云资源

由于我们要演示如何将现有的云资源导入 KubeVela,我们需要先创建一个。 如果你已经拥有此类资源,则可以跳过此步骤。

在开始之前,请确保你已经:

· 阅读需要 1 分钟

Helm Charts 如今已是一种非常流行的软件打包方式,在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中,业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下,单纯依赖 Helm 工具可能无法做到灵活的部署和交付。

在本文中,我们将介绍如何通过 KubeVela 解决多集群环境下 Helm Chart 的部署问题。如果你手里没有多集群也不要紧,我们将介绍一种仅依赖于 Docker 或者 Linux 系统的轻量级部署方式,可以让你轻松的体验多集群功能。当然,KubeVela 也完全具备单集群的 Helm Chart 交付能力。

· 阅读需要 1 分钟

如果您正在寻找将 Terraform 生态系统与 Kubernetes 世界粘合在一起的东西,那么恭喜!你在这个博客中得到了你想要的答案。

随着各大云厂商产品版图的扩大,基础计算设施,中间件服务,大数据/AI 服务,应用运维管理服务等都可以直接被企业和开发者拿来即用。我们注意到也有不少企业基于不同云厂商的服务作为基础来建设自己的企业基础设施中台。为了更高效,统一的管理云服务,IaC 思想近年来盛行,其中 Terrafrom 更是成功得到了几乎所有的云厂商的采纳和支持。以 Terrafrom 模型为核心的云服务 IaC 生态已经形成。然而在 Kubernetes 大行其道的今天,IaC 被冠以更广大的想象空间,Terraform IaC 能力和生态成果如果融入 Kubernetes 世界,我们认为这是一种强强联合。

· 阅读需要 1 分钟
孙健波,曾庆国

KubeVela 是一个现代化的软件交付控制平面,目标是让应用的部署和运维在如今的混合多云环境下更简单、敏捷、可靠。自 1.1 版本发布以来,KubeVela 架构上天然打通了企业面向混合多云环境的交付难题,且围绕 OAM 模型提供了充分的可扩展性,赢得了大量企业开发者的喜爱,这也使得 KubeVela 的迭代速度不断加快。

1.2 版本我们发布了开箱即用的可视化控制台,终端用户可以通过界面发布和管理多样化的工作负载;1.3 版本 的发布则完善了以 OAM 模型为核心的扩展体系,提供了丰富的插件功能,并给用户提供了包括 LDAP 权限认证在内的大量企业级功能,同时为企业集成提供了巨大的便利。至今为止,你已经可以在 KubeVela 社区的插件中心里获得 30 多种插件,其中不仅包含了 argocd、istio、traefik 这样的 CNCF 知名项目,更有 flink、mysql 等数据库中间件,以及上百种不同云厂商资源可供直接使用。

在这次发布的 1.4 版本中,我们围绕让应用交付更安全、上手更简单、过程更透明三个核心,加入了包括多集群权限认证和授权、复杂资源拓扑展示、一键安装控制平面等核心功能,全面加固了多租户场景下的交付安全性,提升了应用开发和交付的一致性体验,也让应用交付过程更加透明化。

· 阅读需要 1 分钟

在应用交付中另一个很大的诉求是对资源交付流程的透明化管理,比如社区里很多用户喜欢使用 Helm Chart ,把一大堆复杂的 YAML 打包在一起,但是一旦部署出现问题,如底层存储未正常提供、关联资源未正常创建、底层配置不正确等,即使是一个很小的问题也会因为整体黑盒化而难以排查。尤其是在现代混合的多集群混合环境下,资源类型众多、错综复杂,如何从中获取到有效信息并解决问题是一个非常大的难题。

· 阅读需要 1 分钟

本篇博客将介绍如何使用 CUE 和 KubeVela 构建自己的抽象 API,以降低 Kubernetes 资源的复杂性。 作为平台构建者,你可以动态定制抽象,根据需求为你的开发者构建一条由浅入深的路径,适应越来越多的不同场景,满足公司长期业务发展的迭代需求。

· 阅读需要 1 分钟
KubeVela 社区

得益于 KubeVela 社区上百位开发者的参与和 30 多位核心贡献者的 500 多次代码提交, KubeVela 1.3 版本正式发布。相较于三个月前发布的 v1.2 版本,新版本在 OAM 核心引擎(Vela Core),可视化应用交付平台 (VelaUX) 和社区插件生态这三方面都给出了大量新特性。这些特性的诞生均源自于阿里巴巴、LINE、招商银行、爱奇艺等社区用户大量的深度实践,最终贡献到 KubeVela 项目中,形成大家可以开箱即用的功能。

· 阅读需要 1 分钟
段威(段少)

在当今的多集群业务场景下,我们经常遇到的需求有:分发到多个指定集群、按业务规划实现分组分发、以及对多集群进行差异化配置等等。

KubeVela v1.3 在之前的多集群功能上进行了迭代,本文将为你揭示,如何使用 KubeVela 进行多集群应用的部署与管理,实现以上的业务需求。