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 available to the services in the service mesh by using a common internal hostname,

Before you begin

  1. 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 as kubectl and istioctl.
    • 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.
  2. Install Bookinfo and other sample apps.
  3. 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 to REGISTRY_ONLY as shown in the following steps. Note that if you manually installed Istio, follow the steps in Upgrade Istio to update that setting.

    1. Open the gm-istiod-values.yaml file that you used to create the istiod control plane.
    2. Change the outboundTrafficPolicy field to REGISTRY_ONLY.
    3. Apply your changes by using the following command.
        kubectl apply -f gm-istiod-values.yaml --context $MGMT_CONTEXT

Create an internal DNS entry for external endpoints

  1. Log in to the reviews app and verify that you cannot reach

      kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=reviews -A -o jsonpath='{.items[0]}') --image=curlimages/curl -- curl -vik

    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
  2. Create the global namespace in the management cluster.

      kubectl create namespace global --context $MGMT_CONTEXT
  3. Create an external endpoint resource for 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
    kind: ExternalEndpoint
      name: solo
      namespace: global
        # Label that the external service will select
        external-endpoint: solo
      # Hostname address of the external service
        - name: http
          number: 80
  4. 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 the hosts 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
    kind: ExternalService
      name: solo-service
      namespace: global
      # Arbitrary, internal-only hostname assigned to the endpoint
      - ""
      - name: http
        number: 80
        protocol: HTTP
          number: 80
        # Selects the endpoint label
        external-endpoint: solo
  5. Log in to the reviews app again and verify that you are now able to reach via the internal 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]}') --image=curlimages/curl -- curl -vik

    Example output:

      * Connected to ( port 80 (#0)
    > GET / HTTP/1.1
    > Host:
    > 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
  6. 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