Garbage Collect

By default, KubeVela Application will recycle outdated resources when new version is deployed and confirmed to be healthy. In some cases, you may want to have more customized control to the recycle of outdated resources, where you can leverage the garbage-collect policy.

In garbage-collect policy, there are two major capabilities you can use.

Suppose you want to keep the resources created by the old version of the application. Use the garbage-collect policy and enable the option keepLegacyResource.

  1. create app
  1. cat <<EOF | vela up -f -
  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: gateway
  15. properties:
  16. class: traefik
  17. domain: 47.251.8.82.nip.io
  18. http:
  19. "/": 8000
  20. policies:
  21. - name: keep-legacy-resource
  22. type: garbage-collect
  23. properties:
  24. keepLegacyResource: true
  25. EOF

Check the status:

  1. vela status first-vela-app --tree

expected output

  1. CLUSTER NAMESPACE RESOURCE STATUS
  2. local ─── default ─┬─ Service/express-server updated
  3. ├─ Deployment/express-server updated
  4. └─ Ingress/express-server updated
  1. update the app
  1. cat <<EOF | vela up -f -
  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: gateway
  15. properties:
  16. class: traefik
  17. domain: 47.251.8.82.nip.io
  18. http:
  19. "/": 8000
  20. policies:
  21. - name: keep-legacy-resource
  22. type: garbage-collect
  23. properties:
  24. keepLegacyResource: true
  25. EOF

Check the status again:

  1. vela status first-vela-app --tree

expected output

  1. CLUSTER NAMESPACE RESOURCE STATUS
  2. local ─── default ─┬─ Service/express-server outdated
  3. ├─ Service/express-server-1 updated
  4. ├─ Deployment/express-server outdated
  5. ├─ Deployment/express-server-1 updated
  6. ├─ Ingress/express-server outdated
  7. └─ Ingress/express-server-1 updated

You can see the legacy resources are reserved but the status is outdated, it will not be synced by periodically reconciliation.

  1. delete the app
  1. $ vela delete first-vela-app

If you hope to delete resources in one specified version, you can run kubectl delete resourcetracker first-vela-app-v1-default.

You can also persist part of the resources, which skips the normal garbage-collect process when the application is updated.

Take the following app as an example, in the garbage-collect policy, a rule is added which marks all the resources created by the expose trait to use the onAppDelete strategy. This will keep those services until application is deleted.

  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: demo-gc
  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

You can find deployment and service created.

  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

If you upgrade the application and use a different component, you will find the old versioned deployment is deleted but the service is kept.

  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

If you want to deploy job-like components, in which cases the resources in the component are not expected to be recycled even after the application is deleted, you can use the component type selector and set strategy to never as follows.

  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

An alternative selector for the component resources is the component name selector.

  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

If you want to garbage collect resources in the order of reverse dependency, you can add order: dependency in the garbage-collect policy.

Garbage Collect - 图1note

This delete in order feature is only available for the resources that created in the components. Custom Resources deployed in WorkflowStep will not be included.

  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

In the example above, component test1 depends on test2, and test2 need the output from test3.

So the creation order of deployment is: test3 -> test2 -> test1.

When we add order: dependency in garbage-collect policy and delete the application, the order of garbage collection is: test1 -> test2 -> test3.

Last updated on Feb 9, 2023 by dependabot[bot]