tigera · ctauchen · Nov 20, 2024 · Nov 19, 2024 · Nov 19, 2024 · Nov 19, 2024
@@ -18,7 +18,7 @@ Determine the right install method for your deployment, how to customize your in
 
 ### API-driven installation
 
-Starting in release v3.0, $[prodname] API-driven installation is the only supported installation method. The Tigera operator APIs (**operator.tigera.io**), let you define a $[prodname] cluster using declarative states. The APIs in the operator.tigera.io group define the desired state for your installation, and provide status reporting and visibility into the health of $[prodname]. The Tigera operator makes sure the cluster’s state matches your desired state. These APIs can be configured at install-time, and can also be modified on a running cluster to adjust configuration.
+The Tigera operator APIs (**operator.tigera.io**), let you define a $[prodname] cluster using declarative states. The APIs in the operator.tigera.io group define the desired state for your installation, and provide status reporting and visibility into the health of $[prodname]. The Tigera operator makes sure the cluster’s state matches your desired state. These APIs can be configured at install-time, and can also be modified on a running cluster to adjust configuration.
 
 ### Available APIs
 

@@ -3,13 +3,13 @@ description: Review requirements for using OpenShift with Calico Enterprise.
 ---
 
 import ReqsSys from "@site/calico-enterprise/_includes/components/ReqsSys";
-import ReqsKernel from '@site/calico-enterprise/_includes/components/ReqsSys';
+import ReqsKernel from '@site/calico-enterprise/_includes/components/ReqsKernel';
 
 # System requirements
 
 ## OpenShift requirements
 
-See [OpenShift Container Platform](https://docs.openshift.com/container-platform/4.6/welcome/index.html).
+See [OpenShift Container Platform](https://docs.openshift.com/container-platform/4.15/welcome/index.html).
 
 <ReqsSys orch='OpenShift' />
 

@@ -3,7 +3,7 @@ description: Review requirements to install Calico Enterprise networking and net
 ---
 
 import ReqsSys from "@site/calico-enterprise/_includes/components/ReqsSys";
-import ReqsKernel from '@site/calico-enterprise/_includes/components/ReqsSys';
+import ReqsKernel from '@site/calico-enterprise/_includes/components/ReqsKernel';
 
 # System requirements
 

@@ -30,7 +30,7 @@ The following table summarizes the networking options and considerations.
 
 | Networking         | Components                                                                                  | **Value/Content**                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
 | ------------------ | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| $[prodname] BGP   | Windows CNI plugin:<br /><br />calico.exe<br /><br />Linux: $[prodname] for policy and networking      | $[prodname]'s native networking approach, supports:<br/>- Auto-configured node-to-node BGP mesh over an L2 fabric<br/>- Peering with external routers for an L3 fabric<br/>- $[prodname] IPAM and IP aggregation (with some limitations)<br/>- Route reflectors (including the new in-cluster route reflector introduced in $[prodname] v3.3). **Note**: Windows node cannot act as route reflectors.<br/>- Kubernetes API datastore driver<br/><br />**AWS users**: If running on AWS, you must disable the source/dest check on your EC2 instances so that hosts can forward traffic on behalf of pods. |
+| $[prodname] BGP   | Windows CNI plugin:<br /><br />calico.exe<br /><br />Linux: $[prodname] for policy and networking      | $[prodname]'s native networking approach, supports:<br/>- Auto-configured node-to-node BGP mesh over an L2 fabric<br/>- Peering with external routers for an L3 fabric<br/>- $[prodname] IPAM and IP aggregation (with some limitations)<br/>- Route reflectors **Note**: Windows node cannot act as route reflectors.<br/>- Kubernetes API datastore driver<br/><br />**AWS users**: If running on AWS, you must disable the source/dest check on your EC2 instances so that hosts can forward traffic on behalf of pods. |
 | $[prodname] VXLAN | Windows CNI plugin:<br/>calico.exe<br /><br />Linux: $[prodname] for policy and networking | $[prodname]'s VXLAN overlay, supports:<br/><br />- VXLAN overlay, which can traverse most networks.<br/>- Auto-configured node-to-node routing<br/>- $[prodname] IPAM and IP aggregation (with some limitations)<br/>- Kubernetes API datastore driver<br/>**Note**: VXLAN runs on UDP port 4789 (this is the only port supported by Windows), remember to open that port between your $[prodname] hosts in any firewalls / security groups.                                                                                                                                                              |
 | Cloud provider     | Windows CNI plugin: win-bridge.exe<br /><br />Linux: $[prodname] policy-only               | A useful fallback, particularly if you have a Kubernetes cloud provider that automatically installs inter-host routes. $[prodname] has been tested with the standard **win-bridge.exe** CNI plugin so it should work with any networking provider that ultimately uses win-bridge.exe to network the pod (such as the Azure CNI plugin and cloud provider).                                                                                                                                                                                                                                                 |
 

@@ -12,10 +12,6 @@ All upgrades in $[prodname] are free with a valid license.
 
 :::
 
-## Upgrades paths
-
-Upgrading to $[prodname] v3.13 and above, from Calico 3.22 and below is currently unsupported.
-
 ## Prepare your cluster for the upgrade
 
 Calico Enterprise creates default-deny policies for all Calico and Tigera namespaces, including calico-system. If you deploy workloads into the calico-system namespace, you must create policy that allows the required traffic for your workloads prior to upgrade.
@@ -32,8 +28,9 @@ The following steps assume the Calico deployment is installed on `tigera-operato
 
    <CodeBlock language='bash'>
      {'$[version]' === 'master'
-       ? 'gsutil cp gs://tigera-helm-charts/tigera-operator-v0.0.tgz'
-       : 'curl -O -L $[downloadsurl]/ee/charts/tigera-operator-$[chart_version_name].tgz'}
+       ? (`gsutil cp gs://tigera-helm-charts/tigera-operator-v0.0.tgz`)
+       : (`curl -O -L $[downloadsurl]/ee/charts/tigera-operator-$[chart_version_name].tgz`)
+      }
    </CodeBlock>
 
 1. Install the $[prodname] custom resource definitions.

@@ -12,16 +12,6 @@ All upgrades in $[prodname] are free with a valid license.
 
 :::
 
-## Upgrades paths
-
-Upgrading to $[prodname] v3.14 from previous $[prodname] versions other than v3.13 is currently unsupported.
-
-:::note
-
-Always check the [Release Notes](../../../../release-notes/index.mdx) for exceptions; limitations can override the above pattern.
-
-:::
-
 ## Prerequisites
 
 - Verify that your Kubernetes cluster is using Helm
@@ -62,7 +52,7 @@ owned resources being garbage collected by Kubernetes.
 
 $[prodname] 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.13 or later
+## Upgrade from 3.19 or later
 
 :::note
 
@@ -74,8 +64,9 @@ These steps differ based on your cluster type. If you are unsure of your cluster
 
    <CodeBlock language='bash'>
      {'$[version]' === 'master'
-       ? 'gsutil cp gs://tigera-helm-charts/tigera-operator-v0.0.tgz'
-       : 'curl -O -L $[downloadsurl]/ee/charts/tigera-operator-$[chart_version_name].tgz'}
+       ? (`gsutil cp gs://tigera-helm-charts/tigera-operator-v0.0.tgz`)
+       : (`curl -O -L $[downloadsurl]/ee/charts/tigera-operator-$[chart_version_name].tgz`)
+      }
    </CodeBlock>
 
 1. Install the $[prodname] custom resource definitions.

