github
/
consul
mirror of https://github.com/hashicorp/consul
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
21458 Commits
1702 Branches
457 Tags
697 MiB
 
 
 
 
 
 
Tree: 2d19cd5810
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '2d19cd5810'
${ noResults }
consul/website/content/docs/connect/gateways/index.mdx

101 lines
7.0 KiB
Raw Blame History

---
layout: docs
page_title: Gateways Overview
description: >-
Gateways are proxies that direct traffic into, out of, and inside of Consul's service mesh. They secure communication with external or non-mesh network resources and enable services on different runtimes, cloud providers, or with overlapping IP addresses to communicate with each other.
---
# Gateways Overview
This topic provides an overview of the gateway features shipped with Consul. Gateways provide connectivity into, out of, and between Consul service meshes. You can configure the following types of gateways:
- [Mesh gateways](#mesh-gateways) enable service-to-service traffic between Consul datacenters or between Consul admin partitions. They also enable datacenters to be federated across wide area networks.
- [Ingress gateways](#ingress-gateways) enable connectivity within your organizational network from services outside the Consul service mesh to services in the mesh.
- [Terminating gateways](#terminating-gateways) enable connectivity within your organizational network from services in the Consul service mesh to services outside the mesh.
[![Gateway Architecture](/img/consul-connect/svgs/consul_gateway_overview.svg)](/img/consul-connect/svgs/consul_gateway_overview.svg)
## Mesh Gateways
Mesh gateways enable service mesh traffic to be routed between different Consul datacenters and admin partitions. The datacenters or partitions can reside
in different clouds or runtime environments where general interconnectivity between all services in all datacenters
isn't feasible.
They operate by sniffing and extracting the server name indication (SNI) header from the service mesh session and routing the connection to the appropriate destination based on the server name requested.
Mesh gateways enable the following scenarios:
* **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/consul/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) for additional information.
- **Service-to-service communication across WAN-federated datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) for additional information.
- **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployments called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Across Admin Partitions](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information.
- **Bridge multiple datacenters using Cluster Peering**. Since Consul 1.14.0, mesh gateways can be used to route peering control-plane traffic between peered Consul Servers. See [Mesh Gateways for Peering Control Plane Traffic](/consul/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) for more information.
- **Service-to-service communication across peered datacenters**. Refer to [Establish cluster peering connections](/consul/docs/connect/cluster-peering/usage/establish-cluster-peering) for more information.
-> **Mesh gateway tutorial**: Follow the [mesh gateway tutorial](/consul/tutorials/developer-mesh/service-mesh-gateways) to learn concepts associated with mesh gateways.
## API Gateways
API gateways enable network access, from outside a service mesh, to services running in a Consul service mesh. The
systems accessing the services in the mesh, may be within your organizational network or external to it. This type of
network traffic is commonly called _north-south_ network traffic because it refers to the flow of data into and out of
a specific environment.
API gateways solve the following primary use cases:
- **Control access at the point of entry**: Set the protocols of external connection
requests and secure inbound connections with TLS certificates from trusted
providers, such as Verisign and Let's Encrypt.
- **Simplify traffic management**: Load balance requests across services and route
traffic to the appropriate service by matching one or more criteria, such as
hostname, path, header presence or value, and HTTP method.
Refer to the following documentation for information on how to configure and deploy API gateways:
- [API Gateways on VMs](/consul/docs/connect/gateways/api-gateway/deploy/listeners-vms)
- [API Gateways for Kubernetes](/consul/docs/connect/gateways/api-gateway/deploy/listeners-k8s).
## Ingress Gateways
<Note>
Ingress gateway is deprecated and will not be enhanced beyond its current capabilities. Ingress gateway is fully supported
in this version but will be removed in a future release of Consul.
Consul's API gateway is the recommended alternative to ingress gateway.
</Note>
Ingress gateways enable connectivity within your organizational network from services outside the Consul service mesh
to services in the mesh. To accept ingress traffic from the public internet, use Consul's
[API Gateway](https://www.hashicorp.com/blog/announcing-hashicorp-consul-api-gateway) instead.
These gateways allow you to define what services should be exposed, on what port, and by what hostname. You configure
an ingress gateway by defining a set of listeners that can map to different sets of backing services.
Ingress gateways are tightly integrated with Consul's L7 configuration and enable dynamic routing of HTTP requests by
attributes like the request path.
For more information about ingress gateways, review the [complete documentation](/consul/docs/connect/gateways/ingress-gateway)
and the [ingress gateway tutorial](/consul/tutorials/developer-mesh/service-mesh-ingress-gateways).
![Ingress Gateway Architecture](/img/ingress-gateways.png)
## Terminating Gateways
Terminating gateways enable connectivity within your organizational network from services in the Consul service mesh
to services outside the mesh.
Services outside the mesh do not have sidecar proxies or are not [integrated natively](/consul/docs/connect/native).
These may be services running on legacy infrastructure or managed cloud services running on
infrastructure you do not control.
Terminating gateways effectively act as egress proxies that can represent one or more services. They terminate service mesh
mTLS connections, enforce Consul intentions, and forward requests to the appropriate destination.
These gateways also simplify authorization from dynamic service addresses. Consul's intentions determine whether
connections through the gateway are authorized. Then traditional tools like firewalls or IAM roles can authorize the
connections from the known gateway nodes to the destination services.
For more information about terminating gateways, review the [complete documentation](/consul/docs/connect/gateways/terminating-gateway)
and the [terminating gateway tutorial](/consul/tutorials/developer-mesh/terminating-gateways-connect-external-services).
![Terminating Gateway Architecture](/img/terminating-gateways.png)