Istio Ingress Gateway will not permit short names

[vincentjorgensen]

Bug description Short names not allowed in istio ingress gateways

for: "gateway-machine.yaml": admission webhook "pilot.validation.istio.io" denied the request: configuration is invalid: 1 error occurred:
    * short names (non FQDN) are not allowed

Expected behavior In our local development environment, we use DNS search domains to so that internal-to-kubernetes shortnames and the external-to-kubernetes short names match up. For example, regardless of whether you are developing in devel or preprod, "machine" will always resolve to the correct DNS host for the development environment.

If an external application attempts to use an ingress gateway, however, to communicate inside the mesh, the gateway fails if the FQDN isn't used.

For example, this works:

grpcurl machine.devel.local.domain:4000 Action/Do

But this never does (and it never will, if I understand ingress gateways correctly)

grpcurl machine:4000 Action/Do

Even though both machine.devel.local.domain and machine resolve correctly in DNS

If ingress gateways can't route based on short name headers, is there an alternative to using ingress gateways for getting machine to correctly route inside the ingress gateway? I have an example manifest below

Steps to reproduce the bug

---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: machine-gateway
  namespace: devel
  labels:
    app: machine
spec:
  selector:
    istio: ingressgateway
  servers: 
  - port:
      number: 4000
      name: grpc
      protocol: grpc
    hosts:
    - "machine.devel.local.domain"
    # - "machine" # this line isn't allowed
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: machine-virtualservice
  namespace: devel
  labels:
    app: machine
    service_name: machine
spec:
  hosts:
  - "machine.devel.local.domain"
  - "machine" # this line doesn't do anything
  gateways:
  - machine-gateway
  http: 
  - match:
    - port: 4000
    route:
    - destination:
        port:
          number: 4000
        host: machine
...

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)

% istioctl version --remote
client version: 1.4.3
control plane version: 1.4.3
data plane version: 1.4.3 (147 proxies)

% kubectl version --short
Client Version: v1.17.4
Server Version: v1.14.9-eks-502bfb

How was Istio installed? kubectl apply

Environment where bug was observed (cloud vendor, OS, etc) EKS 1.14

Thank you in advance for your advice and assistance.

[DanielQujun]

This is expected behaviour, hosts field set in gateway shold be FQDN or "*"

ref: https://istio.io/docs/reference/config/networking/gateway/#Server

[vincentjorgensen]

@DanielQujun Thank you for your reply. Yes, I understand that it's expected behavior. My question is whether the developers or the developer community know if a shortname alternative or a shortname "hack". Thanks.

[DanielQujun]

I speculate that The shortname could work because kubernetes set SearchDomain for Pod, It's based on kubernetes service, But the gateway is designed for exposing service for the external, the shortname might not be appropriate here.

In fact, The domains in gateway route's VirtualHost was extracted from where hosts in VirtualService and server.hosts in Gateway intersect.

// We have two cases here:
// 1. virtualService hosts are 1.foo.com, 2.foo.com, 3.foo.com and server hosts are ns/*.foo.com
// 2. virtualService hosts are *.foo.com, and server hosts are ns/1.foo.com, ns/2.foo.com, ns/3.foo.com
intersectingHosts := serverHosts.Intersection(virtualServiceHosts)

https://github.com/istio/istio/blob/master/pilot/pkg/networking/core/v1alpha3/gateway.go#L235

So I think is hard to set shortname for gateway cause you can't define a host to match it (since host in gateway needs to be FQDN) even if you create a service for your shortname.

[howardjohn]

How does your DNS determine that service if you just have a single part machine and not machine.devel. I am skeptical this is a use case we should support, especially as it will lead to users attempting to use short names to reference k8s services which we will not support.

@rshriram any thoughts?

[wanglihui]

this feature is import for users from k8s. the old program has harded code the service short name. when use istio, we don't want to modify the FQDN. especial the test env is istio, prod is k8s native.

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2020-07-28. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.

[letdosomething]

Does this problem resolved? I migrate istio from native k8s. Ingress nginx can config shot name host. Client hard code it. This involes hundreds of service.

[sfc-gh-stopchiy]

In our company, we also use short names for internal apps, which are managed in the /etc/hosts file. Currently, we are in the process of migrating all internal apps to Kubernetes with Istio, and we have encountered an issue where short links do not work. Is it possible to implement a feature to support short links?

[stanfordpeng]

Note for Kubernetes users: When short names are used (e.g. “reviews” instead of “reviews.default.svc.cluster.local”), Istio will interpret the short name based on the namespace of the rule, not the service. A rule in the “default” namespace containing a host “reviews” will be interpreted as “reviews.default.svc.cluster.local”, irrespective of the actual namespace associated with the reviews service. To avoid potential misconfigurations, it is recommended to always use fully qualified domain names over short names.

ref: https://istio.io/latest/docs/reference/config/networking/virtual-service/