@@ -16,9 +16,9 @@ All upgrades in $[prodname] 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.6, you can upgrade to 3.7, or you can upgrade directly to 3.8. However, you cannot upgrade beyond **two releases**; upgrading from 3.6 to 3.9 (three releases) is not supported.
+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.6, and you want to get to 3.10, you can upgrade to 3.8, then upgrade from 3.8 directly to 3.10.
+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.
 
 :::note
 
@@ -31,8 +31,6 @@ Always check the [Release Notes](../../../../release-notes/index.mdx) for except
 Verify that your Kubernetes cluster is using a version of $[prodname] installed with the operator, by running
 `kubectl get tigerastatus`. If the result is successful, then your installation is using the operator.
 
-If your cluster is on a version earlier than 2.6 or does not use the operator, contact Tigera support to upgrade.
-
 If your cluster has a Calico installation, contact Tigera support to upgrade.
 
 ## Prepare your cluster for the upgrade
@@ -67,13 +65,13 @@ $[prodname] creates a default-deny for the calico-system namespace. If you deplo
 
 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](../../../../operations/comms/log-storage-tls.mdx) that include the required service DNS names.
 
-For AKS only, upgrades beginning from $[prodname] v3.11.2 to a newer version will automatically upgrade $[prodnameWindows]. During the upgrade, Windows nodes will be tainted so new pods will not be scheduled until the upgrade of the node has finished. The $[prodnameWindows] upgrade status can be monitored with: `kubectl get tigerastatus calico -oyaml`
+For AKS only, upgrades to a newer version will automatically upgrade $[prodnameWindows]. During the upgrade, Windows nodes will be tainted so new pods will not be scheduled until the upgrade of the node has finished. The $[prodnameWindows] upgrade status can be monitored with: `kubectl get tigerastatus calico -oyaml`
 
