开发者学堂课程【第八届大学生创新创业大赛阿里命题云原生命题培训：KubeVela 安装以及第一个应用】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1044/detail/15203
KubeVela 安装以及第一个应用
内容介绍：
一、安装 KubeVela
二、安装 KubeVela 插件
三、交付第一个应用
一、安装 KubeVela
1、准备集群
在之前的学习当中，已经了解了 KubeVela 到底是什么以及 OAM 的一些具体概念，现在来学习如何安装 KubeVela。
首先需要准备一个集群，推荐使用 ACK 集群，也可以选择在本地搭建 kind 或者 MiniKube 集群。创建一个 ACK 的集群，需要进行一些配置，可以使用 EIP 暴露 API server，这样后续会方便一些。
可以看到，大部分做的一些配置都是按照默认的设置走的，ACK 里提供的默认设置是比较方便的，在完成了配置之后，可以直接创建这个集群。在这里会使用一个之前已经创建好的 ACK 集群进行演示，
这里有一个 demo-cluster，是之前刚创建好的，接下来会用这个集群去完成 KubeVela 的安装。
2、使用 Helm 安装
在安装这一步，会使用 Helm 进行安装，首先需要添加并更新 KubeVela Helm Chart，
目前这样一个集群中，它是没有 KubeVela 的，是一个干净的集群，在 ACK 的集群当中，默认是添加着 KubeVela 的仓库的，
可以看到，已经被添加了。然后更新 Helm 仓库，
更新完成之后，通过
helm install --create-namespace -n vela-system kubevela
kubevela/vela-core --wait
命令安装 KubeVela。
在这里加上了刚刚--create-namespace 参数，这个参数默认创建 vela-system 的namespace，并且加上了刚刚 wait 的参数，这个参数会默认的帮我们等待 KubeVela 的所有组件都已经成功运行之后才会退出命令。
现在 KubeVela 已经成功的部署了，可以查看 KubeVela name space 下面的组件，
目前装了一个 core 的 controller 以及一个 apiserver，所有的组件都已经成功运行。
接下来推荐安装 KubeVela 的 CLI，在安装完 CLI 之后，之后的命令都会使用 CLI 进行演示，由于现在演示的是在 Mac 系统下的操作，所以会选用 brew 去安装，如果是在 Linux 的操作系统下面，也可以使用其他的包安装的方式，具体的可以查看 KubeVela 的官方文档，里面都有关于各个操作系统的安装方式。
之前已经安装过 KubeVela 的 CLI 了，所以这边已经是装完了。这个 CLI 的命令是 vela，可以看一下它目前的版本。
Vela 的目前版本是1.1.5，和现在的 KubeVela 版本是进行匹配的，至此就已经完成了整个 KubeVela 以及它的 CLI 的安装。
二、安装 KubeVela 插件
接下来可以安装 KubeVela 的插件，KubeVela 目前有许许多多的插件，它为整个 KubeVela的生态提供了一个更好的方式，可以查看一下目前有哪些插件。使用 vela addon list 可以查看目前可以安装的所有组件，
第一列是组件的名称，第二列是组件的一些描述，第三列是表明组件是否有被安装，这里目前全部都是 uninstalled，表示现在没有安装任何一个组件。最后一个是组件将会被安装在的 namespace，比如第一个 addon，fluxcd，它其实就是一个用于持续部署的交互组件，并且里面会带上一些比较常用的组件，比如 helm 以及 kustomize，后面是 istio 的默认 controller 的安装，如果想用一些资源类型，里边还有 terraform，可以使用 enable 这个 terraform 的插件完成对资源的一些管控。在这里安装一个 fluxcd 的组件，可以通过 vela addon 的命令把插件成功开启，
它正在初始化 fluxcd 的组件，
插件已经成功被安装了，再次 list 来查看插件的状态，
fluxcd 的插件目前 status 已经变成了 installed，还有个变成 installed 的是 ns-flux-system，第一个 fluxcd 插件会依赖 ns-flux-system 插件的 Namespace 插件的安装，所以它会默认把 Name space 也给安装上。
所以会多了一个 fluxcd 的 namespace，
并且在里面会跑的 fluxcd 的一些 pod。
目前已经把插件成功安装起来了，然后可以查看目前在整个 KubeVela 中已经安装的一些能力，可以通过 vela components 查看目前已经安装的一些 component DeFinition，
已有的一些 component DeFinition，除了常用的 worker、webservice 之外，还把 helm 和kustomize 也装上去了，这个就是刚刚通过 addon 安装起来的一些 components。在这些 components 后面都有对应的一些介绍，比如 helm，它可以安装一些 helm 的一些 chart，比如接下来会演示用 webservice 部署一个最简单的 Vela 应用，而 webservice 就是 long running 的一个组件，并且它可以带上一些 service，因为相当于用它的命名 webservice 可以体现出它想做的就是一个 long running，并且带 service 的这样一个组件，而 worker 同样是一个 long running 的，但它是一个 backend，它并不会有一些 network endpoint。
三、交付第一个应用
接下来可以交付第一个 KubeVela 应用。在这里提供了一个最简单的事例，
这样一个 application，它只有一个 components，而在 components 当中用的就是这样一个webservice 的类型。它所用的镜像是一个 hello-world 镜像，并且给它赋值上了 ingress，这里用的是 ingress-1-20，就是1.20版本的一个 ingress，可以查看目前机器里面有的一些traits，
目前集群中的 traits 还是比较多的，可以看到 ingress 分成了两个版本，一个是用于比较以前的一些版本，而 ingerss-1-20 主要是由于 K8S 1.20版本以后的 ingress 跟之前的差别比较大，所以在这里把两个 traits 分开来了，这里也解释到它主要是用于1.20以后版本的集群。
再次回顾 application，它其实是非常简单的 webservice 的应用，它可以附带了 ingress 的traits 之后，就可以通过 ingress 访问 component 的 webservice。可以用 vela up 的命令部署这个应用，
这里有一个 app.yaml，里面的内容跟之前演示的是一样的，可以通过 vela up 的命令部署这个应用。
Application 已经成功被部署了，可以通过 vela list 命令查看 application，
它的 phase 已经是 running，并且状态已经是 healthy 了，可以通过 vela status 查看 application 的具体状态，
在 vela status 中，它会把 application 的一些 traits 列出来，可以看到这是附带了 ingress 的一个 traits，由于现在用的并不是一个真实的域名，所以它会推荐使用 port-forward 的方式把 APP 展示出来，复制这个命令并且执行，
通过 port-forward 的命令，已经把 APP 映射到本地的8000端口了，这里是 hello-world 的页面，表示目前的这样一个应用已经被成功部署了。
也可以使用一个真实的域名，这里还放了 application v2版本，
可以用这个版本更新 V1版本的 vacation。Diff 这两个文件，
唯一的一个区别就是第二版本的 application，它的 Ingress 的域名是一个真实的域名。重新vela up，来更新这个 vacation，
这个 vacation 已经被更新完成了。重新使用 vela status，查看这个 app
可以看到它推荐已经可以使用真实的 URL 域名查看 application，
使用真实的域名之后，已经将 APP 成功部署了。
这就是最简单的 KubeVela 应用的状态，首先通过 vela up 部署这个应用，接着通过 vela list 查看集群中的所有应用，最后通过 vela status 查看应用的状态，并且可以查看它的 service。
由于之前已经启动了一个 fluxcd 的 addon，所以在这里可以使用 helm 部署第二个组件，
可以查看 wordpress application 的 yalm 文件，
可以看到它依旧是一个比较简单的 demo component 类型的 vacation，而它的 type 声明的是 helm 类型的。在它的 properties 里面会将 repoType 也声明为helm，并且 URL 指向的是 helm chart 的一个 URL，而它的 chart 名是在下面一个 chart 字段中声名的，version 指的是 chart version 的一个版本，在 values 里面填写的所有字段都会默认覆盖 helm chart 里面的 value。由于 wordpress 默认使用的是 load balance 类型的 service，而在 values 里面将 ingress 打开并且复制一个真实的域名。
在这里同样将 helm 类型的 application 部署到集群中，
通过 vela list 查看集群中的应用状态，
目前 wordpress 的状态仍旧是 runningworkflow，这是由于 helm 类型的应用需要拉取 helm chart 并且将它部署，会比之前的一些应用启动速度稍微慢一些。可以查看目前 pod 的状态，
Wordpress 会启动 mariadb 并且再去启动 wordpress 的 pod，而目前这些 pod 的状态仍旧在 con-creating 当中。
目前两个 pod 都已经成功启动起来了，再用 vela list 查看应用的状态，
应用的状态也已经变成了 running，而这个时候再去访问之前指定的域名，
可以看到这样一个 wordpress 的页面已经被成功部署。
再次回顾 KubeVela 的应用的基本结构，它是由 component 以及 traits 指定完成的。在 component 里面有一些默认的类型，像刚刚已经演示过的 webservice 以及 helm 类型，还有一些别的内置的 components 类型。而在这些内置的基础之上，KubeVela 真正强大的地方是可以让用户自定义 component 的 DeFinition，通过这种自定义且抽象的方式，可以让 KubeVela 的能力变得更为强大。而在已经提供了一些默认的 component DeFinition 的基础之上，还会有一个 traits，traits 是作为运维特征附属到 Component 里面，像在最开始的最简单的例子里面，实际上是将一个应用分成两个部分，一个属于应用的主体，另外一个属于应用的服务，这里特指一个 ingress，通过将应用主体以及运维特征分开来的方式，会使得整个 application 的结构更为清晰，也是 OAM 的主旨。而在这种结构体系下，不仅可以在 KubeVela 本身内置的一些 DeFinition 的基础之上构建应用，也可以达成更为抽象的方式自定义一些 component DeFinition 以及 traits DeFinition。
关于 KubeVela 部署以及第一个应用的部署的内容大致上就是这些，后面的课程会是更为进阶的一些内容，比如用户如何完成一些多级群的部署，以及灰度发布的部署，在上面是 KubeVela 更为高级的一些功能。
