--- title: "Why use Typha in your Calico Kubernetes Deployments?" source: "https://www.tigera.io/blog/why-use-typha-in-your-calico-kubernetes-deployments/" description: "Typha is not optional, but is a necessary component of your Calico deployment for any decent-sized production cluster." --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Why use Typha in your Calico Kubernetes Deployments? By [Bikram Gupta](https://www.tigera.io/blog/author/bikramgupta/) on Apr 07, 2020 • 3 min read [Calico](https://www.tigera.io/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports a broad range of platforms including [Kubernetes](http://kubernetes.io/), [OpenShift](http://www.openshift.com/), [Docker EE](http://www.mirantis.com/software/docker/docker-enterprise/), [OpenStack](http://www.openstack.org/), and bare metal. In this blog, we will focus on Kubernetes pod networking and network security using Calico. Calico uses [etcd](http://etcd.io/) as the back-end datastore. When you run Calico on Kubernetes, you can use the same etcd datastore through the [Kubernetes API server.](http://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) This is called a [Kubernetes backed datastore](http://docs.projectcalico.org/getting-started/kubernetes/hardway/the-calico-datastore) (KDD) in Calico. The following diagram shows a block-level architecture of Calico. ![Calico block-level architecture diagram](/app/uploads/2020/04/Calico-block-architecture-300x169.png) Calico-node runs as a [Daemonset](http://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), and has a fair amount of interaction with the Kubernetes API server. It’s easy for you to profile that by simply enabling audit logs for [calico-node](http://github.com/projectcalico/node). For example, in my [kubeadm](http://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) cluster, I used the following audit configuration ![Code of audit configuration](/app/uploads/2020/04/audit-configuration-300x191.png) To set the context, this is my cluster configuration. ![Code of cluster configuration](/app/uploads/2020/04/cluster-configuration-300x168.png) As we are running [Typha](http://github.com/projectcalico/typha) already, let us profile the API calls for both Calico and Typha components. I used the following commands to extract the unique API calls for each. ![Code to extract the unique API calls](/app/uploads/2020/04/commands1-280x300.png) ![Code to extract the unique API calls](/app/uploads/2020/04/commands2-259x300.png) ![Code to extract the unique API calls](/app/uploads/2020/04/commands3-300x59.png) If you ignore the license key API calls from calico-node, you will see that the API calls from calico-node are an order of magnitude smaller than the API calls from Typha. I also sent the logs over to Elasticsearch, and here’s a simple plot for comparison. As you can see, there’s a massive difference between the API calls generated from Typha vs. Calico. (Kibana JSON available here). ![Graph that shows the difference between the API calls generated from Typha vs. Calico](/app/uploads/2020/04/Filters-300x148.png) The key point is that API calls from Typha will remain constant as you scale the cluster. If you watch the raw log pattern from gist, above, the bulk of API calls from Typha are watch events. [Typha](http://github.com/projectcalico/typha) is a read-only system. It watches for changes in various resources, and does a fan-out to all its clients (calico-node). This significantly reduces the load on the API server. [An instance of Typha sits between the datastore](http://github.com/projectcalico/typha#project-calico) (such as the Kubernetes API server) and many instances of Felix. ![Datastore diagram](/app/uploads/2020/04/datastore-pen-drawing-300x169.png) Another way to understand this is to simply generate a [clusterRole](http://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) from the audit logs of Typha and calico-node. When reviewing the clusterRoles, you will see that Typha is primarily doing get, list, and watch. Whereas calico-node does create, update, delete, patch, get, and list on resources. The watch events, which are very frequent given the dynamic nature of configuration and pods, are handled by Typha. ![Code snippet](/app/uploads/2020/04/bottom-text-window-300x80.png) Without Typha, every calico-node would have to register its own watch with the API Server, and the load on the API server would multiply as you scale up the number of nodes. By having Typha, all the watch events are off-loaded to Typha and read only once from the API server. Hence Typha is not optional, but is a necessary component of your Calico deployment for any decent-sized production cluster. ————————————————- [**Free Online Training**](https://www.tigera.io/events/) Access Live and On-Demand Kubernetes Tutorials [**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home) Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption [Open Source](https://www.tigera.io/tags/open-source/)[Project Calico](https://www.tigera.io/tags/project-calico/) ## Related posts [![What’s new in Calico: Spring 2026 Release](https://www.tigera.io/app/uploads/2026/06/Whats-New-in-Calico-NEW-TEMPLATE-2026.png)](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [Company Blog](https://www.tigera.io/category/company-blog/) #### [What’s new in Calico: Spring 2026 Release](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on Jun 2, 2026 Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs... [Read more](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [![Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/app/uploads/2026/05/Kubernetes-Operational-Maturity-Secure-and-Resilient-Cluster-Federation-with-Cluster-Mesh.png)](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) #### [Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on May 25, 2026 Practically no one runs a single Kubernetes cluster in production these days. Maybe that’s how it started but data sovereignty requirements, acquisitions, AI initiatives and the need for edge servers, among other considerations, have pulled... [Read more](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) [![What’s New in Calico v3.32](https://www.tigera.io/app/uploads/2026/05/Green-Please-use-a-different-background-color-alternately-1.png)](https://www.tigera.io/blog/whats-new-in-calico-v3-32/) #### [What’s New in Calico v3.32](https://www.tigera.io/blog/whats-new-in-calico-v3-32/) By [Reza Ramezanpour](https://www.tigera.io/blog/author/rezar/) on May 13, 2026 We’re excited to announce the release of Calico Open Source v3.32! 🎉 This release corresponds with Kubernetes v1.36 (Codename Haru) and it goes beyond just sharing a cat as the mascot of the release, it... [Read more](https://www.tigera.io/blog/whats-new-in-calico-v3-32/)