This procedure describes how to upgrade the Control-M/Agents that you deployed when you set up the previous version of Control-M for Kubernetes.
If you have multiple Agent deployed (as recommended), the deployed Agents are updated one by one without downtime.
Begin
Update the controlm repository that contains the Helm charts obtained from the Control-M Repository by running the following command:
helm repo update controlm
- Run the helm list command and identify the release that is currently running.
Run the helm upgrade command to upgrade to the newest Agent version, as in the following example:
helm upgrade <releaseName> controlm/controlm-agent --version 9.21.310 --set image.tag=9.21.310-k8s-openjdk <all other parameters from the original installation>
where <releaseName> is the name of the release that is currently running, as determined in the previous step.
helm upgrade <releaseName> controlm/controlm-agent --version 9.21.310 --set image.tag=9.21.310-k8s-openjdk \
--set server.name=LocalControlM --set server.host=controlm --set server.port=7005 --set server.ip=10.20.30.40 \
--set api.endpoint=https://controlm:8443/automation-api --set api.token=<apiToken> \
--set pvc.storageClass=efs-sc
Note
Alternatively, you can use the --reuse-values switch to reuse the values from the previous release, instead of including all other parameters that you used in your original installation, as in the following example:
helm upgrade <releaseName> controlm/controlm-agent --version 9.21.310 --set image.tag=9.21.310-k8s-openjdk --reuse-values
Before upgrade starts, requirements are verified, including whether the Agent image version matches the Helm chart version and whether the Control-M Automation API version is equal to or above the minimum required. If you receive an error, see Troubleshooting-and-Messages.
The upgrade is performed in the background. This might take several minutes.
- Monitor the status of the rollout by running the following command:
kubectl rollout status statefulset/<releaseName>-sts
Note
If you need to roll back the upgrade, do the following:
- In each Agent pod, run one of the following commands:
- If you are rolling back to the BMC-provided image, which contained Java version 17:
ctmcfg -TABLE CONFIG -ACTION UPDATE -PARAMETER AG_JAVA_HOME -value /etc/alternatives/jre_17_openjdk
If you are rolling back to an image that you created with your own external Java:
ctmcfg -TABLE CONFIG -ACTION UPDATE -PARAMETER AG_JAVA_HOME -value <path to previous Java>
You are using an image that you created with your own external Java. During the creation of this image, you set the Java path to /etc/alternatives/java_sdk. You now specify that Java path in the rollback:
ctmcfg -TABLE CONFIG -ACTION UPDATE -PARAMETER AG_JAVA_HOME -value /etc/alternatives/java_sdk
For more information, see Creating-a-Container-Image-with-External-Java.
- Use the helm history command to check which revision of the Helm chart you want to roll back to, as in the following example:
helm history controlm-agent - Run the helm rollback command, with the following syntax:
helm rollback <releaseName> [revisionNumber]