版本:v1.6

垃圾回收

默认情况下,KubeVela 应用会在新的版本发布并健康运行后回收掉过时的资源。但是在一些场景下,你可能希望对于过时资源的回收有其他的控制方式,这种情况下你可以使用垃圾回收策略来配置相应的行为。

在垃圾回收策略中,目前主要有两种能力你可以使用。

如果你想要保留应用在先前版本中创建出来的资源,你可以配置垃圾回收策略中的keepLegacyResource选项来实现。比如如下应用:

  1. # app.yaml
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5. name: first-vela-app
  6. spec:
  7. components:
  8. - name: express-server
  9. type: webservice
  10. properties:
  11. image: oamdev/hello-world
  12. port: 8000
  13. traits:
  14. - type: ingress-1-20
  15. properties:
  16. domain: testsvc.example.com
  17. http:
  18. "/": 8000
  19. policies:
  20. - name: keep-legacy-resource
  21. type: garbage-collect
  22. properties:
  23. keepLegacyResource: true
  1. 首先创建这个应用
  1. vela up -f app.yaml
  1. $ vela ls
  2. APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
  3. first-vela-app express-server webservice ingress-1-20 running healthy Ready:1/1 2022-04-06 16:20:25 +0800 CST
  1. 然后更新它
  1. # app1.yaml
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5. name: first-vela-app
  6. spec:
  7. components:
  8. - name: express-server-1
  9. type: webservice
  10. properties:
  11. image: oamdev/hello-world
  12. port: 8000
  13. traits:
  14. - type: ingress-1-20
  15. properties:
  16. domain: testsvc.example.com
  17. http:
  18. "/": 8000
  19. policies:
  20. - name: keep-legacy-resource
  21. type: garbage-collect
  22. properties:
  23. keepLegacyResource: true
  1. vela up -f app1.yaml
  1. $ vela ls
  2. APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
  3. first-vela-app express-server-1 webservice ingress-1-20 running healthy Ready:1/1 2022-04-06 16:20:25 +0800 CST

可以发现旧版本的应用资源和新版本的应用资源同时存在于集群中。

在下述步骤中,我们将使用 kubectl 命令来做一些验证。你也可以使用 vela status first-vela-app 来检查应用及其组件的健康状态。

  1. $ kubectl get deploy
  2. NAME READY UP-TO-DATE AVAILABLE AGE
  3. express-server 1/1 1 1 10m
  4. express-server-1 1/1 1 1 40s
  1. $ kubectl get svc
  2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  3. express-server ClusterIP 10.96.102.249 <none> 8000/TCP 10m
  4. express-server-1 ClusterIP 10.96.146.10 <none> 8000/TCP 46s
  1. $ kubectl get ingress
  2. NAME CLASS HOSTS ADDRESS PORTS AGE
  3. express-server <none> testsvc.example.com 80 10m
  4. express-server-1 <none> testsvc.example.com 80 50s
  1. $ kubectl get resourcetracker
  2. NAME AGE
  3. first-vela-app-default 12m
  4. first-vela-app-v1-default 12m
  5. first-vela-app-v2-default 2m56s

在删除该应用时所有的版本资源会被一并回收。

  1. $ vela delete first-vela-app

如果你希望删除某个应用版本下的过时资源,你可以运行kubectl delete resourcetracker first-vela-app-v1-default

除了在整个应用维度上保留历史版本资源外,你还可以通过配置部分资源的持久化策略来跳过常规的垃圾回收过程。

在如下所示的样例中,添加了一条规则(rule)。该规则指定所有由expose这一运维特征创建出来的资源使用onAppDelete策略,即这些资源只有在应用删除时才会被回收。

  1. $ cat <<EOF | vela up -f -
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5. name: garbage-collect-app
  6. spec:
  7. components:
  8. - name: hello-world
  9. type: webservice
  10. properties:
  11. image: oamdev/hello-world
  12. traits:
  13. - type: expose
  14. properties:
  15. port: [8000]
  16. policies:
  17. - name: garbage-collect
  18. type: garbage-collect
  19. properties:
  20. rules:
  21. - selector:
  22. traitTypes:
  23. - expose
  24. strategy: onAppDelete
  25. EOF
  1. $ kubectl get deployment
  2. NAME READY UP-TO-DATE AVAILABLE AGE
  3. hello-world 1/1 1 1 74s
  4. $ kubectl get service
  5. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  6. hello-world ClusterIP 10.96.160.208 <none> 8000/TCP 78s

