版本:v1.8

一键创建/销毁环境

本章将介绍如何使用 KubeVela 在交付应用时对环境进行快速初始化和销毁。

一个应用开发团队通常需要做一些初始化工作来满足应用部署时方方面面的需要,即“初始化环境”。 这里的环境是一个逻辑概念,既可以表示应用部署时依赖的公共资源,也可以表示应用运行必要的准备工作。

KubeVela 可以使用 Application 对象做环境的初始化,可以初始化的资源类型包括但不限于下列类型:

  1. 一个或多个 Kubernetes 集群,不同的环境可能需要不同规模和不同版本的 Kubernetes 集群。同时环境初始化还可以将多个 Kubernetes 集群注册到一个中央集群进行统一的多集群管控。

  2. 任意类型的 Kubernetes 自定义资源(CRD)和系统插件,一个环境会拥有很多种不同的自定义资源来提供系统能力,比如不同的工作负载、不同的运维管理功能等等。初始化环境可以包含环境所依赖的一系列功能的初始化安装,比如各类中间件工作负载、流量管理、日志监控等各类运维系统。

  3. 各类共享资源和服务,一个微服务在不同环境中测试验证时,除了自身所开发的组件以外,往往还会包含一系列其他团队维护的组件和一些公共资源。环境初始化功能可以将其他组件和公共资源统一部署,在无需使用时销毁。这些共享资源可以是一个微服务组件、云数据库、缓存、负载均衡、API网关等等。

  4. 各类管理策略和流程,一个环境可能会配备不同的全局策略和流程,举例来说,环境策略可能会包括混沌测试、安全扫描、错误配置检测、SLO指标等等;而流程则可以是初始化一个数据库表、注册一个自动发现配置等。

不仅如此,KubeVela 的环境初始化能力还可以跟工作流、策略、依赖等功能相结合,做不同环境的差异化部署,依赖管理等。

若不同环境初始化存在依赖关系,可以初始化的公共资源分离出一个单独的 Application 作为依赖,这样可以形成可以被复用的初始化模块。 例如,测试环境和开发环境都依赖了一些相同的控制器,可以将这些控制器提取出来作为单独的环境初始化,在开发环境和测试环境中都指定依赖该环境初始化。

请确保你的 KubeVela 版本在 v1.1.6 及以上。

如果我们希望在环境中使用一个自定义 CRD 控制器(如 OpenKruise),那么,我们可以使用 Helm 组件初始化 kruise。

我们可以直接使用 KubeVela 的应用部署计划来初始化 kruise 的环境,该应用会帮你在集群中部署一个 OpenKruise 的控制器,给集群提供 kruise 的各种能力。

由于我们使用 Helm 组件完成 kruise 的部署,我们首先要在集群中使用 FluxCD 插件开启 helm 功能。 当环境初始化具备多个模块时,可以对初始化的内容进行拆分,同时使用工作流的 depends-on-app 步骤,描述不同初始化模块的依赖关系。 比如我们可以在这个例子里,使用 depends-on-app 表示环境初始化 kruise 依赖环境初始化 addon-fluxcd 提供的能力。同时,使用 apply-once 策略来确保资源只会部署一次来完成初始化。

depends-on-app 会根据 properties 中的 namenamespace,去查询集群中是否存在对应的应用。 如果应用存在,则当该应用的状态可用时,才会进行下一个步骤; 若该应用不存在,则会去查询同名的 configMap,从中读取出应用的配置并部署到集群中。 更详细的说明,请查看 depends-on-app

部署如下文件:

  1. cat <<EOF | vela up -f -
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5. name: kruise
  6. namespace: vela-system
  7. spec:
  8. components:
  9. - name: kruise
  10. type: helm
  11. properties:
  12. repoType: helm
  13. url: https://openkruise.github.io/charts/
  14. chart: kruise
  15. version: 1.2.0
  16. git:
  17. branch: master
  18. values:
  19. featureGates: PreDownloadImageForInPlaceUpdate=true
  20. policies:
  21. - name: apply-once
  22. type: apply-once
  23. properties:
  24. enable: true
  25. workflow:
  26. steps:
  27. - name: check-flux
  28. type: depends-on-app
  29. properties:
  30. name: addon-fluxcd
  31. namespace: vela-system
  32. - name: apply-kruise
  33. type: apply-component
  34. properties:
  35. component: kruise
  36. EOF

