Glossary

This page defines terms used in Consul and provides links to its supporting documentation.

Access logs

Consul can emit access logs to record application connections and requests that pass through proxies in a service mesh, including sidecar proxies and gateways. When you enable access logs in your proxy defaults, you can use it to diagnose and troubleshoot network issues, detect threats to your network, and audit traffic for security compliance.

You can also configure the OpenTelemetry Envoy extension to capture and stream access logs. Refer to access logs for more information on enabling access logs in Consul.

Agent

The Consul agent is a long running daemon that operates on a node. It is a core unit of Consul operations. Agents are highly configurable, which enables you to deploy Consul to any infrastructure.

Agents can run in either server mode or client mode. Server nodes make up the control plane's server cluster, and they are responsible for maintaining the cluster's state. Client nodes are lightweight processes that make up the majority of the cluster. They interface with the server nodes for most operations and maintain little state of their own. Clients run on every node where services are running.

For more information, refer to Consul agent fundamentals.

Admin partitions

Admin partitions define one or more administrative boundaries for a Consul deployment. They exist one level above namespaces in Consul's identity hierarchy. Server clusters that manage multiple admin partitions require a Consul Enterprise license.

Admin partitions enable cluster peering connections and sameness groups between Consul datacenters deployed in different regions or cloud environments. Refer to the admin partition documentation for more information.

API gateways

API gateways enable external network clients to securely access applications and services running in a Consul datacenter. Consul API gateways can also forward requests from clients to specific destinations in the service mesh based on request's path or protocol.

To enable an API gateway, you must configure the gateway, its listeners, and its routes. Refer to API gateway overview for more about deploying API gateways to your Consul service mesh.

Application load balancing

A load balancer accepts incoming traffic requests and routes them to service instances in a distributed network so that resource consumption is spread between available instances and individual nodes are not overworked. Consul functions as a load balancer by directing traffic to healthy service instances using information registered to the catalog and Consul DNS. Consul can also integrate with external load balancers such as NGINX and HAProxy.

Load balancing is a core component of Consul's service discovery functionality. For more information, refer to service discovery overview.

Blocking queries

Many Consul API endpoints support blocking queries. In a blocking query, Consul waits until an update occurs and then returns a response to the HTTP request. Because connections can remain open without updates occuring, configure timeouts to control blocking query behavior. Blocking queries are an important part of some of Consul's advanced networking automations. To learn more, refer to Blocking Queries in the Consul API documentation.

Certificate authority

Consul servers include a built-in certificate authority (CA) provider to centrally manage mTLS certificates and perform signing operations. When using the CA, sidecar proxies confirm that an incoming request includes a signed mTLS certificate before it forwards the request to a service.

To use the built-in CA, you must bootstrap it by generating a private key and root certificate that you can distribute to agents. You can also configure Consul agents to use other certificate authorities, such as HashiCorp Vault.

For more information, refer to certificate authority overview.

Clusters

A collection of Consul agents that are aware of each other is called a cluster. The terms datacenter and cluster are often used interchangeably. In some cases, however, cluster refers only to Consul server agents, such as in HCP Consul Dedicated. In other contexts, such as the admin partitions feature included with Consul Enterprise, a cluster may refer to collection of client agents.

Cluster peering

Cluster peering connects two or more independent Consul clusters so that services deployed to different datacenters can communicate. The process to establish a connection generates and exchanges peering tokens between admin partitions in each datacenter.

Peering topologies that include more than one admin partition in a single Consul datacenter require Consul Enterprise. HCP Consul enables additional support for cluster peering lifecycle operations through HCP Consul Central.

Cluster peering in your service mesh enables sameness groups, service failover, and connections between Consul clusters owned by different operators. Refer to the Cluster peering documentation for more information.

Consul DNS

Consul DNS is the primary interface for querying records when Consul service mesh is disabled and your network runs in a non-Kubernetes environment. Consul DNS lets you look up services and nodes registered with Consul without making HTTP API requests to Consul. We recommend using the DNS for service discovery in virtual machine (VM) environments because it removes the need to modify native applications so that they can consume the Consul service discovery APIs. The DNS has several default configurations, but you can customize how the server processes lookups. Refer to Configure Consul DNS behavior for additional information.

