<p>Is the host needed when connecting to a Postgres container behind a K8s service?</p>
<p>I was able to connect via the sql driver using just the username, password and dbname. When using the postgres driver with GORM it fails without the host in the url.</p>
<p>The issue is that the service IP address routing to the Postgres container is only known once creating and applying the service to the cluster. The container running code to connect to the Postgres container doesn't have access to this host variable, without hardcoding or adding the host to the secrets and reapplying the secrets file.</p>
<p>What is the correct way to dynamically connect to the Postgres container via the K8s service from another container?</p>

some_id
<p>The idiomatic way to achieve this is to use the <code>service name</code> as <code>hostname</code> and the <code>port</code> the <code>service</code> is exposing.</p>
<p>When in the same <code>namespace</code>, the <code>service name</code> alone is enough. I.E.</p>
<pre class="lang-sh prettyprint-override"><code>my-service-name:8080
</code></pre>
<p>When in different namespaces, you can append the namespace to the service name as its part of the container's fully qualified domain name. I.E.</p>
<pre class="lang-sh prettyprint-override"><code>my-service.my-namespace:8080
</code></pre>
<p>Additionally, many tools and even the browser is using <code>default ports</code>. So if you were to expose your <code>service</code> on <code>port 80</code> and wanted to reach it over <code>HTTP</code> with let's say <code>curl</code>, you could omit the <code>port</code> since <code>curl</code> would use <code>port 80</code> by default.</p>
<pre class="lang-sh prettyprint-override"><code>curl my-service
</code></pre>
<p>Note that in this instance even the protocol is left out, as <code>curl</code> uses <code>HTTP</code> by default. If you wanted to connect over <code>HTTPS</code> on <code>port 8080</code> to a <code>service</code>, then you would need to provide both <code>protocol</code> and <code>port</code>.</p>
<pre class="lang-sh prettyprint-override"><code>curl https://my-service:8080
</code></pre>
<p>This is because, Kubernetes runs its own <code>DNS resolver</code>. To learn more about this, you can maybe look at this question.</p>
<p><a href="https://stackoverflow.com/questions/50668124/why-dig-does-not-resolve-k8s-service-by-dns-name-while-nslookup-has-no-problems/68130684#68130684">Why dig does not resolve K8s service by dns name while nslookup has no problems with it?</a></p>
<p>Furthermore, it is a common pattern to use <code>environment variables</code> for your container to set the <code>URI</code> to connect to other <code>services</code>. That has the benefit of being able to deploy your <code>service</code> everywhere without having to know how the other service may be reachable upfront. Otherwise, you would potentially need to rebuild the <code>container</code>, if something outside such as <code>service name</code> or <code>port</code> has changed.</p>
