From b815c41816ea25528f23b2bcf9044aa13c153b49 Mon Sep 17 00:00:00 2001 From: Ram Vennam Date: Fri, 4 Jun 2021 11:49:15 -0400 Subject: [PATCH] review comments (#9882) --- content/en/blog/2021/external-locality-failover/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/blog/2021/external-locality-failover/index.md b/content/en/blog/2021/external-locality-failover/index.md index 198fea6fd0..72e1df980c 100644 --- a/content/en/blog/2021/external-locality-failover/index.md +++ b/content/en/blog/2021/external-locality-failover/index.md @@ -19,7 +19,7 @@ Similar to services running inside the service mesh, you can configure Istio to ## Define external endpoints using a ServiceEntry -First, determine the location of your workloads. +[Locality load balancing](/docs/tasks/traffic-management/locality-load-balancing/) works based on `region` or `zone`, which are usually inferred from labels set on the Kubernetes nodes. First, determine the location of your workloads: {{< text bash >}} $ kubectl describe node | grep failure-domain.beta.kubernetes.io/region @@ -29,7 +29,7 @@ $ kubectl describe node | grep failure-domain.beta.kubernetes.io/region In this example, the GKE cluster nodes are running in `us-east1`. -Next, apply a `ServiceEntry` to create a `mydb.com` service that’s backed by the two DynamoDB endpoints. Set the `locality` of your primary endpoint to the same region as your workload. +Next, create a `ServiceEntry` which aggregates the endpoints you want to use. In this example, we have selected `mydb.com` as the host. This is the address your application should be configured to connect to. Set the `locality` of the primary endpoint to the same region as your workload: {{< text yaml >}} apiVersion: networking.istio.io/v1beta1