Upgrade Calico Enterprise installed with Helm

note

All upgrades in Calico Enterprise are free with a valid license.

Prerequisites

• Verify that your Kubernetes cluster is using Helm

  kubectl get tigerastatus

  If the result is successful, then your installation is using Helm.

Prepare your cluster for the upgrade

During the upgrade the controller that manages Elasticsearch is updated. Because of this, the Calico Enterprise LogStorage CR is temporarily removed during upgrade. Features that depend on LogStorage are temporarily unavailable, among which are the dashboards in the Manager UI. Data ingestion is temporarily paused and will continue when the LogStorage is up and running again.

To retain data from your current installation (optional), ensure that the currently mounted persistent volumes have their reclaim policy set to retain data. Retaining data is only recommended for users that use a valid Elastic license. Trial licenses can get invalidated during the upgrade.

If your cluster has Windows nodes and uses custom TLS certificates for log storage then, prior to upgrade, prepare and apply new certificates for log storage that include the required service DNS names.

Upgrade OwnerReferences

If you do not use OwnerReferences on resources in the projectcalico.org/v3 API group, you can skip this section.

Starting in Calico Enterprise v3.19, a change in the way UIDs are generated for projectcalico.org/v3 resources requires that you update any OwnerReferences that refer to projectcalico.org/v3 resources as an owner. After upgrade, the UID for all projectcalico.org/v3 resources will be changed, resulting in any owned resources being garbage collected by Kubernetes.

1. Remove any OwnerReferences from resources in your cluster that have apiGroup: projectcalico.org/v3.
2. Perform the upgrade normally.
3. Add new OwnerReferences to your resources referencing the new UID.

Default Deny

Calico Enterprise creates a default-deny for the calico-system namespace. If you deploy workloads into the calico-system namespace, you must create policy that allows the required traffic for your workloads prior to upgrade.

Upgrade from 3.17 or later

note

These steps differ based on your cluster type. If you are unsure of your cluster type, look at the field clusterManagementType when you run kubectl get installation -o yaml before you proceed.

1. Get the Helm chart

   curl -O -L https://downloads.tigera.io/ee/charts/tigera-operator-v3.19.4-0.tgz

2. Install the Calico Enterprise custom resource definitions.

   kubectl apply --server-side --force-conflicts -f https://downloads.tigera.io/ee/v3.19.4/manifests/operator-crds.yaml
   kubectl apply --server-side --force-conflicts -f https://downloads.tigera.io/ee/v3.19.4/manifests/prometheus-operator-crds.yaml
   kubectl apply --server-side --force-conflicts -f https://downloads.tigera.io/ee/v3.19.4/manifests/eck-operator-crds.yaml

3. Run the Helm upgrade command for tigera-operator and make sure to either update values.yaml with your configuration or use custom values.yaml file:

helm upgrade calico-enterprise --values=<path-to-values-yaml> tigera-operator-v3.19.4-0.tgz \
--set-file imagePullSecrets.tigera-pull-secret=<path-to-pull-secret>,tigera-prometheus-operator.imagePullSecrets.tigera-pull-secret=<path-to-pull-secret> \
--set-file licenseKeyContent=<path-to-license-file-yaml> \
--namespace tigera-operator

note

If you previously upgraded from open source to enterprise, your installation name will be calico. Substitute the command above with helm upgrade calico ... instead.

1. You can monitor progress with the following command:

 watch kubectl get tigerastatus

note

Make sure you have the CNI Type defined in your values.yaml file, especially if it is different from the default CNI type. If there are any problems you can use kubectl get tigerastatus -o yaml to get more details.