<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>

CC BY-SA 4.0
2021-06-03T08:10:36.030Z
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.
msolefonte
CC BY-SA 4.0
2021-06-03T08:05:34.237Z
2021-06-03T08:05:34.237Z
Joseph Marhee
<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>

<kubernetes>
How to connect two Kubernetes Jobs without using a Service?
msolefonte
# 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.
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 Jobs. 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:
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.  

---