For reference information about formatting Consul DNS requests, refer to Consul DNS reference.

Consul template

Consul Template is a tool that enables you to programmatically render configuration files according to data in Consul's KV store and the services registered to the catalog. It updates configuration files according to relevant changes in the datacenter. This tool requires a separate download and installation becuase it is not part of Consul's binary.

For more information, refer to Consul Template overview.

Datacenters

The Consul control plane contains one or more datacenters. A datacenter is the smallest unit of Consul infrastructure that can perform basic Consul operations. A datacenter contains at least one Consul server agent, but a real-world deployment contains three or five server agents and several Consul client agents. You can create multiple datacenters and allow nodes in different datacenters to interact with each other. Refer to Bootstrap a Datacenter for information about how to create a datacenter.

Distributed tracing

Distributed tracing tracks and correlates requests between microservices, including proxies and gateways, in your service mesh. By implementing a tracing library such as Jaeger or Zipkin, you can trace the spans a request follows to investigate failures between service calls.

Refer to distributed tracing for more information.

Key/value store

Consul includes a built-in key/value store that stores indexed objects on Consul servers and makes them accessible by any Consul agent. Advanced deployment strategies leverage Consul's KV store to watch for changes, create distributed semaphors, and dynamically generate configuration files for automated deployments. Consul's KV store is enabled by default. The Consul KV API, CLI, and UI are now considered feature complete and no new feature development is planned for future releases.

For more information, refer to Consul key/value (KV) store overview.

Ingress gateways

Ingress gateways listen for external requests and route authorized traffic to instances in the service mesh. They provide one-way traffic from external sources to services in the mesh. If you want to enable traffic from services in the mesh to external destinations, then you must also configure a terminating gateway, which is a separate component that requires additional configuration and maintenance.

Ingress gateways are deprecated. Use Consul API gateways to secure service mesh ingress instead.

Refer to Ingress gateway overview for additional information about deploying ingress gateways to your Consul service mesh.

Mesh gateways

Mesh gateways route service mesh traffic between Consul datacenters that reside in different cloud or runtime environments where general interconnectivity between all services in all datacenters is not feasible. In hybrid or multi-cloud production environments, mesh gateways secure communication between datacenters deployed to different cloud regions or platforms.

After you register a mesh gateway with Consul, you can configure a service's sidecar proxy to enable the mesh gateway as a service upstream. Refer to the Mesh gateway documentation for more information.

Namespaces

Namespaces isolate data for different users or teams. They exist one level below admin partitions in Consul's identity hierarchy. Server clusters register services to multiple namespaces require a Consul Enterprise license.

Namespaces can help reduce operational challenges by removing restrictions around uniqueness of resource names across distinct teams. You can secure namespace resources with Consul's Access Control List (ACL) system. Refer to the namespace documentation for more information.

Network areas

Network areas specify a relationship between a pair of Consul datacenters. Operators create reciprocal areas on each side of the relationship and then joins them together. This networking strategy allows for more flexible relationships between Consul datacenters, such as hub/spoke or more general tree structures. Because traffic between network areas uses server RPC (8300/tcp), you can secure it using only TLS.

Refer to the Network area documentation for more information.

Network infrastructure automation

Network Infrastructure Automation (NIA) enables dynamic updates to network infrastructure devices triggered by service changes. Consul-Terraform-Sync (CTS) utilizes Consul as a data source that contains networking information about services and monitors those services. Terraform is used as the underlying automation tool and leverages the Terraform provider ecosystem to drive relevant changes to the network infrastructure.

Consul-Terraform-Sync requires an Enterprise license. For more information, refer to Network infrastructure automation.

Network segments

Network segments enable Consul deployments for organizations with network rules or firewalls that prevent full connectivity between all agents in a datacenter's gossip pool. Establishing communication boundaries with Consul network segments limits Consul's connectivity requirements to an individual segment.

Network segments are defined in agent configuration files and require a Consul Enterprise license. Refer to the network segments documentation for more information.

Prepared queries

Prepared queries are configurations that enable you to register a complex service query and perform dynamic lookups on services using Consul DNS. Prepared queries enable advanced lookup scenarios such filtering by multiple tags and returning services that match a prefix. You can also use prepared queries to implement service failover scenarios between datacenters.