-For all other platforms or versions older than v3.11.2, upgrading $[prodnameWindows] can be performed out-of-band with the $[prodname] upgrade of the cluster. For each Windows node, [uninstall](../../../install-on-clusters/windows-calico/manual-install/maintain.mdx#uninstall-calico-enterprise-for-windows-from-windows-nodes) the $[prodnameWindows] services, copy over the latest $[prodnameWindows] installation archive, then proceed with the [installation](../../../install-on-clusters/windows-calico/manual-install/quickstart.mdx#install-calico-enterprise-for-windows-manually).
+For all other platforms, upgrading $[prodnameWindows] can be performed out-of-band with the $[prodname] upgrade of the cluster. For each Windows node, [uninstall](../../../install-on-clusters/windows-calico/manual-install/maintain.mdx#uninstall-calico-enterprise-for-windows-from-windows-nodes) the $[prodnameWindows] services, copy over the latest $[prodnameWindows] installation archive, then proceed with the [installation](../../../install-on-clusters/windows-calico/manual-install/quickstart.mdx#install-calico-enterprise-for-windows-manually).
 
 ### Multi-cluster management
 
-For $[prodname] v3.5 and v3.7, upgrading multi-cluster management setups must include updating all managed and management clusters.
+For $[prodname], upgrading multi-cluster management setups must include updating all managed and management clusters.
 
 :::note
 

@@ -15,9 +15,9 @@ All upgrades in $[prodname] 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.6, you can upgrade to 3.7, or you can upgrade directly to 3.8. However, you cannot upgrade beyond **two releases**; upgrading from 3.6 to 3.9 (three releases) is not supported.
+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.6, and you want to get to 3.10, you can upgrade to 3.8, then upgrade from 3.8 directly to 3.10.
+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.
 
 :::note
 

@@ -18,7 +18,7 @@ Determine the right install method for your deployment, how to customize your in
 
 ### API-driven installation
 
-Starting in release v3.0, $[prodname] API-driven installation is the only supported installation method. The Tigera operator APIs (**operator.tigera.io**), let you define a $[prodname] cluster using declarative states. The APIs in the operator.tigera.io group define the desired state for your installation, and provide status reporting and visibility into the health of $[prodname]. The Tigera operator makes sure the cluster’s state matches your desired state. These APIs can be configured at install-time, and can also be modified on a running cluster to adjust configuration.
+The Tigera operator APIs (**operator.tigera.io**), let you define a $[prodname] cluster using declarative states. The APIs in the operator.tigera.io group define the desired state for your installation, and provide status reporting and visibility into the health of $[prodname]. The Tigera operator makes sure the cluster’s state matches your desired state. These APIs can be configured at install-time, and can also be modified on a running cluster to adjust configuration.
 
 ### Available APIs
 

@@ -9,7 +9,7 @@ import ReqsKernel from "@site/calico-enterprise_versioned_docs/version-3.17/_inc
 
 ## OpenShift requirements
 
-See [OpenShift Container Platform](https://docs.openshift.com/container-platform/4.6/welcome/index.html).
+See [OpenShift Container Platform](https://docs.openshift.com/container-platform/4.13/welcome/index.html).
 
 <ReqsSys orch='OpenShift' />
 

@@ -30,7 +30,7 @@ The following table summarizes the networking options and considerations.
 
 | Networking         | Components                                                                                  | **Value/Content**                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
 | ------------------ | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| $[prodname] BGP   | Windows CNI plugin:<br /><br />calico.exeLinux: $[prodname] for policy and networking      | $[prodname]'s native networking approach, supports:<br/>- Auto-configured node-to-node BGP mesh over an L2 fabric<br/>- Peering with external routers for an L3 fabric<br/>- $[prodname] IPAM and IP aggregation (with some limitations)<br/>- Route reflectors (including the new in-cluster route reflector introduced in $[prodname] v3.3). **Note**: Windows node cannot act as route reflectors.<br/>- Kubernetes API datastore driver<br/><br />**AWS users**: If running on AWS, you must disable the source/dest check on your EC2 instances so that hosts can forward traffic on behalf of pods. |
+| $[prodname] BGP   | Windows CNI plugin:<br /><br />calico.exeLinux: $[prodname] for policy and networking      | $[prodname]'s native networking approach, supports:<br/>- Auto-configured node-to-node BGP mesh over an L2 fabric<br/>- Peering with external routers for an L3 fabric<br/>- $[prodname] IPAM and IP aggregation (with some limitations)<br/>- Route reflectors **Note**: Windows node cannot act as route reflectors.<br/>- Kubernetes API datastore driver<br/><br />**AWS users**: If running on AWS, you must disable the source/dest check on your EC2 instances so that hosts can forward traffic on behalf of pods. |
 | $[prodname] VXLAN | Windows CNI plugin:<br/>calico.exe<br /><br />Linux: $[prodname] for policy and networking | $[prodname]'s VXLAN overlay, supports:<br/><br />- VXLAN overlay, which can traverse most networks.<br/>- Auto-configured node-to-node routing<br/>- $[prodname] IPAM and IP aggregation (with some limitations)<br/>- Kubernetes API datastore driver<br/>**Note**: VXLAN runs on UDP port 4789 (this is the only port supported by Windows), remember to open that port between your $[prodname] hosts in any firewalls / security groups.                                                                                                                                                              |
 | Cloud provider     | Windows CNI plugin: win-bridge.exe<br /><br />Linux: $[prodname] policy-only               | A useful fallback, particularly if you have a Kubernetes cloud provider that automatically installs inter-host routes. $[prodname] has been tested with the standard **win-bridge.exe** CNI plugin so it should work with any networking provider that ultimately uses win-bridge.exe to network the pod (such as the Azure CNI plugin and cloud provider).                                                                                                                                                                                                                                                 |