查看集群中应用的状态:

  1. vela status kruise -n vela-system

期望输出

  1. About:
  2. Name: kruise
  3. Namespace: vela-system
  4. Created at: 2022-10-31 18:10:27 +0800 CST
  5. Status: running
  6. Workflow:
  7. mode: StepByStep-DAG
  8. finished: true
  9. Suspend: false
  10. Terminated: false
  11. Steps
  12. - id: l6apfsi5c2
  13. name: check-flux
  14. type: depends-on-app
  15. phase: succeeded
  16. - id: p2nqell47w
  17. name: apply-kruise
  18. type: apply-component
  19. phase: succeeded
  20. Services:
  21. - Name: kruise
  22. Cluster: local Namespace: vela-system
  23. Type: helm
  24. Healthy Fetch repository successfully, Create helm release successfully
  25. No trait applied

kruise 已经成功运行!之后,你可以在环境中使用 kruise 的能力。如果需要配置新的环境初始化,也只需要类似的定义一个部署计划。

在环境中,一些通用的 ConfigMap / PVC 等资源是十分常用的。 如果你希望在部署应用前内置一些通用资源,可以在应用部署中加入初始化的工作流来完成。

KubeVela 提供了一个内置的工作流步骤 apply-object,可以直接在组件的 properties 字段中填写创建到环境中的原生 Kubernetes 资源。 这种在 Application 中直接填写 Kubernetes 原生资源的方式,可以避免编写多余的组件定义(ComponentDefinition)。

部署如下应用,初始化一个带有 ConfigMap / PVC 的环境。同时,部署两个组件,第一个组件会不断向 PVC 中写入数据,第二个组件会读取 PVC 中的数据:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: server-with-pvc-and-cm
  5. namespace: default
  6. spec:
  7. components:
  8. - name: log-gen-worker
  9. type: worker
  10. properties:
  11. image: busybox
  12. cmd:
  13. - /bin/sh
  14. - -c
  15. - >
  16. i=0;
  17. while true;
  18. do
  19. echo "$i: $(date)" >> /test-pvc/date.log;
  20. i=$((i+1));
  21. sleep 1;
  22. done
  23. volumes:
  24. - name: "my-pvc"
  25. type: "pvc"
  26. mountPath: "/test-pvc"
  27. claimName: "my-claim"
  28. - name: "my-configmap"
  29. type: "configMap"
  30. mountPath: "/test-cm"
  31. cmName: "my-cm"
  32. items:
  33. - key: test-key
  34. path: test-key
  35. - name: log-read-worker
  36. type: worker
  37. properties:
  38. name: count-log
  39. image: busybox
  40. cmd:
  41. - /bin/sh
  42. - -c
  43. - 'tail -n+1 -f /test-pvc/date.log'
  44. volumes:
  45. - name: "my-pvc"
  46. type: "pvc"
  47. mountPath: "/test-pvc"
  48. claimName: "my-claim"
  49. - name: "my-configmap"
  50. type: "configMap"
  51. mountPath: "/test-cm"
  52. cmName: "my-cm"
  53. items:
  54. - key: test-key
  55. path: test-key
  56. policies:
  57. - name: my-policy
  58. properties:
  59. clusters:
  60. - local
  61. type: topology
  62. - name: apply-once
  63. type: apply-once
  64. properties:
  65. enable: true
  66. workflow:
  67. steps:
  68. - name: apply-pvc
  69. type: apply-object
  70. properties:
  71. value:
  72. apiVersion: v1
  73. kind: PersistentVolumeClaim
  74. metadata:
  75. name: my-claim
  76. namespace: default
  77. spec:
  78. accessModes:
  79. - ReadWriteOnce
  80. resources:
  81. requests:
  82. storage: 8Gi
  83. storageClassName: standard
  84. - name: apply-cm
  85. type: apply-object
  86. properties:
  87. value:
  88. apiVersion: v1
  89. kind: ConfigMap
  90. metadata:
  91. name: my-cm
  92. namespace: default
  93. data:
  94. test-key: test-value
  95. - name: deploy-comp
  96. properties:
  97. policies:
  98. - my-policy
  99. type: deploy

