From bad6ab958d5bdfab471797c1de2fc0e55b57b1f5 Mon Sep 17 00:00:00 2001 From: Alex Robinson Date: Sun, 24 Jun 2018 21:18:03 -0500 Subject: [PATCH] Fix rendering of example federated service DNS name (#9161) --- .../federation/federation-service-discovery.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/en/docs/tasks/federation/federation-service-discovery.md b/content/en/docs/tasks/federation/federation-service-discovery.md index 8b14127fcc..fc905d76a4 100644 --- a/content/en/docs/tasks/federation/federation-service-discovery.md +++ b/content/en/docs/tasks/federation/federation-service-discovery.md @@ -268,12 +268,13 @@ With the introduction of Federated Services and Cross-Cluster Service Discovery, this concept is extended to cover Kubernetes services running in any other cluster across your Cluster Federation, globally. To take advantage of this extended range, you use a slightly different -DNS name (of the form "..", -e.g. myservice.mynamespace.myfederation) to resolve Federated -Services. Using a different DNS name also avoids having your existing -applications accidentally traversing cross-zone or cross-region -networks and you incurring perhaps unwanted network charges or -latency, without you explicitly opting in to this behavior. +DNS name of the form ```".."``` +to resolve Federated Services. For example, you might use +`myservice.mynamespace.myfederation`. Using a different DNS name also +avoids having your existing applications accidentally traversing +cross-zone or cross-region networks and you incurring perhaps unwanted +network charges or latency, without you explicitly opting in to this +behavior. So, using our NGINX example service above, and the Federated Service DNS name form just described, let's consider an example: A Pod in a