Manage L7 traffic with cluster peering on Kubernetes
This usage topic describes how to configure the
service-resolver custom resource definition (CRD) to set up and manage L7 traffic between services that have an existing cluster peering connection in Consul on Kubernetes deployments.
For general guidance for managing L7 traffic with cluster peering, refer to Manage L7 traffic with cluster peering.
When you use cluster peering to connect datacenters through their admin partitions, you can use dynamic traffic management to configure your service mesh so that services automatically forward traffic to services hosted on peer clusters.
service-router CRDs do not natively support directly targeting a service instance hosted on a peer. Before you can split or route traffic to a service on a peer, you must define the service hosted on the peer as an upstream service by configuring a failover in a
service-resolver CRD. Then, you can set up a redirect in a second service resolver to interact with the peer service by name.
For more information about formatting, updating, and managing configuration entries in Consul, refer to How to use configuration entries.
To configure L7 traffic management behavior in deployments with cluster peering connections, complete the following steps in order:
Define the peer cluster as a failover target in the service resolver configuration.
The following example updates the
cluster-01so that Consul redirects traffic intended for the
frontendservice to a backup instance in peer
cluster-02when it detects multiple connection failures.
apiVersion: consul.hashicorp.com/v1alpha1 kind: ServiceResolver metadata: name: frontend spec: connectTimeout: 15s failover: '*': targets: - peer: 'cluster-02' service: 'frontend' namespace: 'default'
Define the desired behavior in
The following example splits traffic evenly between
apiVersion: consul.hashicorp.com/v1alpha1 kind: ServiceSplitter metadata: name: frontend spec: splits: - weight: 50 ## defaults to service with same name as configuration entry ("frontend") - weight: 50 service: frontend-peer
Create a second
service-resolverconfiguration entry on the local cluster that resolves the name of the peer service you used when splitting or routing the traffic.
The following example uses the name
frontend-peerto define a redirect targeting the
frontendservice on the peer
apiVersion: consul.hashicorp.com/v1alpha1 kind: ServiceResolver metadata: name: frontend-peer spec: redirect: peer: 'cluster-02' service: 'frontend'