<p>We're running a lot of applications in Kubernetes and handle TLS termination inside a pod with HAProxy and a certificate generated with LetsEncrypt.</p>

<p>This works really well for traffic coming from outside the Kubernetes cluster because the requests use the domain name as specified in the certificate.</p>

<p>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.</p>

<p>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?</p>

<p>I can think of a couple of options that you could pursue:</p>

<ol>
<li><p>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.</p></li>
<li><p>You could have your HAProxy instance serve a different certificate to internal requests using <a href="https://en.wikipedia.org/wiki/Server_Name_Indication" rel="nofollow">SNI</a>. 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. </p></li>
<li><p>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. </p></li>
</ol>

<p>There isn't really a way to inject/overwrite the external FQDN resolution to return the internal service IP.</p>
