原创 吴就业 155 0 2023-07-23
本文为博主原创文章,未经博主允许不得转载。
本文链接:https://wujiuye.com/article/4520e1bbebf04aa88a5316ccb1c4559a
作者:吴就业
链接:https://wujiuye.com/article/4520e1bbebf04aa88a5316ccb1c4559a
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。
以一个简单的first-vela-app应用在kubevela上部署为例,介绍应用安装流程:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-vela-app
spec:
components:
- name: simple-server
type: webservice
properties:
image: oamdev/hello-world
ports:
- port: 8000
expose: true
traits:
- type: scaler
properties:
replicas: 1
执行vela up -f application.yaml命令,实际就是将application.yaml apply到k8s中(这里指的是kubevela底座的k8s集群,即管控集群),然后由application_controller监听事件处理application的安装/更新。
velad是kubevela的命令行工具:https://github.com/kubevela/velad,实际vela命令的代码实现在kubevela项目的references包下。
application_controller中会将应用的部署转为工作流(Workflow),每一步称为一个工作流步骤(WorkflowSteps),安装应用,就是按依赖顺序执行工作流步骤。如果需要对部署流程卡点,可以给工作流加入卡点审批步骤。每个工作流步骤都可以有子工作流,这里不展开。
在first-vela-app这个例子中,我们并没有声明任何工作流步骤,只声明了一个类型为webservice且名为simple-server的组件,为什么也会安装成功这个组件?
实际上,当我们没有声明任何工作流步骤时,application_controller会为每一个组件生成一个类型为“apply-component”的工作流步骤,放在工作流的后面。相当于:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-vela-app
spec:
components:
- name: simple-server
type: webservice
properties:
image: oamdev/hello-world
ports:
- port: 8000
expose: true
traits:
- type: scaler
properties:
replicas: 1
workflow:
- type: apply-component
name: simple-server
properties:
component: simple-server
当执行“apply-component”类型的工作流步骤时,如果组件类型不是terraform,kubevela将组件渲染成目标工作负载(workload)之后,applay到目标k8s集群,后续交由k8s处理。否则如果组件类型是terraform,将组件渲染成Configuration之后,直接apply到管控集群(也就是当前kubevela所在集群),后续则交由terraform-controller处理。
如何理解渲染组件?根据组件的定义(其实就是模版),填充给组件填写的参数,就能得到一个组件对象,这个过程就是组件渲染。
如案例中,组件类型是webservice,工作负载是Deployment。kubevela安装webservice组件,就是将webservice组件渲染成Deployment,然后直接apply到k8s集群,监听Deployment的状态直到完成,就完成了webservice组件的部署。另外,组件还绑定了一个scaler运维特征,这个运维特征会随着组件一起渲染apply到k8s集群。 组件默认是部署到local集群,也就是kubevela所在的集群(管控集群)。
我们可以给kubevela添加一个k8s集群,并将集群命名为cluster-wjy,让kubevela管理这个集群,执行命令:
vela cluster join ~/.kube/config_wjy --name cluster-wjy
我们可以添加一个Topology策略,声明将组件安装到cluster-wjy集群:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-vela-app
spec:
components:
- name: express-server
type: webservice
properties:
image: oamdev/hello-world
ports:
- port: 8000
expose: true
traits:
- type: scaler
properties:
replicas: 1
policies:
- name: wjy-topology
type: topology
properties:
clusters: ["cluster-wjy"]
Topology策略是kubevela内置的策略,描述组件应该部署到的集群环境。同样的,当我们没有声明任何工作流步骤时,kubevela会为每个Topology策略生成一个deploy工作流步骤,并且kubevela不会再为组件生成apply-component工作流步骤。deploy工作流步骤会承接所有组件的部署工作,将会加载所有(包括terraform类型)的组件,编排成任务执行,而组件的部署逻辑,原来是什么逻辑就还是什么逻辑。
上面的application.yaml部署清单等价于:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-vela-app
spec:
components:
- name: express-server
type: webservice
properties:
image: oamdev/hello-world
ports:
- port: 8000
expose: true
traits:
- type: scaler
properties:
replicas: 1
policies:
- name: wjy-topology
type: topology
properties:
clusters: ["cluster-wjy"]
workflow:
- type: deploy
name: deploy-wjy-topology
properties:
policies: ["wjy-topology"]
如上,我们声明了一个Topology策略,指定部署集群为“cluster-wjy”,这样该app下的每个非terraform类型的组件,在渲染完成工作负载后,都会apply到“cluster-wjy”上。注意,由于我们手动添加了一个工作流步骤,如果Application存在terraform类型的组件,就需要手动添加工作流步骤来部署这些terraform类型的组件了,否则terraform类型的组件就不会部署。
看源码只看代码相当于用人脑执行代码,难免会出错,所以调试代码也是看源码的一部分。那么应该怎么调试kubevela?
1.本地通过kind安装一个k3s集群,安装后~/.kube/config就是这个集群的kubeconfig。 2.不要部署kubevela,下载kubevela源码。 3.安装kubevela的自定义资源定义(CRD)
cd $kubevela源码目录/charts
kubectl apply -f ./vela-core/crds
4.然后安装部署一个simple应用至少需要依赖的组件定义、工作流步骤定义。(需要替换helm的变量占位符)
kubectl apply -f ./vela-core/templates/apply-component.yaml
kubectl apply -f ./vela-core/templates/deploy.yaml
5.根据需要部署的组件安装需要的组件定义,例如webservice.yaml。
kubectl apply -f ./vela-core/templates/webservice.yaml
6.本地run/debug启动kubevela,就可以下断点调试了。 7.可以编写一个application.yaml,使用vela命令安装,用来debug。
声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。
通过前面的章节,我们已经学习了解terraform,并通过vpc资源例子,为私有云/混合云开发了terraform provider,这一节介绍如何将我们开发的mycloud terraform provider整合到kubevela控制平台上,以通过在application中声明一个kubevela组件的方式去申请基础设施资源。
KubeVela是面向混合云环境的应用交付控制面,不与任何云产商绑定。KubeVela通过提供插件扩展机制,打通了应用交付涉及的基础设施即代码-terraform等能力。编写一个符合OAM模型的application.yaml就能实现将应用部署起来,包括申请基础设施。实现了声明式部署,且一次编写,到处部署。
“部署即代码”即用代码描述一个应用的部署计划。KubeVela就是实现这一目标的平台,让我们可以编写一个符合OAM模型的yaml来描述应用的部署。
Go sdk本地开发调试sdk依赖问题;关于复杂嵌套结构体的schema声明;状态死循环监听,以及terraform命令终止时如何终止死循环;资源创建接口的默认可选字段不填遇到的坑;HCL代码输入变量的复杂校验。
订阅
订阅新文章发布通知吧,不错过精彩内容!
输入邮箱,提交后我们会给您发送一封邮件,您需点击邮件中的链接完成订阅设置。