Closed sergiopozoh closed 4 years ago
andrewsykim
commented
4 years ago +1 for making FQDN optional.
I can imagine a Kubernetes-based implementation updating the cluster DNS with the fqdn provided by Hamlet but in the absense of that, it can connect to the endpoints directly w/ SNI header so optional makes sense.
sergiopozoh
commented
4 years ago I meant, these are the options I see.
FQDN provided by the service owner and used to program the consumer DNS. Since there may be collisions in the consumer (only when both owner and consumer have the same domain name), the consumer agent may create an alias for this FQDN. Client workloads in the consumer will use this aliased DNS name. Assumption: DNS in owner and consumer platforms is not shared. DNS resolution required in the consumer. Cleartext traffic.
FQDN not provided by the service owner, or provided but ignored by the consumer. The consumer agent must create a FQDN in the local DNS. The consumer will use a programmatically created FQDN using, for example, service name, etc. from the FederatedEntry. Assumption: DNS in owner and consumer platforms is not shared. DNS resolution required in the consumer. Cleartext traffic.
In the case of TLS, I think we still have the same two cases. To me, FQDN makes sense to be mandatory when both owner and consumer share DNS.
Am I missing anything @andrewsykim ?
andrewsykim
commented
4 years ago Specifically for a Kubernetes-based implementation, DNS (CoreDNS to be specific) would not be shared across clusters , but we may want to apply some global FQDN across clusters. The FQDN doesn't have to resolve to the same address (or clusterIP), but the address can route to the same set of endpoints. So in this scenario the first case is more applicable.
Even when DNS is shared across consumers, I'm not sure that FQDN will always be mandatory. Need to think about this one some more.
sergiopozoh
commented
4 years ago Even when DNS is shared across consumers, I'm not sure that FQDN will always be mandatory. Need to think about this one some more.
I haven't found a reason to make it mandatory yet. That's the reason I was proposing to make it optional.
Once you have given it a thought, I would love to learn more!
sergiopozoh
commented
4 years ago Wanted to provide an update on this. Changes are only in the consumer behavior regarding what to do with the FQDN provided by the service owner, and the descriptions. No changes to data model or APIs.
Proposed change
A better description of FQDN. Proposal: "FQDN consumer platforms use as a DNS name to access the imported FederatedService. The consumer platform DNS can be programmed to reference the Ingress of the imported FederatedService".
Make FQDN required to be unique. As this is created by the owner platform, uniqueness will be only in the service owner platform. The consumer platform has to provide it within its local catalog, for example, aliasing all FQDNs from the same owner platform consistently (with the same prefix or suffix).
Although the service owner has to provide an FQDN, the service consumer agent implementation can decide to alias it or not use it at all: whether unique or not, an FQDN can always be created by the implementor on the consumer mesh or not use it at all. For example, Consul is not currently using it when importing and simply makes it up when exporting. In the Istio implementation, it is used in ServiceEntry 'hosts' field, which is required.
Reasons The current description of FQDN is not saying much about how a service owner or consumer could use it: "FQDN the federated service exposes outside of the owner mesh".
FQDN might not be required or used by some implementors, like Consul. But it can be helpful to provide aliasing (for example, using some parts of the domain name as prefix or suffix for a service Name or ServiceID).
Alternatives Currently, we have discarded overloading Name with FQDN or vice-versa.
Currently, we have discarded making Ingress optional if the owner mesh has programmed an ingress of the service in a DNS the consumer mesh can use, as this would assume a global DNS which may not be the case in many architectures, but especially in different administrative boundaries.
Wanted to propose to make FQDN unique and provide a better description for it.
Proposed change
A better description of FQDN. Proposal: "FQDN consumer platforms use as a DNS name to access the imported FederatedService. The consumer platform DNS can be programmed to reference the Ingress of the imported FederatedService".
Make FQDN required to be unique. As this is created by the owner platform, uniqueness will be only in the service owner platform. The consumer platform has to provide it within its local catalog, for example, aliasing all FQDNs from the same owner platform consistently (with the same prefix or suffix).
Make FQDN optional. Whether unique or not, an FQDN can always be created by the implementor on the consumer mesh when needed and not provided by the owner mesh. Even when provided, since optional, there would be no need to use the one provided by the owner. Is this statement fair for all implementors? For example, Consul is not currently using it when importing and simply makes it up when exporting. In the Istio implementation, it is used in ServiceEntry 'hosts' field, which is required.
Reasons The current description of FQDN is not saying much about how a service owner or consumer could use it: "FQDN the federated service exposes outside of the owner mesh".
FQDN might not be required or used by some implementors, like Consul. But it can be helpful to provide aliasing (for example, using some parts of the domain name as prefix or suffix for a service Name or ServiceID).
Alternatives Currently, we have discarded overloading Name with FQDN or vice-versa.
Currently, we have discarded making Ingress optional if the owner mesh has programmed an ingress of the service in a DNS the consumer mesh can use, as this would assume a global DNS which may not be the case in many architectures, but especially in different administrative boundaries.