Recently at VMworld 2019 in San Francisco, VMware announced a new open specification for Service Mesh Federation. This specification defines a common standard to facilitate secure communication between different service mesh solutions.
Service mesh is quickly becoming a necessity for organizations embarking upon application modernization and transitioning to microservice architectures. Consul service mesh provides unified support across a heterogeneous environment: bare metal, virtual machines, Kubernetes, and other workloads. However, some organizations may choose to run different mesh technologies on different platforms. For these customers, federation becomes critical to enable secure connectivity across the boundaries of different mesh deployments.
We have partnered with VMware to support the Service Mesh Federation Specification. This blog will explain how services running in HashiCorp Consul service mesh can discover and connect with services in VMware NSX Service Mesh (NSX-SM).
Service Mesh Federation is the ability for services running in separate meshes to communicate as if they were running in the same mesh. For example, a Consul service can communicate with an NSX-SM service running in a remote cluster in the same way it would communicate with another Consul service running in the same cluster.
The first step towards supporting federation is Service Sync: sharing which services are running on each mesh. To accomplish this, Consul Enterprise implements the Service Mesh Federation Spec via the new Consul federation service. The Consul federation service communicates with NSX-SM’s federation service to keep the service lists in sync so that each mesh is aware of each other’s services.
First, Consul sends the
foo service to the remote federation service and receives the
Next, Consul creates a Consul
bar service to represent the remote
With services synced, Consul services can now talk to remote services as if they were running in the same cluster. To do this, they configure their upstreams to route to the remote service’s name.
In this example, the Consul
foo service wants to call the NSX-SM
bar service. We configure an upstream so that port 8080 routes to
name = "foo"
upstreams = [
destination_name = "bar"
local_bind_port = 8080
Then from the
foo service, we simply need to talk to http://localhost:8080:
$ curl http://localhost:8080
<response from bar service>
Under the hood, we’re using the Consul service mesh sidecar proxies to encrypt all the traffic using TLS.
bar service running in NSX-SM, we can use KubeDNS to talk to the
foo service in Consul:
$ curl foo.default.svc.cluster.local
<response from foo service>
This request will route to the Consul Mesh Gateway and then to
foo’s sidecar proxy. The sidecar proxy decrypts the traffic and then routes it to the
Service mesh federation between Consul Enterprise and NSX-SM allows traffic to flow securely beyond the boundary of each individual mesh, enabling flexibility and interoperability. If you would like to learn more about Consul Enterprise’s integration with NSX-SM, please reach out to our sales representatives to schedule a demo.
For more information about this and other features of HashiCorp Consul, please visit: https://www.hashicorp.com/products/consul.
Consul is now supported in Google Cloud’s GKE Autopilot partner program, enabling deployment of Consul to GKE Autopilot.
Learn the installation and verification workflow for any Linux distribution that does not include HashiCorp software in its package repository.
Integrating HCP Consul Central with Backstage can enhance your organization’s infrastructure-management capabilities. Here’s how to do it.