江苏龙网

  1. 主页 > 生活百科 > >

基于 KubeVela 的 GitOps 交付

KubeVela

KubeVela 作为一个声明式的应用交付控制平面，天然就可以以 GitOps 的方式进行使用，并且这样做会在 GitOps 的基础上为用户提供更多的益处和端到端的体验，包括：

  • 应用交付工作流（CD 流水线）：KubeVela 支持在 GitOps 模式中描述过程式的应用交付，而不只是简单的声明终态；
  • 处理部署过程中的各种依赖关系和拓扑结构；
  • 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程；
  • 统一进行云服务的声明、部署和服务绑定；
  • 提供开箱即用的交付策略（金丝雀、蓝绿发布等）；
  • 提供开箱即用的混合云/多云部署策略（放置规则、集群过滤规则等）；
  • 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而无需学习任何 Kustomize 本身的细节
GitOps 模式需要依赖 FluxCD 插件 ， 所以在使用 GitOps 模式下交付应用之前需要先启用 FluxCD 插件 。
vela addon enable fluxcdGitOps 工作流分为 CI 和 `CD 两个部分：
  • CI：持续集成对业务代码进行代码构建、构建镜像并推送至镜像仓库 。目前有许多成熟的 CI 工具：如开源项目常用的 Github Action、Travis 等，以及企业中常用的 Jenkins、Tekton 等，KubeVela 围绕 GitOps 可以对接任意工具下的 CI 流程 。
  • CD：持续部署会自动更新集群中的配置 ， 如将镜像仓库中的最新镜像更新到集群中 。目前主要有两种方案的 CD：
  • Push-Based：Push 模式的 CD 主要是通过配置 CI 流水线来完成的，这种方式需要将集群的访问秘钥共享给 CI，从而使得 CI 流水线能够通过命令将更改推送到集群中 。前面我们讲解的 Jenkins 方式就属于该方案 。
  • Pull-Based：Pull 模式的 CD 会在集群中监听仓库（代码仓库或者配置仓库）的变化，并且将这些变化同步到集群中 。这种方式与 Push 模式相比，由集群主动拉取更新，从而避免了秘钥暴露的问题 。前面课程中我们讲解的 Argo CD 与 Flux CD 就属于这种模式 。
而交付面向的人员有以下两种：
  • 面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置 ， 如系统的依赖软件、安全策略、存储、网络等基础设施配置 。
  • 面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代 ， 与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力 。
面向平台管理员/运维人员的交付如下图所示，对于平台管理员/运维人员而言 ， 他们并不需要关心应用的代码 ， 所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪 。
基于 KubeVela 的 GitOps 交付

文章插图
这里我们将部署一个 MySQL 数据库作为项目的基础设施，同时部署一个业务应用，使用这个数据库 。配置仓库的目录结构如下:
  • clusters/ 中包含集群中的 KubeVela GitOps 配置，用户需要将 clusters/ 中的文件手动部署到集群中 。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置 。其中，clusters/Apps.yaml 将监听 apps/ 下所有应用的变化，clusters/infra.yaml 将监听 infrastructure/ 下所有基础设施的变化 。
  • apps/ 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用 。
  • infrastructure/ 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库 。
├── apps│└── my-app.yaml├── clusters│├── apps.yaml│└── infra.yaml└── infrastructure└── mysql.yaml


推荐阅读


上一篇：Spring的BeanFactory与FactoryBean的区别，你现在懂了吗？

下一篇：Mybatis占位符#和$的区别？源码解读