<p>In the case that an app and database are in different containers/pods (each a separate deployment yaml) how do you get them to communicate?</p>

<p>For example, a Django app requires the host name of the database in it's config/environment variables (along with the database name and a few other things) in order to connect to the database.</p>

<p>You should be able to specify the service as follows (assuming the database has a service called db-service in the default namespace):</p>

<p><strong>Inside Django app demployment.yaml file:</strong></p>

<pre><code>    env:
    - name: SQL_HOST
      value: "db-service.default"
</code></pre>

<p>or you could do some hackery with the HOSTNAME for the database container (if it's similar to the app name) for example:</p>

<p><strong>Inside Django app demployment.yaml file:</strong></p>

<pre><code>env:
- name: POD_NAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name

- name: SQL_HOST
  value: $(POD_NAME)-db
</code></pre>

<p><strong>Inside Postgres demployment.yaml file:</strong></p>

<pre><code>spec:
  replicas: 1
  selector:
    matchLabels:
      app: sitename-db-container
  template:
    metadata:
      labels:
        app: sitename-db-container
    spec:
      hostname: sitename-db
</code></pre>

<p>But what happens when you have multiple deployments inside a service for the same app (each having their app - database container pair)? How will the service know which app pod will communicate with what database pod? Does there now need to be a separate service for every app and database deployment?</p>

Mick
<blockquote>
  <p>But what happens when you have multiple deployments inside a service
  for the same app (each having their app - database container pair)?
  How will the service know which app pod will communicate with what
  database pod? Does there now need to be a separate service for every
  app and database deployment?</p>
</blockquote>

<p>What do you mean by <em>"multiple deployments inside a service"</em> ? In a <code>Service</code> definition you are supposed to select only one set of <code>Pods</code>, let's say managed by one specific <code>Deployment</code>. As @Matt suggested, you should always <em>create a service with a unique name for each pod/db you want to access</em>. If you have <code>Pods</code> dedicated to do specific tasks you deploy them separately (as separate <code>Deployments</code>). They can even consist of just one <code>Pod</code> if you don't need any redundancy. And basically you will always create a separate <code>Service</code> ( obviously with unique name as you cannot create more <code>Services</code> using the same name ) for exposing different microservice ( represented by unique <code>Deployment</code>). Note that if you don't create a <code>Deployment</code> but a simple <code>Pod</code> it won't be managed by any controller so if it crashes, nothing will take care of recreating it. So definitely you should always use <code>Deployment</code> even to run a single <code>Pod</code> representing your microservice.</p>

<p>Have you read <a href="https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/#creating-a-service" rel="nofollow noreferrer">this</a> topic in official kubernetes documentation ? If you don't specify <code>Service</code> type, by default it creates so called <code>ClusterIP</code> Service which is basically what you need to expose your <code>app</code> components internally (make them available for other app components in your cluster).</p>
