Cloud-native applications require their workloads to be dynamically provisioned, so network modifications cannot be made manually for one service (say, the frontend) to connect to other services (say, the backend). The Consul architecture evolved differently compared to Kubernetes service discovery. Kubernetes uses iptables to point service IP addresses to the dynamic IP addresses of the pod, whereas Consul uses DNS for service discovery. Consul's service discovery can work with Kubernetes by injecting its DNS as an upstream server to the Kubernetes DNS. This architecture is mainly influenced by the modern gossip protocol, which works across multiple data centers.

The architecture of Consul supports loose coupling of data centers so that connectivity failures in a data center do not affect the availability of Consul in other data centers. With a dedicated group of servers, each data center runs independently using a private LAN gossip pool. Multiple data centers are connected with others using a WAN gossip pool. This can be seen in the following diagram:

The key components that define the architecture for Consul are as follows:

• Data center
• Client/server
• Protocol management

We will take a look at each of these individually in upcoming sections.