For more information, refer to Perform dynamic service lookups with prepared queries.

Sameness groups

Sameness groups are a user-defined set of admin partitions with identical configurations, including namespaces and configuration entries. By establishing cluster peering connections and exporting services between these partitions when creating a sameness group, operators can manage groups of services across regions, runtimes, and cloud environments, and implement automated service failover strategies.

Sameness groups require a Consul Enterprise license. Refer to create sameness groups for more information.

Service definitions

A service definition contains a set of parameters that specify various aspects of the service, including how it is discovered by other services in the network. The service definition may also contain health check configurations. Configure individual services and health checks by specifying parameters in the service block of a service definition file. Refer to Define Services for information about defining services. Refer to Health Check Configuration Reference for configuration details about health checks.

Consul supports service definitions written in JSON and HCL.

Service discovery

Service discovery helps you discover, track, and monitor the health of services within a network. It uses a service's identity instead of traditional access information, such as IP address and port, to dynamically map services and track any changes within a service catalog. Service consumers can then use DNS to dynamically retrieve other service's access information from the service catalog.

To learn more, refer to service discovery use cases.

Service intentions

Service intentions control communication between services at the L4 (network) layer and the L7 (application) layer, depending on the protocol the services use to communicate. You can define service intentions in a configuration entry to automatically deny all service-to-service communication, and then configure more specific intentions to allow only defined traffic within the service mesh. You can also configure service intentions so that sidecar proxies must present a JSON Web Token (JWT) for authorization.

For more information, refer to service mesh intentions overview.

Service mesh

A service mesh is a dedicated network layer that provides secure service-to-service communication within and across infrastructure, including on-premises and cloud environments. Service meshes are often used with a microservice architectural pattern, but can provide value in any scenario where complex networking is involved. Consul’s service mesh allows organizations to securely connect and manage their network services across multiple different environments. Using Envoy as the sidecar proxy attached to every service, Consul ensures that all service-to-service communication is authorized, authenticated, and encrypted.

For more information, refer to Consul service mesh use cases.

Service mesh telemetry metrics

Consul agents, dataplanes, gateways, and sidecar proxies emit metrics that you can access and visualize using tools such as Prometheus and Grafana. Consul's UI can display visualizations of service mesh topologies and L7 metrics when they are enabled and configured in Consul. HCP Consul Central enables additional visualizations of cluster insights using dashboards and configurations managed by HashiCorp.

Refer to service mesh telemetry on virtual machines (VMs) or service mesh telemetry on Kubernetes for more information.

Sessions

Consul provides a session mechanism you can use to build distributed locks. When the services in an application's service mesh operate across multiple nodes, distributed locks can restrict traffic between nodes to prevent resource exhaustion and application failure. Sessions can be configured to use data from Consul's KV store.

For more information, refer to Sessions overview.

Static lookups

To lookup details about registered services and specific service instances, perform a static query using Consul DNS to return A and SRV records for your deployment. Consul DNS enables you to return results from across your Consul deployment, including the number of healthy instances and network addresses of nodes that match service names or custom tags.

Consul Enterprise enables static lookups for Enterprise features such as virtual services and sameness groups. Refer to Perform static DNS queries for more information.

Terminating gateways

Terminating gateways handle requests from services in the network for external services running on external nodes. They act as service mesh proxies that can services in the Consul catalog. These gateways terminate service mesh mTLS connections, enforce service intentions, and forward requests to the appropriate destination.

Terminating gateways are deprecated. Use Consul API gateways instead.

Refer to Terminating gateways for more information about how to deploy terminating gateways to your Consul service mesh.

WAN federation

Wide Area Network (WAN) federation joins two or more Consul datacenters. When you enable WAN federation in each server cluster and declare one of them the primary datacenter, Consul agents can communicate using WAN gossip to function as if they were a single datacenter.

WAN federation in your service mesh enables service-to-service communication across cloud regions, key/value store replication, and advanced strategies for traffic management such as service failover. Refer to the WAN federation documentation for more information.

Watches

Watches can monitor a datacenter's key/value (KV) store, services, nodes, health checks, and events for updates. You can configure a view of data to watch in an agent configuration file so that when the data changes, Consul invokes a handler that can call an HTTP endpoint or run an executable.

For more information, refer to Watches overview.