How to use Istio Service Entry object to connect two services in different namespace?

user_309830 0
Viewed 1039

I have two services, say svcA and svcB that may sit in different namespaces or even in different k8s clusters. I want to configure the services so that svcA can refer to svcB using some constant address, then deploy an Istio Service Entry 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.

If svcB is in a completely different cluster, it is just like any external server and is easy to configure.

But when it is in a different namespace on the same cluster, I just could not get the Service Entry work. Maybe I don't understand all the options it provides.

Istio objects

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:
    - "*"

---
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

Update

After doing some random/crazy test, I found that the alias domain name must ends with well know suffix, like .com, .org, arbitrary suffix, like .svc, .alias, won't work.

If I update the above ServiceEntry object to like this. My application works.

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

I searched for a while and checked the Istio documentations, but could not find any reference about domain name suffix restrictions.

Is it implicit knowledge that only domain names like .com and .org are valid? I have left school for a long time.

istio kubernetes
1 Answers

I have posted community wiki answer to summarize the topic and paste explanation of the problem:

After doing some random/crazy test, I found that the alias domain name must ends with well know suffix, like .com, .org, arbitrary suffix, like .svc, .alias, won't work.

If I update the above ServiceEntry object to like this. My application works.

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

I searched for a while and checked the Istio documentations, but could not find any reference about domain name suffix restrictions.

Is it implicit knowledge that only domain names like .com and .org are valid? I have left school for a long time.

Explanation: You can find ServiceEntry requirements in the offical documentation. You can find description how you can properly set this value:

The hosts associated with the ServiceEntry. Could be a DNS name with wildcard prefix.

  1. The hosts field is used to select matching hosts in VirtualServices and DestinationRules.
  2. For HTTP traffic the HTTP Host/Authority header will be matched against the hosts field.
  3. For HTTPs or TLS traffic containing Server Name Indication (SNI), the SNI value will be matched against the hosts field.

NOTE 1: 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.

NOTE 2: 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 istiod:

  1. 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.

Based on this issue you don't have to use FQDN in your hosts field, but you need to set proper value to select matching hosts in VirtualServices and DestinationRules.

user_154075420
Related