Version 1.2.0+ of VMware Tanzu RabbitMQ for Kubernetes leverages the kapp-controller framework to allow for easy installation and management of the RabbitMQ operators and OCI images. If you are upgrading to version 1.2.0+ from any version 1.1.*, complete the following procedures.
The following procedures assume the following is in place:
kubectl are installedkapp deploy -a kc -y -f https://github.com/vmware-tanzu/carvel-kapp-controller/releases/latest/download/release.yml
kapp deploy -a sg -y -f https://github.com/vmware-tanzu/carvel-secretgen-controller/releases/latest/download/release.yml
kapp deploy -a cert-manager -y -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml
The steps to upgrade using the bundle consists of the following procedures:
If you are planning on deploying VMware Tanzu RabbitMQ for Kubernetes to a Kubernetes cluster on an airgapped network, you must first follow the instructions on the kapp-controller docs to relocate the package registry.tanzu.vmware.com/p-rabbitmq-for-kubernetes/tanzu-rabbitmq-package-repo to your internal registry. In the following instructions, you should use the URL of your registry in place of any references to registry.tanzu.vmware.com.
This upgrade process will upgrade the Cluster Operator and the Topology Operator while installing the new Standby Replication Operator. RabbitMQ instances will not be upgraded in this procedure. RabbitMQ instances can be upgraded in a separate procedure, and as needed.
Note: When you upgrade the rabbitmq-cluster-operator, you are updating the RabbitMQ clusters which causes a rolling update of the underlying StatefulSets. If you want to control when a RabbitMQ cluster gets updated, ensure to pause reconciliation before upgrading the rabbitmq-cluster-operator. After the `rabbitmq-cluster-operator upgrade is complete, resume reconciliation whenever it is safe to update the RabbitMQ cluster.
To upgrade Tanzu RabbitMQ, follow this procedure:
Check the existing Operators, make sure they are running.
kapp -n default inspect -a rabbitmq-operator
# [...]
# rabbitmq-system messaging-topology-leader-election-role Role kapp - ok - 9d
# ^ messaging-topology-leader-election-rolebinding RoleBinding kapp - ok - 9d
# ^ messaging-topology-operator Deployment kapp 2/2 t ok - 9d
# ^ messaging-topology-operator ServiceAccount kapp - ok - 9d
# ^ messaging-topology-operator-59c887bf9b ReplicaSet cluster - ok - 2d
# ^ messaging-topology-operator-59c887bf9b-zntdg Pod cluster 4/4 t ok - 2d
# ^ messaging-topology-operator-7df4b4c88b ReplicaSet cluster - ok - 9d
# ^ messaging-topology-operator-b5c8bdd5f ReplicaSet cluster - ok - 9d
# ^ rabbitmq-cluster-leader-election-role Role kapp - ok - 9d
# ^ rabbitmq-cluster-leader-election-rolebinding RoleBinding kapp - ok - 9d
# ^ rabbitmq-cluster-operator Deployment kapp 2/2 t ok - 9d
# ^ rabbitmq-cluster-operator ServiceAccount kapp - ok - 9d
# ^ rabbitmq-cluster-operator-5688599bc9 ReplicaSet cluster - ok - 9d
# ^ rabbitmq-cluster-operator-5c479456b ReplicaSet cluster - ok - 2d
# ^ rabbitmq-cluster-operator-5c479456b-n4jxb Pod cluster 4/4 t ok - 2d
# ^ rabbitmq-cluster-operator-6f87c7bbf8 ReplicaSet cluster - ok - 9d
# [...]
Rename the existing deployment containing the operators to tanzu-rabbitmq-ctrl:
kapp rename -a rabbitmq-operator --new-name tanzu-rabbitmq-ctrl -y
Follow the instructions under the Setup section of the installation guide. Important: If you are upgrading from version 1.1.0 only to 1.2.0, the PackageInstall manifest you use in those instructions must be as follows:
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageInstall
metadata:
name: tanzu-rabbitmq
spec:
serviceAccountName: ${SERVICE_ACCOUNT} # Replace with service account name
packageRef:
refName: rabbitmq.tanzu.vmware.com
versionSelection:
constraints: 1.2.0
values:
- secretRef:
name: tanzu-rabbitmq-values
---
apiVersion: v1
kind: Secret
metadata:
name: tanzu-rabbitmq-values
stringData:
values.yml: |
---
upgrade110To120: true
kapp inspect -a tanzu-rabbitmq-ctrl to verify everything is running and all conditions (Conds column) are true. It should look similar to this:# [...]
# rabbitmq-system messaging-topology-leader-election-role Role kapp - ok - 9d
# ^ messaging-topology-leader-election-rolebinding RoleBinding kapp - ok - 9d
# ^ messaging-topology-operator Deployment kapp 2/2 t ok - 11s
# ^ messaging-topology-operator ServiceAccount kapp - ok - 9d
# ^ messaging-topology-operator-59c887bf9b ReplicaSet cluster - ok - 11s
# ^ messaging-topology-operator-59c887bf9b-24z29 Pod cluster 4/4 t ok - 11s
# ^ rabbitmq-cluster-leader-election-role Role kapp - ok - 9d
# ^ rabbitmq-cluster-leader-election-rolebinding RoleBinding kapp - ok - 9d
# ^ rabbitmq-cluster-operator Deployment kapp 2/2 t ok - 11s
# ^ rabbitmq-cluster-operator ServiceAccount kapp - ok - 9d
# ^ rabbitmq-cluster-operator-5c479456b ReplicaSet cluster - ok - 11s
# ^ rabbitmq-cluster-operator-5c479456b-lwsxf Pod cluster 4/4 t ok - 11s
# [...]
At this point, the operator upgrades should now be complete.
The following procedure documents how to upgrade individual RabbitMQ instances. Please note that this procedure will restart RabbitMQ in a rolling strategy; in other words, it will restart one RabbitMQ Pod at a time.
kubectl edit rmq my-tanzu-rabbit
# Replace 'my-tanzu-rabbit' with the name of your RabbitMQ cluster
image: in the spec and save & exit the file: [...]
spec:
image: dev.registry.pivotal.io/rabbitmq/vmware-tanzu-rabbitmq:1.1.1 # Remove this line
[...]
This will reset the image of the RabbitmqCluster to the default of the operator, which will be the uplevel version of Tanzu RabbitMQ. This will trigger the rolling upgrade of your cluster.
