We're running a lot of applications in Kubernetes and handle TLS termination inside a pod with HAProxy and a certificate generated with LetsEncrypt.
This works really well for traffic coming from outside the Kubernetes cluster because the requests use the domain name as specified in the certificate.
However for internal communication using the service name - with a url like https:/// - the host part of the url no longer matches what's defined in the certificate, resulting in failure.
Is there any way to let Kubernetes' dns system resolve the full domain name to a specific service, so it doesn't get routed outside the cluster?
I can think of a couple of options that you could pursue:
You could have the requests that transit just the cluster run over http instead of https if you trust the security of your cluster network.
You could have your HAProxy instance serve a different certificate to internal requests using SNI. You would need a way to generate and distribute the internal certificates, but it would allow you to present the client a certificate that matches the Kubernetes service name.
Continue to resolve the FQDN and not worry about routing requests out and then back into the cluster. This actually isn't that different than the upcoming cross-cluster service discovery/federation feature being built into Kubernetes cluster federation.
There isn't really a way to inject/overwrite the external FQDN resolution to return the internal service IP.