---
title: "Upgrade Calico Enterprise installed with the operator"
description: "Upgrading from an earlier release of Calico Enterprise with the operator."
product: "Calico Enterprise"
version: "3.21"
section: "Install and upgrade"
canonical_url: "https://docs.tigera.io/calico-enterprise/3.21/getting-started/upgrading/upgrading-enterprise/kubernetes-upgrade-tsee/operator"
---

# Upgrade Calico Enterprise installed with the operator

> **SECONDARY:** All upgrades in Calico Enterprise are free with a valid license.

## Upgrades paths

You can upgrade your cluster to a maximum of **two releases** from your existing version. For example, if you are on version 3.16, you can upgrade to 3.17, or you can upgrade directly to 3.18. However, you cannot upgrade beyond **two releases**; upgrading from 3.16 to 3.19 (three releases) is not supported.

If you are several versions behind where you want to be, you must go through each group of two releases to get there. For example, if you are on version 3.16, and you want to get to 3.20, you can upgrade to 3.18, then upgrade from 3.18 directly to 3.20.

> **SECONDARY:** Always check the [Release Notes](https://docs.tigera.io/calico-enterprise/3.21/release-notes.md) for exceptions; limitations can override the above pattern.

## Prerequisites

Verify that your Kubernetes cluster is using a version of Calico Enterprise installed with the operator, by running `kubectl get tigerastatus`. If the result is successful, then your installation is using the operator.

If your cluster has a Calico installation, contact Tigera support to upgrade.

## 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 web console. 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](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/). Retaining data is only recommended for users that use a valid Elastic license. Trial licenses can get invalidated during the upgrade.

### 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.

### Windows

If your cluster has Windows nodes and uses custom TLS certificates for log storage, prior to upgrade, prepare and apply new certificates for [log storage](https://docs.tigera.io/calico-enterprise/3.21/operations/comms/log-storage-tls.md) that include the required service DNS names.

For AKS only, upgrades to a newer version will automatically upgrade Calico Enterprise for Windows. During the upgrade, Windows nodes will be tainted so new pods will not be scheduled until the upgrade of the node has finished. The Calico Enterprise for Windows upgrade status can be monitored with: `kubectl get tigerastatus calico -oyaml`.

### Multi-cluster management

For Calico Enterprise, upgrading multi-cluster management setups must include updating all managed and management clusters.

> **SECONDARY:** 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.

## Upgrade Calico Enterprise

<!-- tabs -->

**Tab: Kubernetes**

1. Download the new manifests for Tigera Operator.

   ```bash
   curl -L -O https://downloads.tigera.io/ee/v3.21.9/manifests/tigera-operator.yaml
   ```

2. Download the new manifests for Prometheus operator.

   > **SECONDARY:**
   >
   > If you have an existing Prometheus operator in your cluster that you want to use, skip this step. To work with Calico Enterprise, your Prometheus operator must be v0.40.0 or higher.

   ```bash
   curl -L -O https://downloads.tigera.io/ee/v3.21.9/manifests/tigera-prometheus-operator.yaml
   ```

3. If you previously [installed using a private registry](https://docs.tigera.io/calico-enterprise/3.21/getting-started/install-on-clusters/private-registry.md), you will need to [push the new images ](https://docs.tigera.io/calico-enterprise/3.21/getting-started/install-on-clusters/private-registry/private-registry-regular.md#push-calico-enterprise-images-to-your-private-registry)and then [update the manifest](https://docs.tigera.io/calico-enterprise/3.21/getting-started/install-on-clusters/private-registry/private-registry-regular.md#run-the-operator-using-images-from-your-private-registry) downloaded in the previous step.

4. Apply the manifest for Tigera Operator.

   ```bash
   kubectl apply --server-side --force-conflicts -f tigera-operator.yaml
   ```

   > **SECONDARY:**
   >
   > If you intend to update any
   >
   > `operator.tigera.io`
   >
   >  or
   >
   > `projectcalico.org`
   >
   >  resources to utilize new fields available in the update you must make sure you make those changes after applying the
   >
   > `tigera-operator.yaml`
   >
   > .

5. If you downloaded the manifests for Prometheus operator from the earlier step, then apply them now.

   ```bash
   kubectl apply --server-side --force-conflicts -f tigera-prometheus-operator.yaml
   ```

6. If your cluster has OIDC login configured, follow these steps:

   a. Save a copy of your Manager for reference.

   ```bash
   kubectl get manager tigera-secure -o yaml > manager.yaml
   ```

   b. Remove the deprecated fields from your Manager resource.

   ```bash
   kubectl patch manager tigera-secure --type merge -p '{"spec": null}'
   ```

   c. If you are currently using v3.2 and are using OIDC with Kibana verify that you have the following resources in your cluster:

   ```bash
   kubectl get authentication tigera-secure
   kubectl get secret tigera-oidc-credentials -n tigera-operator
   ```

   If both of these resources are present, you can continue with the next step. Otherwise, use the instructions to [configure an identity provider](https://docs.tigera.io/calico-enterprise/3.21/operations/cnx/configure-identity-provider.md) to configure OIDC.

   d. Follow [configure an identity provider](https://docs.tigera.io/calico-enterprise/3.21/operations/cnx/configure-identity-provider.md).

7. If your cluster is a management cluster using v3.1 or older, apply a [ManagementCluster ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#managementcluster)CR to your cluster.

   ```bash
   kubectl apply -f - <<EOF
   apiVersion: operator.tigera.io/v1
   kind: ManagementCluster
   metadata:
     name: tigera-secure
   EOF
   ```

8. If your cluster is v3.7 or older, apply a new [Monitor ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#monitor)CR to your cluster.

   ```bash
   kubectl apply -f - <<EOF
   apiVersion: operator.tigera.io/v1
   kind: Monitor
   metadata:
     name: tigera-secure
   EOF
   ```

9. If your cluster is v3.16 or older, apply a new [PolicyRecommendation ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#policyrecommendation)CR to your cluster.

   ```bash
   kubectl apply -f - <<EOF
   apiVersion: operator.tigera.io/v1
   kind: PolicyRecommendation
   metadata:
     name: tigera-secure
   EOF
   ```

10. If your cluster is v3.19 or older, apply a new [PacketCaptureAPI ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#packetcaptureapi)CR to your cluster.

    ```bash
    kubectl apply -f - <<EOF
    apiVersion: operator.tigera.io/v1
    kind: PacketCaptureAPI
    metadata:
      name: tigera-secure
    EOF
    ```

11. You can monitor progress with the following command:

    ```bash
    watch kubectl get tigerastatus
    ```

    > **SECONDARY:**
    >
    > If there are any problems you can use
    >
    > `kubectl get tigerastatus -o yaml`
    >
    >  to get more details.

12. If your cluster includes egress gateways, follow the [egress gateway upgrade instructions](https://docs.tigera.io/calico-enterprise/3.21/networking/egress/egress-gateway-on-prem.md#upgrading-egress-gateways).

**Tab: AKS**

> **SECONDARY:** If Calico Enterprise was installed directly onto the AKS cluster, follow the upgrade instructions in the **Kubernetes** tab.

These AKS upgrade instructions apply only to AKS clusters which were upgraded to Calico Enterprise from Calico. Check whether the cluster was upgraded from Calico by checking the namespace for the active operator:

```bash
kubectl get configmap -n calico-system active-operator -oyaml | grep active-namespace
```

If the `active-namespace` is `tigera-operator-enterprise`, then the cluster was upgraded from Calico.

1. Download the new manifests for Tigera Operator.

   ```bash
   curl -L -o tigera-operator.yaml https://downloads.tigera.io/ee/v3.21.9/manifests/aks/tigera-operator-upgrade.yaml
   ```

2. Download the new manifests for Prometheus operator.

   > **SECONDARY:**
   >
   > If you have an existing Prometheus operator in your cluster that you want to use, skip this step. To work with Calico Enterprise, your Prometheus operator must be v0.40.0 or higher.

   ```bash
   curl -L -O https://downloads.tigera.io/ee/v3.21.9/manifests/tigera-prometheus-operator.yaml
   ```

3. If you previously [installed using a private registry](https://docs.tigera.io/calico-enterprise/3.21/getting-started/install-on-clusters/private-registry.md), you will need to [push the new images ](https://docs.tigera.io/calico-enterprise/3.21/getting-started/install-on-clusters/private-registry/private-registry-regular.md#push-calico-enterprise-images-to-your-private-registry)and then [update the manifest](https://docs.tigera.io/calico-enterprise/3.21/getting-started/install-on-clusters/private-registry/private-registry-regular.md#run-the-operator-using-images-from-your-private-registry) downloaded in the previous step.

4. Apply the manifest for Tigera Operator.

   ```bash
   kubectl apply --server-side --force-conflicts -f tigera-operator.yaml
   ```

   > **SECONDARY:**
   >
   > If you intend to update any
   >
   > `operator.tigera.io`
   >
   >  or
   >
   > `projectcalico.org`
   >
   >  resources to utilize new fields available in the update you must make sure you make those changes after applying the
   >
   > `tigera-operator.yaml`
   >
   > .

5. If you downloaded the manifests for Prometheus operator from the earlier step, then apply them now.

   ```bash
   kubectl apply --server-side --force-conflicts -f tigera-prometheus-operator.yaml
   ```

6. If your cluster has OIDC login configured, follow these steps:

   a. Save a copy of your Manager for reference.

   ```bash
   kubectl get manager tigera-secure -o yaml > manager.yaml
   ```

   b. Remove the deprecated fields from your Manager resource.

   ```bash
   kubectl patch manager tigera-secure --type merge -p '{"spec": null}'
   ```

   c. If you are currently using v3.2 and are using OIDC with Kibana verify that you have the following resources in your cluster:

   ```bash
   kubectl get authentication tigera-secure
   kubectl get secret tigera-oidc-credentials -n tigera-operator
   ```

   If both of these resources are present, you can continue with the next step. Otherwise, use the instructions to [configure an identity provider](https://docs.tigera.io/calico-enterprise/3.21/operations/cnx/configure-identity-provider.md) to configure OIDC.

   d. Follow [configure an identity provider](https://docs.tigera.io/calico-enterprise/3.21/operations/cnx/configure-identity-provider.md).

7. If your cluster is a management cluster using v3.1 or older, apply a [ManagementCluster ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#managementcluster)CR to your cluster.

   ```bash
   kubectl apply -f - <<EOF
   apiVersion: operator.tigera.io/v1
   kind: ManagementCluster
   metadata:
     name: tigera-secure
   EOF
   ```

8. If your cluster is v3.7 or older, apply a new [Monitor ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#monitor)CR to your cluster.

   ```bash
   kubectl apply -f - <<EOF
   apiVersion: operator.tigera.io/v1
   kind: Monitor
   metadata:
     name: tigera-secure
   EOF
   ```

9. If your cluster is v3.16 or older, apply a new [PolicyRecommendation ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#policyrecommendation)CR to your cluster.

   ```bash
   kubectl apply -f - <<EOF
   apiVersion: operator.tigera.io/v1
   kind: PolicyRecommendation
   metadata:
     name: tigera-secure
   EOF
   ```

10. If your cluster is v3.19 or older, apply a new [PacketCaptureAPI ](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#packetcaptureapi)CR to your cluster.

    ```bash
    kubectl apply -f - <<EOF
    apiVersion: operator.tigera.io/v1
    kind: PacketCaptureAPI
    metadata:
      name: tigera-secure
    EOF
    ```

11. You can monitor progress with the following command:

    ```bash
    watch kubectl get tigerastatus
    ```

    > **SECONDARY:**
    >
    > If there are any problems you can use
    >
    > `kubectl get tigerastatus -o yaml`
    >
    >  to get more details.

12. If your cluster includes egress gateways, follow the [egress gateway upgrade instructions](https://docs.tigera.io/calico-enterprise/3.21/networking/egress/egress-gateway-on-prem.md#upgrading-egress-gateways).

<!-- /tabs -->