查看集群中的 PVC 以及 ConfigMap:

  1. vela status server-with-pvc-and-cm --detail --tree

期望输出

  1. CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
  2. local ─── default ─┬─ ConfigMap/my-cm updated 2022-10-31 18:00:52 Data: 1 Age: 57s
  3. ├─ PersistentVolumeClaim/my-claim updated 2022-10-31 10:00:52 Status: Bound Volume: pvc-b6f88ada-af98-468d-8cdd-31ca110c5e1a Capacity: 8Gi Access Modes: RWO StorageClass: standard Age: 57s
  4. ├─ Deployment/log-gen-worker updated 2022-10-31 10:00:52 Ready: 1/1 Up-to-date: 1 Available: 1 Age: 57s
  5. └─ Deployment/log-read-worker updated 2022-10-31 10:00:52 Ready: 1/1 Up-to-date: 1 Available: 1 Age: 57s

查看集群中应用的状态:

  1. vela status server-with-pvc-and-cm

期望输出

  1. $ vela status server-with-pvc-and-cm
  2. About:
  3. Name: server-with-pvc-and-cm
  4. Namespace: default
  5. Created at: 2022-10-31 18:00:51 +0800 CST
  6. Status: running
  7. Workflow:
  8. mode: StepByStep-DAG
  9. finished: true
  10. Suspend: false
  11. Terminated: false
  12. Steps
  13. - id: xboizfjo28
  14. name: apply-pvc
  15. type: apply-object
  16. phase: succeeded
  17. - id: 4ngx25mrx8
  18. name: apply-cm
  19. type: apply-object
  20. phase: succeeded
  21. - id: 1gzzt3mfw1
  22. name: deploy-comp
  23. type: deploy
  24. phase: succeeded
  25. Services:
  26. - Name: log-gen-worker
  27. Cluster: local Namespace: default
  28. Type: worker
  29. Healthy Ready:1/1
  30. No trait applied
  31. - Name: log-read-worker
  32. Cluster: local Namespace: default
  33. Type: worker
  34. Healthy Ready:1/1
  35. No trait applied

检查第二个组件的日志输出:

  1. vela logs server-with-pvc-and-cm --component log-read-worker

期望输出

  1. + log-read-worker-7f4bc9d9b5-kb5l6 log-read-worker
  2. log-read-worker 2022-10-31T10:01:15.606903716Z 0: Mon Oct 31 10:01:13 UTC 2022
  3. log-read-worker 2022-10-31T10:01:15.606939383Z 1: Mon Oct 31 10:01:14 UTC 2022
  4. log-read-worker 2022-10-31T10:01:15.606941883Z 2: Mon Oct 31 10:01:15 UTC 2022
  5. log-read-worker 2022-10-31T10:01:16.607006425Z 3: Mon Oct 31 10:01:16 UTC 2022
  6. log-read-worker 2022-10-31T10:01:17.607184925Z 4: Mon Oct 31 10:01:17 UTC 2022
  7. log-read-worker 2022-10-31T10:01:18.607304426Z 5: Mon Oct 31 10:01:18 UTC 2022
  8. ...

可以看到,应用中的两个组件均已正常运行。同时,这两个组件共享同一个 PVC,并使用相同的 ConfigMap 进行配置。

因为我们已经通过应用(Application)这个统一的模型做了环境初始化,所以销毁环境变得非常简单,只需要删除这个应用即可。

  1. vela delete server-with-pvc-and-cm

KubeVela 控制器会自动将资源删除。

Last updated on 2023年5月6日 by Tianxin Dong