About policies

With traffic policies, you can specify how you want to manipulate and respond to incoming requests in your service mesh. For example, you might want to add or remove header information before forwarding the request to your service, implement retries, timeouts, and failover scenarios, or ensure that services use mutual TLS (mTLS) when communicating with each other.

For an overview of supported traffic policies in Gloo Mesh, see Supported policies in Gloo Mesh.

Resources to apply policies to

Policies might apply to the following resources:

• Route: Routes define how to match an incoming request, and what actions you want to perform on a matched request. For example, you can decide to forward the request to a destination in the service mesh, directly respond to the request without forwarding, or manipulate and redirect requests. Routes are defined in a Gloo Mesh route table.
• Destinations: Destinations determine where incoming requests are routed to. A destination can be a Kubernetes Service, a Virtual Destination in a multi-cluster setup, or an External Service resource that you use to reach endpoints that are outside your service mesh.
• Workloads: A workload represents the app that responds to incoming request. For example, you can have Kubernetes workloads such as Deployments or StatefulSets. Or, you can use an Istio WorkloadEntry that might run in a bare metal or virtual machine outside your Kubernetes cluster.

You can apply the policies by using Kubernetes labels and selectors that match the route table, virtual destination, or workload. Remember, all of these resources must be in the same workspace for the policy to apply the resource. To see what resources a policy might select, check the Kubernetes labels such as with the following commands.

kubectl get <RESOURCE> -n <NAMESPACE> -l <KEY=VALUE>
kubectl get all -A -l env=prod

Import and export policies to other workspaces