Create internal DNS entries for external endpoints
Create internal DNS entries that services in the mesh use to reach an external endpoint.
Instead of allowing specific IP addresses, CIDR ranges, or hostnames directly, you can set up an internal hostname or IP address that serves multiple external endpoints and therefore works similarly to setting up a CNAME or A record in your DNS provider. To do that, you use ExternalEndpoint
custom resources to define the external endpoints. Then, you define the internal hostname or IP address that services in the mesh use to route traffic to these endpoints in the ExternalService
resource.
The example in this guide assumes that you want to make www.solo.io
available to the services in the service mesh by using a common internal hostname, www.example.com
.
Before you begin
This guide assumes that you use the same names for components like clusters, workspaces, and namespaces as in the getting started. If you have different names, make sure to update the sample configuration files in this guide.
Complete the multicluster getting started guide to set up the following testing environment.
- Three clusters along with environment variables for the clusters and their Kubernetes contexts.
- The Gloo
meshctl
CLI, along with other CLI tools such askubectl
andistioctl
. - The Gloo management server in the management cluster, and the Gloo agents in the workload clusters.
- Istio installed in the workload clusters.
- A simple Gloo workspace setup.
- Install Bookinfo and other sample apps.
Decide on the outbound traffic policy for your service mesh. If you followed the steps to install Istio with the Istio lifecycle manager, the outbound traffic policy for your service mesh is set to
ALLOW_ANY
by default and allows your services in the mesh to reach any external endpoint. You can change this setting and instead block all egress traffic to hosts that are not part of your service mesh by changing the outbound traffic policy toREGISTRY_ONLY
as shown in the following steps. Note that if you manually installed Istio, follow the steps in Upgrade Istio to update that setting.- Open the
gm-istiod-values.yaml
file that you used to create the istiod control plane. - Change the
outboundTrafficPolicy
field toREGISTRY_ONLY
. - Apply your changes by using the following command.
kubectl apply -f gm-istiod-values.yaml --context $MGMT_CONTEXT
- Open the
Create an internal DNS entry for external endpoints
Log in to the reviews app and verify that you cannot reach
www.solo.io
.kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=reviews -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -vik www.solo.io
Example output:
* Mark bundle as not supporting multiuse < HTTP/1.1 502 Bad Gateway HTTP/1.1 502 Bad Gateway < date: Thu, 11 May 2023 17:07:43 GMT date: Thu, 11 May 2023 17:07:43 GMT < server: envoy server: envoy < content-length: 0 content-length: 0
Create the
global
namespace in the management cluster.kubectl create namespace global --context $MGMT_CONTEXT
Create an external endpoint resource for
www.solo.io
. The external endpoint represents the server or service outside of your service mesh that you want to reach. You later use the external service to assign a unique hostname to this external endpoint that services in your mesh can use to send requests to. For more information, see the API reference for ExternalEndpoint.kubectl apply --context $MGMT_CONTEXT -f- <<EOF apiVersion: networking.gloo.solo.io/v2 kind: ExternalEndpoint metadata: name: solo namespace: global labels: # Label that the external service will select external-endpoint: solo spec: # Hostname address of the external service address: www.solo.io ports: - name: http number: 80 EOF
Create an external service resource to expose the external endpoint inside your mesh. In this example, you select all endpoints with the
external-endpoint: solo
label. Note that thehosts
field is not required to match the address that you specified in the external endpoint, because this host is an internal address that is used only by the proxies and services within your service mesh. For more information, see the API reference for ExternalService.kubectl apply --context $MGMT_CONTEXT -f- <<EOF apiVersion: networking.gloo.solo.io/v2 kind: ExternalService metadata: name: solo-service namespace: global spec: hosts: # Arbitrary, internal-only hostname assigned to the endpoint - "www.example.com" ports: - name: http number: 80 protocol: HTTP targetPort: number: 80 selector: # Selects the endpoint label external-endpoint: solo EOF
Log in to the reviews app again and verify that you are now able to reach
www.solo.io
via the internalwww.example.com
domain name.kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=reviews -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -vik www.example.com
Example output:
* Connected to www.example.com (240.240.105.9) port 80 (#0) > GET / HTTP/1.1 > Host: www.example.com > User-Agent: curl/8.0.1-DEV > Accept: */* > < HTTP/1.1 200 OK < content-length: 4815 < content-type: text/html; charset=UTF-8 < server: envoy < x-pantheon-styx-hostname: styx-fe4-a-65bfb7c97b-2dqwz < x-styx-req-id: 4957c993-f323-11ed-ad4c-9a97f73604cc < date: Mon, 15 May 2023 13:20:39 GMT < x-served-by: cache-chi-kigq8000059-CHI, cache-iad-kcgs7200147-IAD < x-cache: MISS, MISS < x-cache-hits: 0, 0 < x-timer: S1684156840.809399,VS0,VE83 < vary: Accept-Encoding, Cookie, Cookie < age: 0 < accept-ranges: bytes < via: 1.1 varnish, 1.1 varnish < x-envoy-upstream-service-time: 86 ...
Optional: Remove the resources that you created as part of this guide.
kubectl delete externalendpoint solo -n global --context $MGMT_CONTEXT kubectl delete externalservice solo-service -n global --context $MGMT_CONTEXT kubectl delete ns global --context $MGMT_CONTEXT