如果你升级该应用并使用一个新的组件,你会发现旧版本应用中通过 webservice 组件创建的 Deployment 被删除掉了,但是通过 expose 这一运维特征创建的 Service 资源仍然保留下来。

  1. $ cat <<EOF | vela up -f -
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5. name: garbage-collect-app
  6. spec:
  7. components:
  8. - name: hello-world-new
  9. type: webservice
  10. properties:
  11. image: oamdev/hello-world
  12. traits:
  13. - type: expose
  14. properties:
  15. port: [8000]
  16. policies:
  17. - name: garbage-collect
  18. type: garbage-collect
  19. properties:
  20. rules:
  21. - selector:
  22. traitTypes:
  23. - expose
  24. strategy: onAppDelete
  25. EOF
  26. $ kubectl get deployment
  27. NAME READY UP-TO-DATE AVAILABLE AGE
  28. hello-world-new 1/1 1 1 10s
  29. $ kubectl get service
  30. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  31. hello-world ClusterIP 10.96.160.208 <none> 8000/TCP 5m56s
  32. hello-world-new ClusterIP 10.96.20.4 <none> 8000/TCP 13s

如果你想要部署类 Job 组件,希望部署的资源不会被应用回收, 那么你可以使用组件组件类型选择器,同时将回收策略设置为 never

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: garbage-collect-app
  5. spec:
  6. components:
  7. - name: hello-world-new
  8. type: job-like-component
  9. policies:
  10. - name: garbage-collect
  11. type: garbage-collect
  12. properties:
  13. rules:
  14. - selector:
  15. componentTypes:
  16. - webservice
  17. strategy: never

另一种对于组件资源的选择方式是使用组件名称选择器。

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: create-ns-app
  5. spec:
  6. components:
  7. - name: example-addon-namespace
  8. type: k8s-objects
  9. properties:
  10. objects:
  11. - apiVersion: v1
  12. kind: Namespace
  13. policies:
  14. - name: garbage-collect
  15. type: garbage-collect
  16. properties:
  17. rules:
  18. - selector:
  19. componentNames:
  20. - example-addon-namespace
  21. strategy: never

如果你期望按照资源的依赖顺序删除资源,也可以使用本策略,添加 order: dependency 即可。

垃圾回收 - 图1备注

本策略只会按顺序删除在 Component 中声明的资源,在 Workflow 步骤中自定义创建的资源不包括。

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: gc-dependency
  5. namespace: default
  6. spec:
  7. components:
  8. - name: test1
  9. type: webservice
  10. properties:
  11. image: crccheck/hello-world
  12. port: 8000
  13. dependsOn:
  14. - "test2"
  15. - name: test2
  16. type: webservice
  17. properties:
  18. image: crccheck/hello-world
  19. port: 8000
  20. inputs:
  21. - from: test3-output
  22. parameterKey: test
  23. - name: test3
  24. type: webservice
  25. properties:
  26. image: crccheck/hello-world
  27. port: 8000
  28. outputs:
  29. - name: test3-output
  30. valueFrom: output.metadata.name
  31. policies:
  32. - name: gc-dependency
  33. type: garbage-collect
  34. properties:
  35. order: dependency

在上述例子中,我们有三个组件,依赖关系是 test1 依赖 test2test2 依赖 test3 的输出。

所以组件的部署顺序为:test3 -> test2 -> test1.

当我们在资源回收策略(garbage-collect)中指定 order: dependency 时,资源的删除顺序为: test1 -> test2 -> test3

Last updated on 2022年12月1日 by Somefive