DOCS-2884: Make Typha node-count guidance consistent

calico-enterprise/reference/architecture/overview.mdx

@@ -208,7 +208,7 @@ Depending on the specific orchestrator environment, Felix is responsible for:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/typha), and [Typha component](../component-resources/typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## Kubernetes components
 

calico-enterprise/reference/component-resources/typha/overview.mdx

@@ -9,4 +9,4 @@ The Typha daemon sits between the datastore (such as the Kubernetes API server)
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.

calico-enterprise_versioned_docs/version-3.20-2/reference/architecture/overview.mdx

@@ -238,7 +238,7 @@ Depending on the specific orchestrator environment, Felix is responsible for:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/typha), and [Typha component](../component-resources/typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## Kubernetes components
 

calico-enterprise_versioned_docs/version-3.20-2/reference/component-resources/typha/overview.mdx

@@ -9,4 +9,4 @@ The Typha daemon sits between the datastore (such as the Kubernetes API server)
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.

calico-enterprise_versioned_docs/version-3.21-2/reference/architecture/overview.mdx

@@ -238,7 +238,7 @@ Depending on the specific orchestrator environment, Felix is responsible for:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/typha), and [Typha component](../component-resources/typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## Kubernetes components
 

calico-enterprise_versioned_docs/version-3.21-2/reference/component-resources/typha/overview.mdx

@@ -9,4 +9,4 @@ The Typha daemon sits between the datastore (such as the Kubernetes API server)
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.

calico-enterprise_versioned_docs/version-3.22-2/reference/architecture/overview.mdx

@@ -238,7 +238,7 @@ Depending on the specific orchestrator environment, Felix is responsible for:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/typha), and [Typha component](../component-resources/typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## Kubernetes components
 

calico-enterprise_versioned_docs/version-3.22-2/reference/component-resources/typha/overview.mdx

@@ -9,4 +9,4 @@ The Typha daemon sits between the datastore (such as the Kubernetes API server)
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.

calico-enterprise_versioned_docs/version-3.23-2/reference/architecture/overview.mdx

@@ -243,7 +243,7 @@ Depending on the specific orchestrator environment, Felix is responsible for:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/typha), and [Typha component](../component-resources/typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## Kubernetes components
 

calico-enterprise_versioned_docs/version-3.23-2/reference/component-resources/typha/overview.mdx

@@ -9,4 +9,4 @@ The Typha daemon sits between the datastore (such as the Kubernetes API server)
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.

calico-enterprise_versioned_docs/version-3.24-1/reference/architecture/overview.mdx

@@ -208,7 +208,7 @@ Depending on the specific orchestrator environment, Felix is responsible for:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/typha), and [Typha component](../component-resources/typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## Kubernetes components
 

calico-enterprise_versioned_docs/version-3.24-1/reference/component-resources/typha/overview.mdx

@@ -9,4 +9,4 @@ The Typha daemon sits between the datastore (such as the Kubernetes API server)
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.

calico/reference/architecture/overview.mdx

@@ -147,7 +147,7 @@ The `tigera/kube-controllers` container includes the following controllers:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/calico/tree/master/typha), and [Typha component](../typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## calicoctl
 

calico/reference/typha/overview.mdx

@@ -15,4 +15,4 @@ If you are using the Kubernetes API Datastore, we recommend using Typha. Althoug
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.

calico_versioned_docs/version-3.29/reference/architecture/overview.mdx

@@ -142,7 +142,7 @@ The `tigera/kube-controllers` container includes the following controllers:
 
 **Main task**: Increases scale by reducing each node’s impact on the datastore. Runs as a daemon between the datastore and instances of Felix. Installed by default, but not configured. [Typha description](https://github.com/projectcalico/calico/tree/master/typha), and [Typha component](../typha/index.mdx).
 
-Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+Typha maintains a single datastore connection on behalf of all of its clients like Felix and confd. It caches the datastore state and deduplicates events so that they can be fanned out to many listeners. Because one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor. And because Typha can filter out updates that are not relevant to Felix, it also reduces Felix’s CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
 
 ## calicoctl
 

calico_versioned_docs/version-3.29/reference/typha/overview.mdx

@@ -15,4 +15,4 @@ If you are using the Kubernetes API Datastore, we recommend using Typha. Althoug
 ## Advantages
 
 - Since one Typha instance can support hundreds of Felix instances, it reduces the load on the datastore by a large factor.
-- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.
+- Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes.