Feature Request: Allow specifying hostAliases for Knative Services

[emaildanwilson]

Allow specifying hostAliases for Knative Services

In our environment we use hostAliases for a few different use cases and it would be nice to be able to provide the same functionality on knative.

use case 1 - internal routing of external services when they are also hosted locally

When an externally facing service is also hosted locally, we prefer to connect to the local service directly but still using the external address names which provide the following benefits:

• maintains a single endpoint name for internal and external access
• allows us to have a single tls certificate for accessing the service
• routes traffic directly to the service instead of going out of the cluster to hit the external service endpoint

In order to make this work we use hostAliases to provide the internal address of the service, overriding the external dns entry to the running container.

use case 2 - accessing service entries which don't have dns entries.

Istio allows the creation of ServiceEntries, which represent service registry data for virtual services which are either internal to or external to the cluster. You can then create other Istio objects to control the routing behavior, destination services, load balancing, etc. to these endpoints. In some cases, we use endpoints which don't actually exist in DNS for the service entries and since Istio is providing the destination information dynamically the actual IP provided doesn't really matter but a DNS record needs to exist just so the application can initiate the network call which is intercepted by the sidecar proxy.

We use hostAliases to create valid dns records so the traffic can reach the sidecar and get routed.
Maintaining an extra DNS service for this is extra overhead and adds a potential failure point. (the issue is always dns, right?)

---

I propose that we add a feature gate to Knative which will allow specifying hostAliases for knative services in the container spec with a default of disabled. One question though, are there other container networking features that should be included in the same feature gate like dnsPolicy and hostNetwork?

I can contribute the PR if this change is acceptable.

[nak3]

hostAliases was discussed before in #6207.

tag to @dprotaso @mattmoor if any update.

[mattmoor]

Is this covered by the DomainMapping work that @julz has been looking into?

[emaildanwilson]

@julz - I don't have access to the Feature Proposal doc referenced in #9713.
Is this use case included in that work or not?

[julz]

Hi @emaildanwilson, you should be able to get access to the doc by joining the knative-users@ google group. Let me know if that doesn't work or you're already a member and I'll try to figure out what's going wrong!

[emaildanwilson]

thank you. I reviewed the doc and it seems to solve for ingress specific domain routing as opposed to egress. The reason we need hostAliases is to assist with egress calls from within a running pod for a knative service.

[emaildanwilson]

Since this isn't covered in the domain mapping proposal is it ok to add a feature toggle for it?

[dprotaso]

Since this isn't covered in the domain mapping proposal is it ok to add a feature toggle for it?

I think so - I'll add this to next week's API WG agenda for a discussion