Answers: <p>You might be able (assuming you're running at least Kubernetes 1.20) to leverage a beta feature for the <code>Pod</code> spec that allows <a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field" rel="nofollow noreferrer">a <code>Pod</code> FQDN to be set in DNS.</a></p>
  <p>I am uncertain if this extends to <code>Job</code> resources in the minimum version (v1.20), but because it is part of the <code>Pod</code> specification, I would assume so between <code>Job</code>s. In this example, assuming <code>setHostnameAsFQDN: true</code> is set for that definition, a FQDN like <code>busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example</code> (for a <code>name</code> metadata field called <code>busybox</code> for that spec) would be valid, and should be accessible from a different <code>Job</code>.</p>
  <p>I was able to test that <code>Job</code> resources would accept <code>setHostnameAsFQDN</code> in the definition, and it seemed to without issue:</p>
  <pre class="lang-yaml prettyprint-override"><code>apiVersion: batch/v1
  kind: Job
  metadata:
    name: pi
  spec:
    template:
      spec:
        containers:
        - name: pi
          image: perl
          command: [&quot;perl&quot;,  &quot;-Mbignum=bpi&quot;, &quot;-wle&quot;, &quot;print bpi(2000)&quot;]
        restartPolicy: Never
        setHostnameAsFQDN: true
    backoffLimit: 4
  </code></pre>
  <p>on Kubernetes v1.21.1.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-06-03T08:10:36.030Z
Answers: Very good answer. However, we are using Kubernetes 1.19 right now. I'll try to find if it is possible to update to 1.20 at least, because 1.21 is still not available at AWS EKS.
Answers: msolefonte
Answers: CC BY-SA 4.0
Answers: 2021-06-03T08:05:34.237Z
Answers: 2021-06-03T08:05:34.237Z
Answers: Joseph Marhee
Body: <p>I have a deployment that consists on one Job that contains two containers. Due to distribution and economical reasons, I want these two containers to be deployed independently. However, they are still interconnected. This means there should be network communication between both of them.</p>
  <p>As far as I know, you can not create a Service over a Job. You need it to be at least a simple Pod. However, this adds another element and modifies the equation: I want to split the Job into two Jobs, not into one Job, one Pod and one Service.</p>
  <p>So, with this as context, is there a way to connect to Jobs directly without creating a service? They both are going to be on the same cluster, using the same internal DNS, in different machines.</p>
  <p>Basically, something like, from Job1, connect to <em>job1.job1namespace:8080</em>.</p>
  
Tags: <kubernetes>
Title: How to connect two Kubernetes Jobs without using a Service?
UserDisplayName: msolefonte
ThreadText: # How to connect two Kubernetes Jobs without using a Service?
  
  (Asked by: username_0 on 2021-06-02)
  
  I have a deployment that consists on one Job that contains two containers. Due to distribution and economical reasons, I want these two containers to be deployed independently. However, they are still interconnected. This means there should be network communication between both of them.
  
  As far as I know, you can not create a Service over a Job. You need it to be at least a simple Pod. However, this adds another element and modifies the equation: I want to split the Job into two Jobs, not into one Job, one Pod and one Service.
  
  So, with this as context, is there a way to connect to Jobs directly without creating a service? They both are going to be on the same cluster, using the same internal DNS, in different machines.
  
  Basically, something like, from Job1, connect to *job1.job1namespace:8080*.
  
  **Tags:** kubernetes
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-06-03. Score: 1
  
  You might be able (assuming you're running at least Kubernetes 1.20) to leverage a beta feature for the `Pod` spec that allows [a `Pod` FQDN to be set in DNS.](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)
  
  I am uncertain if this extends to `Job` resources in the minimum version (v1.20), but because it is part of the `Pod` specification, I would assume so between `Job`s. In this example, assuming `setHostnameAsFQDN: true` is set for that definition, a FQDN like `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` (for a `name` metadata field called `busybox` for that spec) would be valid, and should be accessible from a different `Job`.
  
  I was able to test that `Job` resources would accept `setHostnameAsFQDN` in the definition, and it seemed to without issue:
  
  ```yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: pi
  spec:
    template:
      spec:
        containers:
        - name: pi
          image: perl
          command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
        restartPolicy: Never
        setHostnameAsFQDN: true
    backoffLimit: 4
  
  ```
  
  on Kubernetes v1.21.1.
  
  > **Comments:**
  > **username_0**: Very good answer. However, we are using Kubernetes 1.19 right now. I'll try to find if it is possible to update to 1.20 at least, because 1.21 is still not available at AWS EKS.  
  
  ---
  
  