From 6ca90f4d81dc8cdda110628b5a9ba303256228c0 Mon Sep 17 00:00:00 2001 From: Chris Tauchen Date: Tue, 11 Aug 2026 12:45:21 +0100 Subject: [PATCH] DOCS-2884: Make Typha node-count guidance consistent The docs gave two different node counts for when Typha matters. The install and metrics pages say Typha applies above 50 nodes, while the Typha and architecture overview pages say it becomes essential at 100 or more nodes. A customer flagged the conflict. Remove the fixed "100+ node" figure from the Typha and architecture overview pages in Calico Open Source and Calico Enterprise, across the latest and all supported versioned docs. The operator always deploys and autoscales Typha, so a fixed node count does not apply there. The 50-node threshold stays on the manifest install and metrics pages, which is the only place a manual threshold is relevant. Co-Authored-By: Claude Opus 4.8 (1M context) --- calico-enterprise/reference/architecture/overview.mdx | 2 +- .../reference/component-resources/typha/overview.mdx | 2 +- .../version-3.20-2/reference/architecture/overview.mdx | 2 +- .../reference/component-resources/typha/overview.mdx | 2 +- .../version-3.21-2/reference/architecture/overview.mdx | 2 +- .../reference/component-resources/typha/overview.mdx | 2 +- .../version-3.22-2/reference/architecture/overview.mdx | 2 +- .../reference/component-resources/typha/overview.mdx | 2 +- .../version-3.23-2/reference/architecture/overview.mdx | 2 +- .../reference/component-resources/typha/overview.mdx | 2 +- .../version-3.24-1/reference/architecture/overview.mdx | 2 +- .../reference/component-resources/typha/overview.mdx | 2 +- calico/reference/architecture/overview.mdx | 2 +- calico/reference/typha/overview.mdx | 2 +- .../version-3.29/reference/architecture/overview.mdx | 2 +- calico_versioned_docs/version-3.29/reference/typha/overview.mdx | 2 +- .../version-3.30/reference/architecture/overview.mdx | 2 +- calico_versioned_docs/version-3.30/reference/typha/overview.mdx | 2 +- .../version-3.31/reference/architecture/overview.mdx | 2 +- calico_versioned_docs/version-3.31/reference/typha/overview.mdx | 2 +- .../version-3.32/reference/architecture/overview.mdx | 2 +- calico_versioned_docs/version-3.32/reference/typha/overview.mdx | 2 +- 22 files changed, 22 insertions(+), 22 deletions(-) diff --git a/calico-enterprise/reference/architecture/overview.mdx b/calico-enterprise/reference/architecture/overview.mdx index 4e3f3e372f..3da4e4cd8b 100644 --- a/calico-enterprise/reference/architecture/overview.mdx +++ b/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 diff --git a/calico-enterprise/reference/component-resources/typha/overview.mdx b/calico-enterprise/reference/component-resources/typha/overview.mdx index 6396f92038..1fda0c8c2c 100644 --- a/calico-enterprise/reference/component-resources/typha/overview.mdx +++ b/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. diff --git a/calico-enterprise_versioned_docs/version-3.20-2/reference/architecture/overview.mdx b/calico-enterprise_versioned_docs/version-3.20-2/reference/architecture/overview.mdx index 22550a7ffd..81c740d0f3 100644 --- a/calico-enterprise_versioned_docs/version-3.20-2/reference/architecture/overview.mdx +++ b/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 diff --git a/calico-enterprise_versioned_docs/version-3.20-2/reference/component-resources/typha/overview.mdx b/calico-enterprise_versioned_docs/version-3.20-2/reference/component-resources/typha/overview.mdx index fc3c771648..c24ba697e3 100644 --- a/calico-enterprise_versioned_docs/version-3.20-2/reference/component-resources/typha/overview.mdx +++ b/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. diff --git a/calico-enterprise_versioned_docs/version-3.21-2/reference/architecture/overview.mdx b/calico-enterprise_versioned_docs/version-3.21-2/reference/architecture/overview.mdx index 7869ef3ed3..329cfdf22e 100644 --- a/calico-enterprise_versioned_docs/version-3.21-2/reference/architecture/overview.mdx +++ b/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 diff --git a/calico-enterprise_versioned_docs/version-3.21-2/reference/component-resources/typha/overview.mdx b/calico-enterprise_versioned_docs/version-3.21-2/reference/component-resources/typha/overview.mdx index fc3c771648..c24ba697e3 100644 --- a/calico-enterprise_versioned_docs/version-3.21-2/reference/component-resources/typha/overview.mdx +++ b/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. diff --git a/calico-enterprise_versioned_docs/version-3.22-2/reference/architecture/overview.mdx b/calico-enterprise_versioned_docs/version-3.22-2/reference/architecture/overview.mdx index 1546896640..2d6f3f4e96 100644 --- a/calico-enterprise_versioned_docs/version-3.22-2/reference/architecture/overview.mdx +++ b/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 diff --git a/calico-enterprise_versioned_docs/version-3.22-2/reference/component-resources/typha/overview.mdx b/calico-enterprise_versioned_docs/version-3.22-2/reference/component-resources/typha/overview.mdx index 6396f92038..1fda0c8c2c 100644 --- a/calico-enterprise_versioned_docs/version-3.22-2/reference/component-resources/typha/overview.mdx +++ b/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. diff --git a/calico-enterprise_versioned_docs/version-3.23-2/reference/architecture/overview.mdx b/calico-enterprise_versioned_docs/version-3.23-2/reference/architecture/overview.mdx index cbceb56480..760400063c 100644 --- a/calico-enterprise_versioned_docs/version-3.23-2/reference/architecture/overview.mdx +++ b/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 diff --git a/calico-enterprise_versioned_docs/version-3.23-2/reference/component-resources/typha/overview.mdx b/calico-enterprise_versioned_docs/version-3.23-2/reference/component-resources/typha/overview.mdx index 6396f92038..1fda0c8c2c 100644 --- a/calico-enterprise_versioned_docs/version-3.23-2/reference/component-resources/typha/overview.mdx +++ b/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. diff --git a/calico-enterprise_versioned_docs/version-3.24-1/reference/architecture/overview.mdx b/calico-enterprise_versioned_docs/version-3.24-1/reference/architecture/overview.mdx index 4e3f3e372f..3da4e4cd8b 100644 --- a/calico-enterprise_versioned_docs/version-3.24-1/reference/architecture/overview.mdx +++ b/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 diff --git a/calico-enterprise_versioned_docs/version-3.24-1/reference/component-resources/typha/overview.mdx b/calico-enterprise_versioned_docs/version-3.24-1/reference/component-resources/typha/overview.mdx index 6396f92038..1fda0c8c2c 100644 --- a/calico-enterprise_versioned_docs/version-3.24-1/reference/component-resources/typha/overview.mdx +++ b/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. diff --git a/calico/reference/architecture/overview.mdx b/calico/reference/architecture/overview.mdx index 64a4db5f43..e3d83f1b26 100644 --- a/calico/reference/architecture/overview.mdx +++ b/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 diff --git a/calico/reference/typha/overview.mdx b/calico/reference/typha/overview.mdx index 42ccaefe20..cbcc9a0d55 100644 --- a/calico/reference/typha/overview.mdx +++ b/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. diff --git a/calico_versioned_docs/version-3.29/reference/architecture/overview.mdx b/calico_versioned_docs/version-3.29/reference/architecture/overview.mdx index 3bcb2882fd..7d9a8c7463 100644 --- a/calico_versioned_docs/version-3.29/reference/architecture/overview.mdx +++ b/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 diff --git a/calico_versioned_docs/version-3.29/reference/typha/overview.mdx b/calico_versioned_docs/version-3.29/reference/typha/overview.mdx index dc5a068e28..aa7935526d 100644 --- a/calico_versioned_docs/version-3.29/reference/typha/overview.mdx +++ b/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. diff --git a/calico_versioned_docs/version-3.30/reference/architecture/overview.mdx b/calico_versioned_docs/version-3.30/reference/architecture/overview.mdx index 3bcb2882fd..7d9a8c7463 100644 --- a/calico_versioned_docs/version-3.30/reference/architecture/overview.mdx +++ b/calico_versioned_docs/version-3.30/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 diff --git a/calico_versioned_docs/version-3.30/reference/typha/overview.mdx b/calico_versioned_docs/version-3.30/reference/typha/overview.mdx index dc5a068e28..aa7935526d 100644 --- a/calico_versioned_docs/version-3.30/reference/typha/overview.mdx +++ b/calico_versioned_docs/version-3.30/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. diff --git a/calico_versioned_docs/version-3.31/reference/architecture/overview.mdx b/calico_versioned_docs/version-3.31/reference/architecture/overview.mdx index 3bcb2882fd..7d9a8c7463 100644 --- a/calico_versioned_docs/version-3.31/reference/architecture/overview.mdx +++ b/calico_versioned_docs/version-3.31/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 diff --git a/calico_versioned_docs/version-3.31/reference/typha/overview.mdx b/calico_versioned_docs/version-3.31/reference/typha/overview.mdx index dc5a068e28..aa7935526d 100644 --- a/calico_versioned_docs/version-3.31/reference/typha/overview.mdx +++ b/calico_versioned_docs/version-3.31/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. diff --git a/calico_versioned_docs/version-3.32/reference/architecture/overview.mdx b/calico_versioned_docs/version-3.32/reference/architecture/overview.mdx index 64a4db5f43..e3d83f1b26 100644 --- a/calico_versioned_docs/version-3.32/reference/architecture/overview.mdx +++ b/calico_versioned_docs/version-3.32/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 diff --git a/calico_versioned_docs/version-3.32/reference/typha/overview.mdx b/calico_versioned_docs/version-3.32/reference/typha/overview.mdx index 42ccaefe20..cbcc9a0d55 100644 --- a/calico_versioned_docs/version-3.32/reference/typha/overview.mdx +++ b/calico_versioned_docs/version-3.32/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.