consul/docs/v2-architecture/service-mesh/README.md

47 lines
2.7 KiB
Markdown

# V2 Service Mesh Architecture
In Consul 1.16 and 1.17 releases, Consul's service mesh has been rewritten to use the controller architecture and the
resource APIs.
At a high level, the service mesh consists of resources and controllers living in three groups: `catalog`, `mesh`,
and `auth`.
![controllers diagram](controllers.png)
The controllers in each groups are responsible for producing an output that may then be used by other controllers.
-> **Note:** This diagram is valid as of Consul 1.17. It may change in the future releases.
## Catalog controllers
Catalog controllers are responsible for reconciling resources in the `catalog` API group.
1. **FailoverPolicy** controller validates `FailoverPolicy` resource has valid service references and updating the
status the `FailoverPolicy` resource with the result.
2. **WorkloadHealth** controller takes in workloads and any relevant health statuses and updates the status of a
workload with the combined health status.
3. **NodeHealth** controller takes in nodes and any relevant health statuses and updates the status of a node with the
combined health status.
4. **ServiceEndpoints** controller generates a `ServiceEndpoints` object that is name-aligned with a service and
contains workload addresses and ports that constitute a service.
## Mesh Controllers
1. **ProxyConfiguration** controller generates a `ComputedProxyConfiguration` resource that is name-aligned with a
workload. `ComputedProxyConfiguration` contains all merged `ProxyConfiguration` resources that apply to a specific
workload.
2. **Routes** controller generates a `ComputedRoutes` resource that is name-aligned with a service. It contains merged
configuration from all xRoutes objects as well as `FailoverPolicy` and `DestinationPolicy`.
3. **ExplicitDestinations** controller generates a `ComputedExplicitDestinations` resource that is name-aligned with a
workload. It contains merged `Destinations` resources that apply to a specific workload.
4. **SidecarProxy** controller takes in the results of the previous three controllers as well as some user-provided
resources and generates `ProxyStateTemplate` resource which serves as the representation of Envoy configuration for
sidecar proxies.
5. **XDSController** takes in `ProxyStateTemplate` resources, fills in missing endpoints references as well as
certificates and CA roots and sends them over to another component that sends this information over to Envoy.
## Auth Controllers
1. **TrafficPermissions** controller generates `ComputedTrafficPermissions` resource that is name-aligned
with `WorkloadIdentity`. This computed resource contains all traffic permissions that apply to a specific workload
identity.