How It Works
There are two major data categories stored in ETCD:
-
Internal topology data, includes instance information, endpoint information, and leader information in the ETCD.
-
External Peer information added by applications.
Both these categories of data are stored in ETCD and are used to store and notify the internal topology data and external peer information data. The current implementation of the topology data and notifications results in increased traffic towards ETCD. The traffic can be reduced by implementing restricted notifications and reload functionality that allows pods to opt in/out for these notifications and reloads.
The current topology data is broadcasted to all the app-infra based pods, including pods that aren’t interested in these entries. This results in unwanted notifications from ETCD that can be avoided.
Furthermore, all the data is reloaded every 10 seconds, which means that the records from ETCD and local cache are reconciled. If there’s a discrepancy, then a notification is raised. While this approach ensures consistency between ETCD and local cache, it can result in excessive traffic towards ETCD.
To optimize this process, the new implementation is to apply the selective approach to notifications and reloading, where only pods that require certain entries or changes are notified, instead of broadcasting to all pods. Also, instead of reloading all data every 10 seconds, it is efficient to reload only the subscribed data. This selective approach helps to reduce the volume of data between various pods and ETCD and improves the overall performance of the system. As a result, the traffic between ETCD and all the pods is reduced.
The following pods no more receives the external peer data and hence the traffic is reduced:
-
cache-pod
-
rest-ep
-
udp-proxy
-
radius-ep
-
li-ep
-
dns-proxy
-
gtpp-ep
-
georeplication-pod
-
oam-pod