Version: v1.2

交付第一个应用

欢迎来到 KubeVela! 在本小节中,我们会向你介绍一些例子来帮助你理解如何使用 KubeVela 解决应用交付中的实际问题。

在实践之前,请确保你已经按照 快速安装 文档,在你的控制平面集群中安装了 KubeVela。

一个最简单的示例

KubeVela 中一个简单的应用部署定义,大致如下所示:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: first-vela-app
  5. spec:
  6. components:
  7. - name: express-server
  8. type: webservice
  9. properties:
  10. image: crccheck/hello-world
  11. port: 8000
  12. traits:
  13. - type: ingress-1-20
  14. properties:
  15. domain: testsvc.example.com
  16. http:
  17. "/": 8000

我们可以直接使用 kubectl 把它提交给 KubeVela:

  1. vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml

上述命令一旦执行,KubeVela 就会帮助你在目标集群中交付一个 Web 服务类型的组件,且该组件的容器镜像是crccheck/hello-world。在本示例中,我们并没有特别指明目标集群是哪个,所以 KubeVela 会默认把应用部署在它所在的集群也就是控制平面集群当中。

而由于我们已经在上述 YAML 文件中为这个组件绑定了一个 ingress 类型的运维特征,KubeVela 就会指导 Kubernetes 自动为这个组件背后的工作负载配置 Service、端口映射和 HTTP 路由规则。所以只要目标集群具备 Ingress 能力,上述 YAML 一部署成功,你就可以立刻通过外域名来问这个应用了。

  1. $ curl -H "Host:testsvc.example.com" http://<your ip address>/
  2. <xmp>
  3. Hello World
  4. ## .
  5. ## ## ## ==
  6. ## ## ## ## ## ===
  7. /""""""""""""""""\___/ ===
  8. ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
  9. \______ o _,/
  10. \ \ _,'
  11. `'--.._\..--''
  12. </xmp>

交付更多的组件

KubeVela 允许你部署的组件类型是非常丰富的。在上面的例子中,Web Service组件实际上就是一个预先编写好的CUE 文件。

你还可以选择其它很多类型,比如:

Helm 组件

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: app-delivering-chart
  5. spec:
  6. components:
  7. - name: redis-comp
  8. type: helm
  9. properties:
  10. chart: redis-cluster
  11. version: 6.2.7
  12. url: https://charts.bitnami.com/bitnami
  13. repoType: helm

Terraform 云资源组件

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: rds-cloud-source
  5. spec:
  6. components:
  7. - name: sample-db
  8. type: alibaba-rds
  9. properties:
  10. instance_name: sample-db
  11. account_name: oamtest
  12. password: U34rfwefwefffaked
  13. writeConnectionSecretToRef:
  14. name: db-conn

来自 Git 仓库的组件(基于 Kustomize)

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: git-app
  5. spec:
  6. components:
  7. - name: git-comp
  8. type: kustomize
  9. properties:
  10. repoType: git
  11. url: https://github.com/<path>/<to>/<repo>
  12. git:
  13. branch: master
  14. path: ./app/dev/

当然,还有更多。欢迎查看边栏中的选择待交付组件 章节来阅读关于部署各种类型的详细文档。如果你需要的话,你还可以在 KubeVela 中添加自己的组件类型。

绑定运维特征

KubeVela 能做的远不止部署,还包括运维。它允许你为待交付组件绑定预先定义好的各种运维行为(叫做运维特征),并且这个绑定会立刻生效。接下来,我们就为 Web 服务组件绑定一个“分批发布”运维特征:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: rollout-trait-test
  5. spec:
  6. components:
  7. - name: express-server
  8. type: webservice
  9. externalRevision: express-server-v1
  10. properties:
  11. image: stefanprodan/podinfo:4.0.3
  12. traits:
  13. - type: rollout
  14. properties:
  15. targetSize: 5
  16. rolloutBatches:
  17. - replicas: 2
  18. - replicas: 3

好了,接下来,只要上述 YAML 中的镜像版本发生变化,KubeVela 就会按照你所定义的分批策略来更新对应的应用实例了。

如果你想了解 KubeVela 所支持的所有运维特征,欢迎查看边栏中的 绑定运维特征 章节,同样的,KubeVela 允许你非常容易的在平台中添加自己的运维特征。

定义交付策略与交付工作流

组件与运维特征只是 KubeVela 非常基本的功能。KubeVela 本身实际上是一个全功能的持续交付(CD)系统,并且原生支持面向混合环境(比如混合云/多云/多集群)应用交付。

举个例子:

我要交付一个包括了两个组件的微服务应用,要求先需要在预发集群当中部署 1 个副本,然后暂停交付过程,请主管进行人工审核。当审核通过后,再继续部署到生产集群中,并且需要部署为3个副本。

想象一下,你需要在 CI/CD 流水线里编写多少“脏乱差”的一次性脚本或者胶水代码才能让上述流程自动化的、保证一定正确性的执行起来?

而在 KubeVela 中,上述流程可以非常容易的通过如下所示的声明式工作流建模出来:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: example-app
  5. namespace: default
  6. spec:
  7. components:
  8. - name: hello-world-server
  9. type: webservice
  10. properties:
  11. image: crccheck/hello-world
  12. port: 8000
  13. traits:
  14. - type: scaler
  15. properties:
  16. replicas: 1
  17. - name: data-worker
  18. type: worker
  19. properties:
  20. image: busybox
  21. cmd:
  22. - sleep
  23. - '1000000'
  24. policies:
  25. - name: example-multi-env-policy
  26. type: env-binding
  27. properties:
  28. envs:
  29. - name: staging
  30. placement: # selecting the cluster to deploy to
  31. clusterSelector:
  32. name: cluster-staging
  33. selector: # selecting which component to use
  34. components:
  35. - hello-world-server
  36. - name: prod
  37. placement:
  38. clusterSelector:
  39. name: cluster-prod
  40. patch: # overlay patch on above components
  41. components:
  42. - name: hello-world-server
  43. type: webservice
  44. traits:
  45. - type: scaler
  46. properties:
  47. replicas: 3
  48. - name: health-policy-demo
  49. type: health
  50. properties:
  51. probeInterval: 5
  52. probeTimeout: 10
  53. workflow:
  54. steps:
  55. # deploy to staging env
  56. - name: deploy-staging
  57. type: deploy2env
  58. properties:
  59. policy: example-multi-env-policy
  60. env: staging
  61. # manual check
  62. - name: manual-approval
  63. type: suspend
  64. # deploy to prod env
  65. - name: deploy-prod
  66. type: deploy2env
  67. properties:
  68. policy: example-multi-env-policy
  69. env: prod

不需要任何“脏乱差”脚本,KubeVela 就能够以完全自动化、高确定性的声明式工作流完成所有的应用交付动作。更为重要的是,KubeVela 希望你继续使用你现有的任何 CI 方案,而 KubeVela 则负责帮助你更好的完成 CD 流程。