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.