<p>I have two services, say <code>svcA</code> and <code>svcB</code> that may sit in different namespaces or even in different k8s clusters. I want to configure the services so that <code>svcA</code> can refer to <code>svcB</code> using some constant address, then deploy an Istio <strong>Service Entry</strong> object depending on the environment to route the request. I will use Helm to do the deployment, so using a condition to choose the object to deploy is easy.</p>
<p>If <code>svcB</code> is in a completely different cluster, it is just like any external server and is easy to configure.</p>
<p>But when it is in a different namespace on the same cluster, I just could not get the <strong>Service Entry</strong> work. Maybe I don't understand all the options it provides.</p>
<h2>Istio objects</h2>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: demo-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - &quot;*&quot;

---
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: svcB-se
spec:
  hosts:
  - svcB.alias
  ports:
  - number: 80
    name: http
    protocol: HTTP2
  location: MESH_INTERNAL
  resolution: svcB.svcb-ns.svc.cluster.local
</code></pre>
<h2>Update</h2>
<p>After doing some random/crazy test, I found that the <em>alias</em> domain name must ends with well know suffix, like <code>.com</code>, <code>.org</code>, arbitrary suffix, like <code>.svc</code>, <code>.alias</code>, won't work.</p>
<p>If I update the above <strong>ServiceEntry</strong> object to like this. My application works.</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: svcB-se
spec:
  hosts:
  - svcB.com
  ports:
  - number: 80
    name: http
    protocol: HTTP2
  location: MESH_INTERNAL
  resolution: svcB.svcb-ns.svc.cluster.local
</code></pre>
<p>I searched for a while and checked the Istio documentations, but could not find any reference about domain name suffix restrictions.</p>
<p>Is it implicit knowledge that only domain names like <code>.com</code> and <code>.org</code> are valid? I have left school for a long time.</p>

David S.
<p>I have posted community wiki answer to summarize the topic and paste explanation of the problem:</p>
<p>After doing some random/crazy test, I found that the  <em>alias</em>  domain name must ends with well know suffix, like  <code>.com</code>,  <code>.org</code>, arbitrary suffix, like  <code>.svc</code>,  <code>.alias</code>, won't work.</p>
<p>If I update the above  <strong>ServiceEntry</strong>  object to like this. My application works.</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: svcB-se
spec:
  hosts:
  - svcB.com
  ports:
  - number: 80
    name: http
    protocol: HTTP2
  location: MESH_INTERNAL
  resolution: svcB.svcb-ns.svc.cluster.local

</code></pre>
<p>I searched for a while and checked the Istio documentations, but could not find any reference about domain name suffix restrictions.</p>
<p>Is it implicit knowledge that only domain names like  <code>.com</code>  and  <code>.org</code>  are valid? I have left school for a long time.</p>
<p><strong>Explanation:</strong>
You can find <a href="https://istio.io/latest/docs/reference/config/networking/service-entry/#ServiceEntry" rel="nofollow noreferrer">ServiceEntry</a> requirements in the offical documentation. You can find description how you can properly set this value:</p>
<blockquote>
<p>The hosts associated with the ServiceEntry. Could be a DNS name with wildcard prefix.</p>
<ol>
<li>The hosts field is used to select matching hosts in VirtualServices and DestinationRules.</li>
<li>For HTTP traffic the HTTP Host/Authority header will be matched against the hosts field.</li>
<li>For HTTPs or TLS traffic containing Server Name Indication (SNI), the SNI value will be matched against the hosts field.</li>
</ol>
<p><strong>NOTE 1:</strong>  When resolution is set to type DNS and no endpoints are specified, the host field will be used as the DNS name of the endpoint to route traffic to.</p>
<p><strong>NOTE 2:</strong>  If the hostname matches with the name of a service from another service registry such as Kubernetes that also supplies its own set of endpoints, the ServiceEntry will be treated as a decorator of the existing Kubernetes service. Properties in the service entry will be added to the Kubernetes service if applicable. Currently, the only the following additional properties will be considered by  <code>istiod</code>:</p>
<ol>
<li>subjectAltNames: In addition to verifying the SANs of the service accounts associated with the pods of the service, the SANs specified here will also be verified.</li>
</ol>
</blockquote>
<p>Based on <a href="https://github.com/istio/istio/issues/13436" rel="nofollow noreferrer">this issue</a> you don't have to use FQDN in your <code>hosts</code> field, but you need to set proper value to select matching hosts in VirtualServices and DestinationRules.</p>
