How to limit the number of deployment on Run cluster in TAP v1.5

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

For TAP, Run cluster will increase deployment with every new version of the workload. Example as below:

kubectl get deployments
NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
tanzu-java-web-app-test-00006-deployment   0/0     0            0           5d18h
tanzu-java-web-app-test-00007-deployment   0/0     0            0           10h
tanzu-java-web-app-test-00008-deployment   0/0     0            0           10h
tanzu-java-web-app-test-00009-deployment   0/0     0            0           10h
tanzu-java-web-app-test-00010-deployment   0/0     0            0           8h
tanzu-java-web-app-test-00011-deployment   0/0     0            0           8h

Customer want to know how to limit the number of deployment in TAP v1.5.x.

Environment

Product Version: 1.5

Resolution

Assuming these deployments are for web workloads, then they are related to the Knative Revisions created with every new version of the workload. This can be setup through configmap config-gc in knative-serving namespace. Related documentation can be found here: https://knative.dev/docs/serving/revisions/revision-admin-config-options/#garbage-collection.

In order to customize the configuration, we need to use overlays in TAP. Steps as below:

Step 1. Create a file overlay-gc-cm.yml with the following content and apply it to the cluster.

apiVersion: v1
kind: Secret
metadata:
  name: cnr-overlay-gc-cm
  namespace: tap-install #! namespace where tap is installed
stringData:
  overlay-gc-cm.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ConfigMap","metadata":{"name":"config-gc"}})
    ---
    data:
      #@overlay/match missing_ok=True
      retain-since-create-time: "48h"
      #@overlay/match missing_ok=True
      retain-since-last-active-time: "15h"
      #@overlay/match missing_ok=True
      min-non-active-revisions: "2"
      #@overlay/match missing_ok=True
      max-non-active-revisions: "5"

Note: You may customized the parameters per your needs. The description of these parameters can be found here: https://knative.dev/docs/serving/revisions/revision-admin-config-options/#garbage-collection.

Step 2. Update your tap-values.yaml file to add the snippet as below:

package_overlays:
  - name: cnrs
    secrets:
      - name: cnr-overlay-gc-cm

Then, update the Tanzu Application Platform installation with below command:

tanzu package installed update tap -p tap.tanzu.vmware.com -v ${TAP_VERSION} --values-file tap-values.yaml -n tap-install

Step 3. Delete the configmap config-gc in order that kapp-controller accepts the change:

kubectl delete configmap config-gc --namespace knative-serving

Note: It will take at least 10 minutes for new configmap to be created. The reason for Step 3 due to known issue Issue with ConfigMap changes via overlays . 

Step 4. To check the overlay was applied correctly you can run below commands:

kubectl get configmap config-gc --namespace knative-serving --output jsonpath="{.data.retain-since-create-time}"
kubectl get configmap config-gc --namespace knative-serving --output jsonpath="{.data.retain-since-last-active-time}"
kubectl get configmap config-gc --namespace knative-serving --output jsonpath="{.data.min-non-active-revisions}"
kubectl get configmap config-gc --namespace knative-serving --output jsonpath="{.data.max-non-active-revisions}"

Step 5. Check the current revisions of apps:

kubectl get revisions -n <workload-namespace>

Note: It will take some time for Knative garbage collection to automatically cleaned up the inactive revisions of a Knative Service.